Kyber Cypher v003/v002/v001 KC//NODE-01 00:00:00:00

Backups that actually work

Field Log // 007 Status Live Difficulty Low Cost A second drive
The Story

Everybody has backups until the first day they need one. That's when they find out the drive was unplugged in March, or the folder they cared about was never in the job, or the whole thing has been quietly writing nothing for months. A backup you have never restored is not a backup. It's a wish.

Here's the part nobody wants to hear: the copy is the easy half. Any tool can copy files. The hard half, the half that actually saves you, is proving you can get the files back. If you have never once done a restore, you don't have a backup system, you have a folder you feel good about.

One drive is a countdown. Every drive you own is a clock ticking toward the day it stops, and it will not warn you first. So the whole game is simple: make sure the thing you care about lives in more than one place, and make sure at least one of those places is not in your house, because a house can flood or burn or get robbed all at once.

The only rule you need to remember

Three copies of anything you'd hate to lose. On two different kinds of storage. One of them somewhere else entirely. That's it. Three, two, one. The photos that can't be re-taken and the documents that can't be re-made are the whole target, and they're smaller than you think.

The one that hurts: the copy that lives next to the original doesn't count for much. If a power surge, a bad drive controller, or a thief takes the machine, it takes the neighbor drive with it. The copy that saves you is the one that was somewhere else when the bad thing happened.

Now the part where I found out mine was lying

For a while my "backup" was a copy job to a second drive, running on a schedule, reporting success every night. Looked perfect. Then I actually tried to pull a file back from three weeks earlier and learned it only ever kept the latest copy, so the ransomware-style "everything got encrypted and then backed up over the good version" scenario would have wiped me out silently. It was faithfully backing up the damage.

The fix was a tool that keeps versions and can prove each one, plus a monthly habit I now refuse to skip: pick a random file, restore it from last month, and open it. If that works, I have a backup. If it doesn't, I'd rather find out on a boring Tuesday than on the worst day of the year.

The Build

A real backup for the files you can't re-make: versioned, encrypted, in three places, and tested. Runs from any always-on machine. Replace every value in angle brackets with your own.

1. Decide what you'd actually cry over

Not the whole disk. The stuff that can't be downloaded again: photos, documents, keys, the config for the things you built from these logs. List those folders. A small, correct backup beats a giant one you never verify.

# the target is small on purpose. write it down:
<path-to-photos>
<path-to-documents>
<path-to-configs>

2. Use a tool that keeps versions

Not a plain copy. Use a backup tool that stores every snapshot, de-duplicates so history is cheap, and encrypts before anything leaves the machine. That versioning is what saves you from "the good file got overwritten by a bad one and then backed up."

# initialize an encrypted, versioned repo on your second drive
restic -r <second-drive-path> init
# back up the folders from step 1
restic -r <second-drive-path> backup <path-to-photos> <path-to-documents>

Source: restic.net, or borgbackup.org. Both are free, encrypted, and versioned.

3. Get one copy out of the house

This is the "1" in 3-2-1. Send the same encrypted repo to somewhere off-site: cheap object storage, or a drive you keep at work or a relative's place and rotate. Because it was encrypted on your machine in step 2, the off-site host only ever sees scrambled blocks.

# same tool, a second destination that isn't in your home
restic -r <offsite-repo> backup <path-to-photos> <path-to-documents>
# it's encrypted before it leaves, so the host can't read it

4. Put it on a schedule

A backup you have to remember is a backup you'll forget. Run it automatically, keep a sensible history (say daily for a couple weeks, then weekly), and let the tool prune the rest so it doesn't grow forever.

# a nightly timed job that backs up, then prunes old snapshots
restic backup <paths> ; restic forget --keep-daily 14 --keep-weekly 8 --prune

5. THE STEP EVERYONE SKIPS: restore it

Once a month, restore a random file from an old snapshot to a scratch folder and open it. This is the only step that proves the other four worked. Everything above is a wish until you've watched a real file come back out.

# prove it. restore one file from last month and open it.
restic -r <repo> restore <old-snapshot> --include <one-file> --target <scratch-dir>
# if it opens, you have a backup. if not, you found out on a good day.

That's a backup that will actually be there. Three copies, two kinds of storage, one off-site, and a restore you've personally watched work.