Lazarus

Recovery that begins with the human

A dying drive is never just a dying drive. It is somebody's wedding photos, somebody's decade of tax records, somebody's unfinished novel, sitting on failing hardware with one real chance to come off it intact. Lazarus is built for that moment: an official Arcology ecosystem tool for offline Windows imaging, recovery, and hardware migration, designed around the complete repair-bench workflow rather than treating raw copying as the whole product.

The operator sees durable device identity, physical bench role, job context, drive analysis, current operation, evidence, and safe-disconnect state -- everything a person needs to feel, correctly, that the machine understands the stakes as well as they do. Advanced mechanisms remain available without becoming prerequisites for protecting a customer disk.

Implemented recovery path

• Linux block-device discovery with persistent by-path and by-id identity
• Source-only and destination-only physical bench policy
• Read-only GPT, MBR, NTFS, FAT, exFAT, Linux, and offline Windows inspection
• Resumable directory-backed .laz images with SHA-256 chunk maps and Zstandard compression
• Normal and Rescue Mode imaging with bad-sector recording
• Cold-reopen verification, factual reports, and destination-only restore
• GTK workflow client, dependency-light TUI, local privileged service, and dedicated appliance work
• Lazarum read-only image inventory, report review, on-demand browsing, and file extraction

The non-negotiable boundary

Approved source devices are opened read-only, and the source API does not expose write operations. Destination writes travel through separate handles, explicit destination-only policy, and destructive confirmation.

The graphical client is unprivileged. Raw disks, mounts, imaging, restore, and boot repair belong to a narrow local service that validates requests independently of the interface.

ArcoBASIC as a communication language

ArcoBASIC lets Lazarus explain its architecture in working code with the clarity people expect from pseudocode. The examples communicate workflow, safety, verification, and recovery policy without asking the reader to decode a language designed around incidental complexity.

The comments are part of that purpose. A person learning recovery engineering should be able to follow what the system protects, what evidence it requires, and why a transition is allowed. The code remains usable language rather than a diagram that must later be translated into something else.

A backup is a claim that requires evidence

Lazarus does not call an image verified merely because the write loop ended. It closes and reopens the image, validates lifecycle markers and metadata, checks stored and logical SHA-256 hashes, reconstructs the partition layout, and tests supported filesystem structures.

A verified raw image can still contain source corruption. Lazarus preserves that distinction and produces an escalation report instead of hiding uncertainty behind a green checkmark.

Verification is a separate act from completion

The habit worth taking from Lazarus is not any specific check. It is refusing to let "the operation finished" and "the operation succeeded" be the same claim, anywhere a result matters enough that being wrong has a cost.

• Close and reopen what you just wrote before trusting it. A write loop that exits cleanly has only proven it finished, not that the result is usable; reopening it as a fresh reader would is the only way to know.
• Design the unprivileged and the privileged paths as physically separate handles, not just separate permission checks on the same one. Source devices here are opened read-only at the API level, so a bug in the interface cannot become a write to the wrong disk no matter what the interface does wrong.
• When a result is uncertain, say so explicitly instead of rounding up to success. An escalation report that admits ambiguity is more useful, and more trustworthy long-term, than a green checkmark that overstates what was actually confirmed.