BackupMedic
Which backup jobs quietly stopped working, and how long ago they last succeeded.
Free right now — no account, no card
Preview
1 interface design, then a screenshot of it running. Drag, scroll or use the arrows.
Free while we’re in preview
Get BackupMedic
Which backup jobs quietly stopped working, and how long ago they last succeeded.
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, BackupMedic is included in every plan along with the rest of the range.
It’s Monday. Every machine ran its backup overnight. Which ones are lying to you?
Every job calls backupmedic record --machine nas01 --job nightly --status ok --bytes ... when it finishes, appending one line to a shared history file on a NAS or a synced folder. No agent, no server, no port. Then backupmedic health --history ... --rpo 24h reads that file and gives each machine-and-job pair a verdict.
NEVER-SUCCEEDED means there’s nothing to restore from at all. FAILING means the last run didn’t fully succeed. LATE means the last success is older than the recovery point you promised. SILENT-SHRINK means the newest good run came out more than 40% smaller than the one before it, which is what a job writing an empty archive looks like from the outside.
Health exits 2 when anything isn’t HEALTHY, so || mail ops@example.com in cron is the entire alerting story today.
Read this before you rely on it. BackupMedic tracks what jobs report. It never opens a backup, hashes it, mounts it or restores from it. A job that writes a truncated image and reports “ok” gets called HEALTHY. It’s a smoke alarm, not a fire inspection.
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...
RescueVault
Simple ReadyTimestamped snapshots you can browse, where unchanged files cost no extra disk.
SafeMirror
Vertical ReadyAudits the backups you already have against the 3-2-1 rule, one file at a time.
RestoreGuard
Pro ReadyKeeps yesterday's snapshots by the hour and last month's by the week.
Advanced & technical details Command-line builds, source code, checksums and a recorded session — for developers and IT teams
A working command-line build of the health engine: an append-only run history, age measured against a stated recovery objective, consecutive-failure streaks, and silent-shrink detection for the night a backup quietly gets much smaller. It reports what jobs themselves report; proving a backup actually restores is a separate job, on the roadmap.
Naming status
Working name only — brand verdict **CAUTION** (Medium-Low). Collision: BackupMedic. Promising if formal clearance is clean; alternate domain is fine.
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.
backupmedic 1.0.0 - fleet backup-job health against an agreed RPO
BackupMedic does not make backups and does not look at your files. Backup jobs
append one record per run to a shared history file; BackupMedic answers, for
every machine and job: when did it LAST SUCCEED, is that inside the recovery
point objective we promised, is it failing silently, and has its output
suddenly shrunk?
USAGE
backupmedic record --machine <name> --job <name> --status ok|failed|partial
--bytes <n> --history <history.jsonl>
[--started <RFC3339>] [--finished <RFC3339>] [--note "..."] [--json]
backupmedic health --history <file> [--rpo 24h] [--window 10]
[--size-drop-pct 40] [--fail-streak 1] [--asof <RFC3339>] [--json]
backupmedic history --history <file> [--machine X] [--job Y] [--last N] [--json]
backupmedic summary --history <file> [--rpo 24h] [--asof <RFC3339>] [--json]
backupmedic help | -h | --help
backupmedic version
COMMANDS
record Append one immutable run record. This is what a backup script calls
when it finishes. The only command that writes anything, and it only
ever appends to --history.
health Per machine+job: last successful run and its age, whether the RPO is
breached, the current consecutive-failure streak, the success rate
over the last --window runs, and the trend in backup size.
history The raw run records, filterable by machine, job and recency.
summary The one-screen fleet answer: healthy vs breaching, worst offender,
and total protected bytes across the fleet.
FLAGS
--history PATH Shared JSONL history file. Required by every command.
--machine NAME Machine the job ran on.
--job NAME Job name, unique per machine.
--status S ok, failed or partial (record).
--bytes N Bytes this run wrote or copied (record, required).
--started TS RFC3339 start time. Default: --finished.
--finished TS RFC3339 finish time. Default: now.
--note TEXT Free text stored with the run.
--rpo D Recovery point objective, e.g. 24h, 90m, 168h. Default 24h.
...Recorded from the shipped binary, not written by hand.
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