3-2-1 is the rule everyone quotes. Three copies of your data, on two different media, with one offsite. It is a good floor and it is easy to think you have cleared it when you have not.
I counted my copies earlier this year and got five. Primary NAS (NAS1), secondary NAS (NAS2), a cold box, a drive at the office, and OneDrive. Comfortably past the bar. Then I counted what could fail independently and got roughly two and a half.
Copies are not fault domains
The problem is that 3-2-1 counts copies, and copies are the wrong unit. What matters is how many distinct ways your data can die, and how many of those each copy actually survives.
NAS2 replicates from NAS1 continuously. That protects me from a drive failing, or the primary unit dying. It protects me from nothing else. A deletion propagates in seconds. So does ransomware encryption, and so does silent corruption. Always-on replication is an uptime feature wearing a backup’s clothes.
The cold box is a genuine second copy, but it is reachable during a sync, so a bad actor with the right access reaches it too. OneDrive covers documents and photos and nothing else. Which left the drive at the office as the only copy that survives losing the house, and I refresh it roughly every two months.
That last number is the whole story. In a site-loss event, my recovery point is whatever date is on that drive. Worst case is eight weeks of loss. Average at a random moment is about a month. My stated goal was “never lose more than a month,” so I was meeting it by luck, with no margin.
Split the dataset before you fix anything
The instinct is to back up everything harder. That is expensive and it is the wrong move, because the data is not one thing.
Roughly 15 TB of mine is media. It barely changes. A copy that is eight weeks old is not stale, because the source has not moved either. The exposure is concentrated in a much smaller slice that changes weekly: documents, photos, project files, configuration, VM state.
Once you see it that way the strategy splits cleanly. Bulk static data wants cheap capacity and a slow cadence. The changing subset wants automation, frequency, and somewhere the house cannot take with it. Trying to apply one policy to both gets you an expensive plan you will not follow.
Media: stale is fine
Media lives on NAS1, replicates to NAS2, and has a third copy on a cold Unraid box. The office drive carries it too, and being two months behind on files that have not changed in two years costs nothing.
What I will not do is put 15 TB in the cloud. I went looking for a one-time-fee option and there is exactly one permanent-payment provider in the market, Arweave, at somewhere between $294,000 and $455,000 for 15 TB, with data that is public and undeletable by design. Cloud storage is rent. The only genuine one-time payment for bulk storage is buying disks.
Recurring cold storage is affordable in isolation, roughly $330 a year on OVHcloud Cold Archive with free egress, but retrieval is where archive tiers bite, and for replaceable media it is not worth it.
The Proxmox cluster
Proxmox Backup Server runs as a VM on NAS2, holding 30 restore points for every guest in the cluster. My guess before measuring was somewhere in the terabytes. The actual datastore is 242 GB.
PBS deduplicates at the chunk level, and thirty restore points of slowly-changing Debian containers are almost entirely the same chunks. Capacity turned out to be a non-issue. Which was useful, because it meant the real risk was somewhere else entirely.
PBS ran on the NAS2 and its datastore lived on that same NAS. One unit failure would have taken the backup server and every restore point for the whole estate in a single event. Not a site-loss scenario, just a one-box scenario, and the only thing standing behind it was an office drive two months stale.
The second PBS, and why it pulls
The fix was a second PBS instance on gollum, one of the other nodes, with a 1 TB USB SSD as its datastore. Different room, different UPS, different failure domain.
Two decisions in there matter more than the hardware.
It pulls, it does not push. The secondary reaches out to the primary on a schedule and takes what it needs. Nothing on the primary has credentials for the secondary. If the primary is compromised, the attacker gets no path to the copy. A push architecture hands them both.
Vanished snapshots are not removed. If something deletes backups on the primary, whether that is ransomware or me at 1am, the secondary keeps its own copies until its own retention decides otherwise. A sync that faithfully mirrors deletions is a very efficient way to lose everything twice.
It syncs at 22:30, prunes at 02:30, and runs garbage collection at 03:30 — deliberately after the prune, so GC actually reclaims what the prune released. Verification runs Sunday mornings. I restore-tested it before trusting it, which is the only reason I am willing to describe it as working.
A third PBS that goes with me
I run a third PBS on my laptop (as a docker container), which I usually take with me everywhere. It follows the schedule of the second PBS, but with a 1 hour difference. It backs up to an external USB SSD that I also keep in the office.
Workstations, and the 465 GB that was actually 19 GB
The desktops back up nightly to the NAS with restic over NFS, encrypted, with restore tests and a proper systemd timer.
The useful discovery was the size. My root filesystem showed 465 GB used, which sounded like an expensive backup. The actual backup set is about 19 GB. Steam accounted for 245 GB, caches for 51 GB, and downloaded model weights for another 29 GB. All of it re-downloadable, none of it worth a single byte of backup storage.
What is left compresses to about 44%. A cold run takes 69 seconds on 10 GbE. An incremental takes under ten. Once you have excluded the things that are large and replaceable, workstation backup stops being a capacity problem and becomes a scheduling one.
One thing I got wrong and only caught by checking: the timer had never actually fired. Every test I had run was a manual invocation with sudo, so I had proven the command worked and proven nothing about the automation. Verifying through systemd is a different test from verifying the thing systemd runs.
“If you fail to plan, you plan to fail”
Offsite, and why cadence beats discipline
The office drive is 16 TB, refreshed manually, and honest about it: “roughly every two months” is what a task with no schedule turns into.
The temptation is to fix that with resolve. Do it monthly. Put it in the calendar. That has never worked for anything and it will not work here, because the two-month drift is the measurement. A manual task on a long rhythm always slips, and the recovery point slips with it.
The better answer is to stop asking the office drive to be the guarantee. Let it carry the bulk static data, where being weeks behind is genuinely fine, and give the changing subset an automated path that involves no human at all. Two drives rotating instead of one also removes the “the single unverified disk I needed did not spin up” scenario, which is a small change for a meaningful reduction in risk.
However, with the AI RAM-ageddon spreading to NVME and spinning disks, the cost for a second 16 TB drive is too crazy for me to even consider. So its a risk I’m going to have to put up with.
Cloud: smaller than it sounds
My cloud leg is Synology Cloud Sync pushing documents and photos to OneDrive. That is it. It is a real offsite copy of the data I would grieve, and it is nowhere near the whole picture.
Sync is not backup for the same reason replication is not backup, so it depends entirely on whether it runs one-way with destination deletes disabled, and on the version history behind it. Second, the entire Proxmox estate is not in it.
That has a cheap answer that I have costed and not yet built. 242 GB on Backblaze B2 is about $1.60 a month, no minimum, free egress up to three times what you store. Twenty dollars a year to put every restore point in the cluster somewhere the house cannot reach. It is the single cheapest meaningful upgrade available to me and it is still sitting on the list.
Two traps I found while costing it, which are worth knowing before you try:
- Do not point archive tiers at a PBS datastore. Glacier Deep Archive would be 24 cents a month, but PBS churns constantly — garbage collection deletes chunks daily — and a 180-day minimum retention charges you for every deleted chunk for months it did not exist. Archive tiers are for write-once data
- Do not rclone a chunk store to object storage. It is millions of small files. A naive sync means millions of API calls and never finishes cleanly. Use PBS remote sync to a second PBS, or snapshot the filesystem and back up the snapshot
What I decided not to do
PBS client-side encryption is off, deliberately. The datastore never leaves hardware I control, and I judged the NAS secure enough for my threat model. The consequence, which I wrote down rather than left implicit, is that backups are readable at rest — including a secrets manager’s encryption key. That is an accepted risk, not an oversight, and the distinction only exists because it is recorded somewhere I will find it again.
I would rather have three things I have restore-tested than six I have merely configured. An untested backup is a hope with a cron entry.
Where it actually stands
The one-box risk is closed. The cluster has two independent PBS instances in different rooms on different power (and separate UPS’s), with a pull-based sync and a restore test behind it. Workstations back up nightly and have been restored from. Media has three local copies and a fourth at the office.
The gap that remains is the same one I started with, just smaller and better understood: everything except documents and photos depends on a manual drive with a two-month rhythm. Twenty dollars a year fixes the important half of that.
3-2-1 was never the goal. It is a way of asking a better question, which is: name every way this data can die, and for each one, point at the copy that survives it. Do that honestly and the number of copies stops mattering; the number of answers is the only thing that does.
Leave a Reply
You must be logged in to post a comment.