one backup means zero backups

one backup means zero backups

you set up a backup job six months ago. it ran once, you saw the green checkmark, and you moved on with your life. congratulations, you have a single point of failure with extra steps. one backup isn't a backup strategy, it's a snapshot of a moment in time that's getting staler every day you don't check on it.

the whole point of a backup is that it exists when you need it, not that it existed once. those are very different things, and the gap between them is where people lose photos, databases, and entire homelabs.

the command that keeps you honest

if you're running restic, this one line tells you the truth:

restic snapshots | tail -1

let's break it down.

restic snapshots lists every snapshot in your repository, oldest first. each line shows a snapshot id, the timestamp it was taken, the hostname, and the paths it backed up.

| tail -1 pipes that output into tail, which grabs just the last line. since the list is chronological, the last line is your most recent snapshot.

run it and actually look at the date. not "yeah that looks recent," look at the actual timestamp. if it says three weeks ago and you thought your backups ran nightly, you just found a problem before it found you.

why "it ran once" is worse than "it never ran"

a backup that never ran at least gives you honest dread. you know you're exposed. a backup that ran once and then quietly stopped gives you false confidence, which is more dangerous. you'll skip double checking things, you'll delete local copies of files thinking they're safe elsewhere, and you'll find out the truth at the worst possible moment, usually right after a drive dies or ransomware chews through your files.

cron jobs fail silently all the time. a script errors out, a mounted drive disconnects, an api key expires, a disk fills up. none of that sends you a text message unless you built one to send it.

check more than just "did it run"

timestamps are step one. here's what else to actually verify:

restic check

this verifies the integrity of your repository, checking that the data structures are consistent and nothing's corrupted. run it periodically, not just after a scare.

restic snapshots --group-by host

if you're backing up multiple machines, this groups the output so you can confirm every host is actually checking in, not just the one you remembered to look at.

and at least once, actually restore something. pick a random file, pull it out of a snapshot, and confirm it opens and isn't garbage.

restic restore latest --target /tmp/restore-test --include /path/to/file

an untested restore is a theory, not a backup.

build in the redundancy

the "one backup is zero backups" rule really means: one copy, one location, one method, is a single point of failure no matter how good the tool is. the fix isn't fancier software, it's basic redundancy:

keep backups in at least two different locations, ideally one offsite or cloud based and one local. use two different failure domains, meaning don't put your only two copies on drives from the same manufacturer bought the same week, plugged into the same power strip. and automate the verification, not just the backup. a simple cron job that emails you if the latest snapshot is older than 24 hours will save you from ever finding out the hard way.

last_snapshot=$(restic snapshots --json | jq -r '.[-1].time')

wrap that in a script, compare it against the current date, and alert yourself if it's stale. five minutes of setup now versus a very bad day later.

the takeaway

backups aren't a checkbox you tick once, they're a system you maintain. run restic snapshots | tail -1 right now, check the date, and if it's not what you expect, fix it today instead of finding out during an actual disaster. redundancy, verification, and tested restores are what turn "i have a backup" into "i actually have a backup." everything else is just hope with a cron schedule.