Recovery Workflow

Recovery begins before the copy

Lazarus is built around a repair-bench reality: the operator may be tired, hurried, interrupted, or unfamiliar with the exact storage device in front of them. A technically correct imaging engine is not enough if the surrounding workflow makes it easy to confuse the source, destination, customer, or purpose.

Every job begins with a ticket number, customer name, technician identity, and job purpose. Devices are shown with persistent identity, capacity, transport, physical port, and assigned bench role instead of relying on transient names such as /dev/sdb.

Task-oriented product modes

Create a verified backup before repair
Restore a verified backup to an approved destination
Move Windows to replacement hardware
Recover selected files without restoring the complete disk
Verify an existing backup independently of its creation job

The normal path

Discover the device and apply physical bench policy
Open an approved source read-only and analyze it without blocking raw capture
Select a named job preset or an explicit expert policy
Write a resumable image while recording chunk hashes and factual progress
Close and reopen the image before verification
Produce either a completion report or an escalation report
Mark devices safe to disconnect only after handles, mounts, and flushes are complete

Readable workflow policy

ArcoBASIC expresses the human-facing workflow as small, readable state transitions. The code communicates the procedure at pseudocode clarity while remaining executable and testable.

Raw-device authority remains behind the narrow service boundary. The example explains the decision without burying the reader in unrelated device-access machinery.

ArcoBASICArcoBASIC communication example: determine the next safe workflow step

' Lazarus workflow policy should read like the procedure it enforces.
FUNCTION NextRecoveryStep(job)
    ' Identity is required before any disk operation begins.
    IF job.Ticket == "" OR job.Customer == "" THEN
        RETURN "COLLECT JOB IDENTITY"
    END IF

    ' A source must be recognized and approved by bench policy.
    IF job.SourceSelected == FALSE THEN RETURN "SELECT SOURCE"
    IF job.SourceApproved == FALSE THEN RETURN "BLOCKED BY BENCH POLICY"

    ' Analysis informs the imaging policy, but a damaged layout does not
    ' prevent Lazarus from preserving the raw device in Rescue Mode.
    IF job.AnalysisFinished == FALSE THEN RETURN "ANALYZE SOURCE"
    IF job.ImageFinished == FALSE THEN RETURN "CREATE IMAGE"

    ' Creation and verification are separate operations on purpose.
    IF job.Verified == FALSE THEN RETURN "VERIFY IMAGE"
    RETURN "READY FOR RECOVERY OR RESTORE"
END FUNCTION

job = {
    "Ticket": "45127",
    "Customer": "Smith",
    "SourceSelected": TRUE,
    "SourceApproved": TRUE,
    "AnalysisFinished": TRUE,
    "ImageFinished": FALSE,
    "Verified": FALSE
}

PRINT NextRecoveryStep(job)

Honest state is part of recovery

Lazarus distinguishes “the application did not write to the source,” “the drive appears healthy,” and “the customer data is safe.” Those statements are not interchangeable. The interface reports only what the current evidence supports.

Analysis can recommend Rescue Mode, but a corrupt partition table or unreadable filesystem does not become an excuse to abandon raw capture. The damaged structure is evidence to preserve.

What travels past disk recovery

The workflow gate in NextRecoveryStep and the ticket-before-touch rule are specific to a repair bench. A different project will have a different sequence of required steps and a different reason those steps must happen in order, but the discipline of encoding that order explicitly, instead of trusting an operator to remember it, is what actually generalizes.

The same shape shows up anywhere a system asks a person to do something consequential in the right order: deployment pipelines that require a signed-off change before a promote step, onboarding flows that block account creation until identity is confirmed, or any state machine that separates the thing ran from the thing was checked. The mechanism differs every time; the discipline of making the order explicit and checkable does not.

Require identity before allowing the operation that matters. Lazarus refuses to let a job proceed past COLLECT JOB IDENTITY until a ticket and customer exist, because an unattributed disk operation is a liability no matter how well it runs.
Make the required sequence a readable function, not tribal knowledge. NextRecoveryStep is a flat chain of checks that reads like the procedure itself, so a new technician, or a future maintainer, can verify the logic by reading it instead of watching someone else work the bench.
Separate the step that creates a result from the step that confirms it. The workflow treats CREATE IMAGE and VERIFY IMAGE as distinct states on purpose, so a rushed job cannot silently skip confirmation just because creation finished.
Treat a damaged input as evidence to carry forward, not a reason to stop. Analysis recommending Rescue Mode does not cancel the job; a corrupt partition table becomes part of what gets preserved and reported.

LEARNING LAYER

Key terms, in plain language

You do not need a systems background to follow the work. These are the specialized terms used on this page.

Disk image: A sector-by-sector copy of storage media saved into a file or another device. Recovery work usually analyzes the image so the fragile original is touched as little as possible.
Resumable imaging: A recovery process that records completed and failed areas so it can pause, retry difficult regions, and continue without starting over.
Persistent device identity: Hardware and physical-path information used to recognize a storage device across reconnects. It is safer than relying on temporary Linux names such as /dev/sdb.
Rescue Mode: An imaging policy for failing media that retries unreadable areas with bounded smaller reads and records ranges that could not be recovered.