SafeReturn

Full-disk backup and recovery for ordinary Windows users — bootable system backups, verification, and restore of individual files or the whole PC through a guided interface.

Most backup tools will tell you a backup "completed." Almost none will prove it can bring your PC back. SafeReturn is built around that proof.

The standout: Recovery Rehearsal

Recovery you can understand and test before a crisis, planned in four levels. These are product goals, not a claim that every level is complete:

1. Quick Check — every referenced chunk is re-hashed and the recorded files are checked for size and hash consistency. Boot-component checks (EFI / BCD / WinRE) are planned, not currently part of this check.
2. File Rehearsal — files you choose (plus a random sample) are restored to a sandbox folder and verified byte-for-byte.
3. Boot Rehearsal — the backup is restored to a virtual disk and actually booted, without touching your real disk.
4. Full Dress Rehearsal — a guided whole-PC restore to a spare disk using the exact recovery flow a real disaster would use.

After a successful rehearsal, SafeReturn produces a printable Recovery Card: which drive to plug in, which USB to boot from, and steps 1-2-3 in large type, written for a stressed non-technical reader.

Honesty is a design rule here: no invented "health score." The app shows facts — last backup time, which rehearsals passed and when — and says "Not tested yet" when a rehearsal has never run.

Status

Pre-alpha. The S1/S2 engine, S3 capture layer, recovery-media planning, and bare-metal restore planning and simulation are implemented in part. There is no installable product yet; real media creation and whole-disk restore are disabled. What exists today:

• An encrypted chunk store (safereturn-core): content-addressed chunks (SHA-256 of the plaintext, dedupe), compressed and encrypted per-chunk (XChaCha20-Poly1305), volumes unlocked by an Argon2id passphrase or a recovery-key file, multi-folder backup sets, and a catalog that rebuilds from their manifests. Before publishing a new set, the engine re-reads its new and reused chunks and checks each file's recorded size and hash. Quick Check names damaged chunks and inconsistent files. The manifests are plaintext and unauthenticated; these checks cannot prove a manifest has not been altered or entries removed. See docs/BACKUP_INTEGRITY.md and docs/S1_S2_NOTES.md.
• The S3 capture layer: backups read through a capture source — the live filesystem by default, or a VSS snapshot via a prefix-mapped source — and every set manifest records which (capture_mode), plus an optional system-facts section (boot mode, Secure Boot, BitLocker, ESP contents, WinRE, BCD status — each fact sourced, each unknown explicit and reasoned). See docs/S3_NOTES.md. Honest limit: this code has never taken a real snapshot — VSS runtime verification is the pending S0.5 on-machine session, listed precisely in those notes.
• The S4 recovery-media planner: a pure media plan based on stated facts, typed refusals, contract messages, plan tokens, a media manifest, cross-platform verify_media, and a boot-test marker. The built-in Windows ADK executor is disabled, including with SR_MEDIA_LIVE=1: its drive selector is not yet bound to the confirmed physical device or protected-disk checks. Planning does not verify physical identity. No media has ever been built by this code; see docs/S4_NOTES.md.
• The S5 bare-metal (whole-PC) restore: a pure, fully tested system-restore plan (GPT layout — ESP/MSR/Windows/WinRE — with every size computed and every default carrying its Microsoft Learn source, per-partition file application, and the bcdboot/reagentc boot steps as data), typed refusals (a file-only set, BIOS source, firmware mismatch, missing boot files, target too small — all named, before anything is erased), disclosed gaps (missing WinRE, and the BitLocker rule: a restored disk is not encrypted, said in the plan whenever the source was protected), contract messages
  • the engine's third plan-token namespace, a simulation executor that runs the full flow against a folder-backed fake disk on any OS, and verification that separates "files in place" from "boot registered" (the latter is never claimed from file inspection). See docs/S5_NOTES.md. Honest limit: no real disk has ever been restored by this code — the Windows executor is a gated skeleton that renders the exact diskpart script and boot commands and refuses to run them; the on-machine restore session is listed precisely in those notes.
• An engine API over the shell contract with restore plan tokens: a restore executes only the exact preview that was confirmed, refuses stale plans, and writes nothing on refusal. Plus Level-2 File Rehearsal (sandbox restore + byte-compare).
• A headless CLI (safereturn-cli): init-volume, backup (with --snapshot <VOL> and --system-facts <file>), list-sets, verify, restore-set, restore-file, rehearse-file, media plan / media create (currently refused) / media verify, and restore-system plan / restore-system execute (with --simulate <folder>, the documented test path) / restore-system verify.
• A VSS requester spike: the documented Windows Volume Shadow Copy sequence as a tested state machine, plus a narrow C++ helper that talks to the real VSS API (safereturn-vss). Compiling that helper on Windows is verified by CI — see the note under Building.
• The shell ↔ engine message contract shared by the future WinUI 3 desktop app, the Win32 recovery shell for WinPE, and the CLI (safereturn-contract, with golden JSON fixtures).

License: MIT (see LICENSE).

Layout

crates/
  safereturn-contract/   Message types between shells and engine (+ golden fixtures)
  safereturn-core/       Encrypted chunk store, sets, verify, engine API, rehearsals
  safereturn-cli/        Headless CLI (init-volume, backup, verify, restore, rehearse)
  safereturn-vss/        VSS requester state machine + C++ helper (cpp/)
  safereturn-shell/      Recovery flow view-model
  safereturn-pe-shell/   WinPE adapter and native shell (runtime unverified)
docs/
  ARCHITECTURE_AND_UX_PLAN.md
  BACKUP_INTEGRITY.md
  S0_FINDINGS.md
  S1_S2_NOTES.md
  S3_NOTES.md
  S4_NOTES.md
  S5_NOTES.md
  SHELL_CONTRACT.md

Building

Requires a stable Rust toolchain. On any OS:

cargo fmt --all
cargo test --workspace

Windows-target compile check (works from Linux/macOS with the target installed via rustup target add x86_64-pc-windows-msvc):

cargo check --workspace --all-targets --target x86_64-pc-windows-msvc

The C++ VSS helper (crates/safereturn-vss/cpp/vss_helper.cpp) builds only on Windows against the Windows SDK (VssApi.lib). The Windows CI job compiles it on every push — that compile is the verification the S0 spike was designed to produce.