A Backup That Never Leaves Your House Isn’t a Backup

Everything you own is sitting in one room

If you run a homelab, you probably solved backups already. There is a NAS in a closet, a nightly job that copies everything to it, and a little green checkmark that says it worked. That is a real accomplishment and it is more than most people have.

It is also all in the same building. Which means one bad night takes out the original and the copy at the same time.

Down here that is not a hypothetical. A roof leak, a lightning hit that fries the whole rack through the ethernet, a break in, or four feet of water in a garage during a storm surge. Any one of those makes the NAS and the machines it protects disappear together. Same event, same room, same loss.

The rule, stated plainly

The old 3-2-1 rule still holds up. Three copies of your data. On two different kinds of media. One of them somewhere else.

Most homelabs nail the first two thirds and skip the last part, because the last part is the only one that costs money and takes effort. That is exactly why it is the one that matters.

I would add a fourth requirement that has become non negotiable: one copy that is normally disconnected or that the source machine cannot write to. Ransomware does not politely skip your backups. It looks for mapped drives and network shares and encrypts those too, and modern strains sit quietly for weeks first so your good copies age out before you notice. A copy your infected machine can reach is a copy your infected machine can ruin.

Option one: encrypted cloud, automated

This is what most people should do, because a backup that requires you to remember something will eventually stop happening.

Tools like restic, Kopia, or Duplicati handle the whole job: they chunk your data, deduplicate it, encrypt it locally before a single byte leaves the house, and only ship the changes after the first run. Point them at Backblaze B2, Wasabi, or an S3 bucket. For a typical lab holding photos, documents, VM configs, and a few years of project files, you are usually looking at a few dollars a month.

Three settings that turn this from decoration into a real backup:

Encrypt before upload, with a key you control. If the provider can read your files, so can anybody who gets into the provider.
Use application keys that cannot delete. B2 and S3 both let you create a key that can write new data but cannot destroy old data. Give your lab that key and keep the master key somewhere else. Now a compromised machine cannot wipe your history.
Turn on versioning or object lock. This is what saves you when the thing you backed up last night was already encrypted by malware. You go back two weeks instead of restoring the ransom note.

Option two: two drives and a car

Nothing wrong with a low tech version. Buy two external drives. Back up to one, then physically take it to a family member’s house, your office, or a safe deposit box. Next month you swap them.

The rules that make this work:

Encrypt the drive. VeraCrypt, LUKS, or BitLocker. A drive with your whole life on it is going to ride around in a car, and cars get broken into.
Label and date it. A drawer full of unlabeled black rectangles is not an archive, it is a puzzle.
Put the swap on the calendar. A recurring reminder on the same day every month. Without it you will discover your offsite copy is fourteen months old on the worst possible day.

The nice thing about drives is that they are genuinely disconnected. No credential on any machine in your house can touch them.

Now the part nobody does

Backups are not the goal. Restores are the goal. A backup job is a claim, and a restore is proof, and I have watched plenty of confident green checkmarks turn out to be backing up an empty folder for eight months.

Two habits, and neither takes long:

Monthly single file restore. Pull one file out of the offsite copy at random, open it, confirm it is the real thing. Five minutes. Do it from a machine that is not the one that made the backup.
Yearly full restore drill. Rebuild something real from nothing but the backup. A VM, a database, your document share. Time it. That number is your actual recovery time, and it is usually a lot bigger than the one in your head.

Bonus points if you also verify that you can still get to the key. A perfectly encrypted offsite backup whose passphrase lives only on the dead laptop is a very tidy way to lose everything.

Make it tell you when it fails

Here is the failure I see most, and it is silent. The backup job breaks in March. Nothing alerts. Everything looks normal because nothing looks like anything. You find out in September when you actually need it.

Every scheduled job should check in when it finishes. Point it at a dead man’s switch service or your own monitoring, so that no news triggers an alert instead of meaning everything is fine. The rule I hold myself to: a scheduled job without a heartbeat is not finished, no matter how well it ran the day I built it.

Decide what actually needs to go

You do not need to ship 8TB of Linux ISOs to the cloud. Sort your data into two piles.

Things you can rebuild: media libraries, OS installs, containers you can pull again. Keep those local and do not pay to store them twice.

Things that only exist because you made them: photos of your kids, tax documents, scanned records, source code, config you spent a weekend tuning, the password vault. That pile is usually far smaller than people expect, often under 500GB, and that pile is what leaves the building.

Do the first upload tonight

Pick the irreplaceable folder. Install restic or Kopia. Point it at a bucket. Let it run overnight. Tomorrow you will have something you have never had before, which is a copy of the stuff that matters sitting somewhere a fire cannot reach.

Then next month, pull one file back out and open it. That is the part that turns it into a backup.

We build this same setup for businesses between Delray Beach and West Palm, with the testing schedule included, because an untested backup is just a feeling. Always happy to troubleshoot.