Thoughts

Backups for a sprawling home infrastructure: the 3-2-1 strategy

← All thoughtsHomeAI markdown

At some point your homelab or remote infra stops being a hobby and becomes something you can’t afford to lose.

For me that was when Serenity, the CRM that runs Vent Busters, went from project to system. Customer records, booking history, job data, invoices. Real business data that doesn’t exist anywhere else. If the server dies and I’ve got no backup, the business has a problem.

I run Proxmox on a dedicated server, Coolify for app hosting, Postgres for most databases, and a pile of services that accumulated over the years. Tutorbin lives here. The ventbusting.com deployment pipeline runs through here. All of it needs backing up, and “I think there’s a cron job somewhere” isn’t a strategy.

Before this was a system

Before Kopia I used whatever the platform of the week offered. S3 for a couple things. A thumb drive for others. I’d manually copy documents and projects to an external drive when I remembered. Casual at best. Google Drive for the stuff that felt important that month.

That worked until the home lab, the production boxes, and Vent Busters all started eating real time. Past a certain point you are not “throwing things on Google Drive.” You need something automated that you can actually set up and leave alone.

Why I take the offsite copy seriously

Around 2014 I helped with a mess at a company in Greensboro. They ran Citrix so people could hit workstations remotely. The real server sat in a closet next to the men’s room. Twenty years of customer records, transactions, claims, the whole business, sitting in an Access database and flat files.

One evening the owner couldn’t get into his own account, so he logged in as admin. He was trying to find a part for a friend’s old Maytag washer, landed on a bad site, clicked through a few popups, and in a hurry installed ransomware. As admin. On the server that held everything.

Next morning nobody could log in. The closet machine had the usual message: pay $50k in bitcoin to this address or the data is gone.

They had a backup that ran every night. It lived on the same server that was now locked.

I got the data off the drive. Shut the box down, pulled the disk, mounted it on another machine so the ransomware wasn’t running, and copied what was still readable. The lesson stuck harder than the recovery did. A backup that shares fate with the original is not a backup. It is a second copy of the same failure.

The 3-2-1 rule

Three copies of the data: the live stuff plus two backups. Two different kinds of storage, so one dead drive does not take everything. One copy offsite, because fire, flood, or theft does not care that your local backup was “working.”

Two drives in the same machine technically counts as two media. Two drives on the same power strip in the same room that floods together does not. In practice I want local plus cloud, or local plus a different building.

Local is for speed when I need a file back today. Offsite is the insurance policy. After Greensboro, I stopped pretending those are the same job.

Why Kopia

I use Kopia. Open source, Linux or Windows, encrypted and deduplicated, talks to S3-compatible storage, Backblaze B2, rclone destinations, and more.

Encryption happens on my side before anything leaves the machine. The storage provider does not get to read the contents. Deduplication is why daily runs stay short. You are not shoving the full pile every night, just what changed.

CLI for the scheduled jobs. UI when I want to poke around a repository or verify something by hand.

What actually gets backed up

Postgres first. I pg_dump before each run so Kopia gets a clean dump instead of live database files mid-write. One dump per database. Lose a VM and I can rebuild it. Lose the database and Vent Busters has a much worse day.

Coolify app data next: config, persistent volumes, anything that does not come back clean from a git deploy.

On Proxmox I care most about VM config. Full images for every app are huge, and most of the apps are reproducible from git anyway. The data is not.

Infisical gets its own treatment. Self-hosted secrets store, backed up separately, extra paranoia about where that backup lands. More on that in secret management for AI agents.

Local destination is a dedicated server at my office writing to 4TB external drives, more as things grow. Offsite is Backblaze B2. Both through Kopia, both encrypted. Local runs daily. B2 follows right after.

For what I push, the B2 bill is basically nothing. Less than $20 a year. B2 is friendly to homelab scale and still prices up if you ever need it. Daily runs across my servers take a few minutes most nights, longer when a lot changed. That is the dedup doing its job.

Test the restore, not just the backup

A backup you have never restored from is a belief.

I have watched that belief fail: backups “running” for months, something breaks, restore does not work. Incomplete snapshot. Decryption key nobody can find. A step nobody ever practiced.

I test restores. Not every week, but often enough that I am not guessing. Can I reach the repository? Can I decrypt it? Can I pull a specific database back to a point in time? Does what came back look like what I expect?

If any of those is “I’m not sure,” it is not a backup yet. It is a cron job with good intentions.

Starting from nothing

If you are running your own servers, even one machine or one VPS, 3-2-1 is still the right starting point. Tools are free. B2 at my scale is pocket change. Kopia is not hard to stand up.

You find out what you had after it is gone otherwise. I would rather not learn that twice.


I run Kopia and Backblaze B2 across my infrastructure. Both have free tiers that cover most personal setups. If you’re starting from nothing, that’s the combination I’d use.