Free while we’re in preview

Get RescueVault

Timestamped snapshots you can browse, where unchanged files cost no extra disk.

The Mac button is for Apple Silicon. On an older Intel Mac, get this one instead.

One file, both ways. Double-click it for the window. Run the same file from a command prompt with arguments and it behaves as the command-line tool, because the engine is inside it. Nothing else to download and nothing to keep beside it.

Early preview. The window has been built and run, but not yet on a real Windows PC or Mac, so expect rough edges. The engine underneath it is fully tested.

One file — no installer
Runs on your machine, offline
Source code published below

Free while in preview. It isn’t signed yet, so Windows or macOS will ask you to confirm the first time you open it. At launch, RescueVault is included in every plan along with the rest of the range.

How a snapshot stays cheap

Every backup run creates a new folder under <vault>/snapshots/<timestamp>/ holding a complete, browsable copy of your source tree. Files unchanged since the previous snapshot are hardlinked to it rather than copied, so twenty snapshots of a mostly static folder cost about one copy plus the changes. It’s the mechanism behind rsync --link-dest and Time Machine.

“Unchanged” here means same size and same modification time. Contents are not hashed, on purpose: hashing everything on every run turns an incremental backup back into a full read of the tree. The gap that leaves is a file whose content changed while both size and mtime stayed exactly as they were, which normally takes deliberate tampering.

Pruning, and getting files back

list shows each snapshot’s file count and its new bytes, meaning what it really copied, read from a manifest written at backup time. prune --keep N removes everything older than the N newest. That’s safe because deleting a directory entry only frees the data once the last link to it is gone, and your kept snapshots still hold theirs.

restore writes real byte copies, never hardlinks, so a restored tree shares no inodes with the vault.

Every command is a dry run until --apply. For retention that thins with age instead of keep-last-N, that’s RestoreGuard.

Reading on the job itself

How to check whether your backup would actually restore Restore something. Not the whole thing — pick a file you know the contents of, restore it somewhere harmles...

The rest of Backup + Rescue

Backups you can actually rely on. Check the copies exist, keep snapshots, prune them by rule, and spot the job that quietly stopped running.

SafeMirror

Vertical Ready

Audits the backups you already have against the 3-2-1 rule, one file at a time.

RestoreGuard

Pro Ready

Keeps yesterday's snapshots by the hour and last month's by the week.

BackupMedic

Team Ready

Which backup jobs quietly stopped working, and how long ago they last succeeded.

Advanced & technical details Command-line builds, source code, checksums and a recorded session — for developers and IT teams

A working CLI prototype of the backup engine: hardlink-deduplicated incremental snapshots (unchanged files are hardlinked, not recopied), with list/prune/restore. Disk imaging, boot rescue, and SMART-based recovery scans need raw-device access and are on the roadmap.

Naming status

Working name only — brand verdict **AVOID** (Very High). Collision: RescueVault. Rename completely.

What it draws on

Existing paid software whose best ideas shaped this program: Macrium Reflect X, Disk Drill, R-Studio, Bvckup 2 Pro.

Command line

There is nothing extra to install. The program you download is the command-line tool as well: give it arguments instead of double-clicking it and it runs as one, with its output on your terminal. The standalone builds below are the same engine on its own, for machines where you would rather not ship a window at all.

rescuevault - hardlink-based incremental snapshot backup

Usage:
  rescuevault backup <src> <vaultdir> [--apply]
      Create a new snapshot of <src> under <vaultdir>/snapshots/<id>/.
      Files unchanged since the previous snapshot (same size + mtime) are
      hardlinked, not copied. Without --apply this is a dry run: prints
      what would happen and does not touch disk or create any directory.

  rescuevault list <vaultdir> [--json]
      List snapshots in <vaultdir> with file counts and "new bytes"
      (bytes actually written by that snapshot, excluding hardlinks).

  rescuevault prune <vaultdir> --keep N [--apply]
      Keep the N most recent snapshots, remove all older ones. Without
      --apply this is a dry run. Safe by design: removing an older
      snapshot directory only removes directory entries, never the
      underlying file content still referenced by a hardlink in a
      newer, kept snapshot.

  rescuevault restore <vaultdir> <snapshot-id> <destdir> [--apply]
      Copy every file from a snapshot into <destdir> as real byte
      copies (never hardlinks back into the vault). Without --apply
      this is a dry run.

  rescuevault help | -h | --help
      Show this message.

Recorded from the shipped binary, not written by hand.

Windows (amd64) macOS (Apple Silicon) macOS (Intel) Linux (amd64)

Source

Every file the program is built from:

console.go · console_test.go · guided.go · main.go

SHA-256 checksums · build instructions & scope notes · full build plan

RescueVault

Preview