The 3-2-1 backup strategy means keeping three total copies of your data, stored on two different types of media, with at least one of those copies kept somewhere other than the machine, or the building, holding the original. It isn’t a product or a piece of software, it’s a decades-old rule of thumb, and it still holds up because the failures it protects against, a dead drive, a ransomware infection, a fire, a stolen NAS, a fat-fingered delete, haven’t gone anywhere. Applied to a homelab, it’s the difference between “my data lives on a NAS” and “my data survives losing that NAS.”
The short version: the live data on your NAS or server is copy one. A second copy on a different disk or device, an external drive, a second pool, another machine entirely, is copy two. A third copy stored somewhere physically separate, cloud object storage or a drive at someone else’s house, is copy three. A RAID array is not one of the three copies. Neither is a snapshot sitting on the same pool as the data it protects.
What the 3-2-1 rule actually means for a homelab
Mapped onto a typical setup, the three numbers translate cleanly. The “3” is the live data plus two additional copies, not three copies total including the original counted twice. The “2” means two genuinely different types of storage, not the same NAS split into two folders. And the “1” means at least one of those copies physically leaves the location where the homelab lives, so a fire, flood, break-in, or a stolen box doesn’t take every copy down at once. None of that requires enterprise tape libraries or a second data center; for most homelabs it’s a NAS or server holding the live data, a second target on different media for the local backup, and a tool like Duplicati or Kopia shipping an encrypted copy offsite on a schedule.
Is RAID a backup?
No. RAID, whether that’s a ZFS pool on TrueNAS or a parity array on Unraid, protects against a drive failing, not against the things that actually destroy backups: ransomware encrypting every file it can reach, an accidental delete on the wrong path, a burst pipe over the NAS, or someone walking out the door with the whole box. Every one of those takes out a RAID array exactly as easily as it takes out a single disk, because RAID doesn’t put a copy of the data anywhere else. It just makes the one copy already there less likely to disappear because of a single failed drive. RAID has a bit of a branding problem in that sense: the name sounds like protection, so it’s easy to stop there and assume the job is done. Our TrueNAS vs Unraid comparison covers how ZFS pools and parity arrays actually work under the hood, useful background, but neither one is a backup strategy on its own.
Are snapshots a backup?
Closer, but still no on their own. A snapshot, ZFS, Btrfs, or whatever a NAS vendor built on top of one of them, freezes the state of a dataset at a point in time and lets you roll a file, a folder, or the whole thing back to how it looked before something broke. That’s genuinely useful: it turns “I deleted the wrong folder” from a disaster into a two-minute rollback. What it doesn’t do is get the data off the box it’s already sitting on. A snapshot living on the same pool as the data it protects disappears in exactly the same events that take out the data itself, hardware failure, theft, fire, or ransomware that specifically targets snapshot metadata, which real-world attacks have done. Snapshots are a solid first line of defense and a poor last one.
Why one NAS is one point of failure
However many drives it holds and however well its array is configured, a single NAS is still one physical device sitting in one location, on one power circuit, behind one router. It doesn’t satisfy the “2” different media types, and it can’t satisfy the “1” offsite copy, because everything on it lives in exactly one place. A homelab whose entire backup plan is internal snapshots on that same box hasn’t really backed anything up. It’s built a single point of failure with extra steps.
Building the three copies, concretely
- Copy one, the live data. Whatever’s actually running: files on a NAS share, a database backing a self-hosted app, a Nextcloud data folder, an Immich photo library.
- Copy two, a second copy on different media. An external USB drive, a second internal pool on separate hardware, or a completely different machine, synced or backed up on a schedule rather than mirrored in real time.
- Copy three, stored somewhere physically separate. Cloud object storage or a drive sitting at a relative’s house are the two most common homelab answers, covered below.
Two different media types, in practice
“Different media” is doing real work in that sentence. Two pools on the same NAS chassis share a single power supply, a single motherboard, and a single point of physical risk, so they’re a weak version of “two media” even if they technically sit on separate drives. A truly different medium looks like an external drive that isn’t plugged in permanently, a second machine entirely, or cloud object storage, which counts as a different medium by definition since it isn’t local hardware at all. The goal is making sure whatever kills copy one, a controller failure, a firmware bug, a bad update, doesn’t have a plausible path to killing copy two as well.
The offsite copy: cloud storage, a friend’s NAS, or both
Cloud object storage, S3-compatible services like Backblaze B2 among them, is the most common offsite target for homelabs, mostly because it’s built for exactly this: durable storage reachable from anywhere, priced by the gigabyte, with no hardware to maintain on the user’s end. The alternative is a physical drive or a small NAS at a family member’s or friend’s house, syncing over the internet; the cost there is a hard drive and someone else’s spare closet space rather than a recurring bill. Neither option is inherently better. A cloud target is easier to automate and less exposed to a shared regional disaster, while an offsite personal NAS means full control over the hardware and no ongoing fee. Whichever gets picked, encrypting the data before it leaves the homelab matters, since the destination is, by definition, somewhere with less physical control than the original box.
Worth knowing about: some backup vendors, Veeam among the most vocal, promote an extended version of the rule called 3-2-1-1-0: the same three copies and two media types, plus one copy that’s immutable or air-gapped, meaning nothing, not even an attacker with valid credentials, can alter or delete it during a set retention window, and zero errors on a tested restore. It’s aimed mostly at businesses, but the immutable-copy idea translates directly to a homelab. Object storage with object-lock support, the kind covered on the Kopia page’s ransomware-protection notes, gets a homelab most of the way there without extra tooling.
Duplicati and Kopia: covering the offsite leg
Duplicati and Kopia both solve the same core problem for the offsite leg of 3-2-1: encrypted, incremental backups shipped to a destination that isn’t the homelab itself. Either one on its own is enough to satisfy the “1” in a homelab’s 3-2-1 setup; running both isn’t necessary for most people, picking one and actually using it consistently matters more than which one gets picked.
| Role in a 3-2-1 setup | Duplicati | Kopia |
|---|---|---|
| Best fit | A single job, one homelab, widest choice of destinations out of the box | Multiple machines backing up to one shared, deduplicated repository |
| Setup effort | Web UI, no terminal required | Web UI (KopiaUI) or CLI, both from the same codebase |
| Ransomware resistance | Encrypted at rest; retention rules limit exposure | Optional object-lock immutability on supported backends |
| Where it falls short | Restore speed lags on very large datasets | Smaller list of prebuilt destination integrations |
In practice, the choice mostly comes down to how many machines need to share one offsite target. A single NAS shipping one dataset to Backblaze B2 doesn’t gain much from Kopia’s cross-machine deduplication, and Duplicati’s web UI gets that job done with less setup. A homelab with a NAS and a couple of other machines all backing up to the same bucket is exactly the case Kopia’s repository model was built for, since every client dedupes against the same storage without needing a dedicated backup server.
Where Watchtower fits, and where it doesn’t
Watchtower isn’t a backup tool, worth saying plainly since the two categories, “keeping data safe” and “keeping containers current”, both end up on the same homelab-maintenance checklists. Where it’s tangentially relevant is after a recovery: once a server has been rebuilt and its containers pulled back from a Duplicati or Kopia backup, whatever images shipped in that backup are frozen at whatever version they were on the day of the backup job, and a tool that flags or updates outdated images matters more right after a rebuild than on an ordinary week. One more thing worth flagging: Watchtower’s own repository was archived in December 2025. It still runs exactly as before, but a fresh deployment is a good moment to look at an actively maintained, notify-only alternative instead of leaning on an unmaintained one long-term.
A simple 3-2-1 setup for a typical homelab
Put together, a realistic homelab version looks something like this: a NAS running TrueNAS, Unraid, or OpenMediaVault holds the live data as copy one, with its RAID or parity array there purely to reduce downtime from a single drive failure, not to serve as a backup. A scheduled Duplicati or Kopia job then copies that data to an external drive or a second machine on the network for copy two, on genuinely different hardware. The same tool, or a second job pointed at a different destination, ships an encrypted copy to cloud object storage or a relative’s NAS for copy three. Three copies, two kinds of media, one of them physically elsewhere, and the whole thing keeps running unattended once the schedules are set.
FAQ
Is RAID a backup?
No. RAID protects against a single drive failing; it doesn’t create a copy of the data anywhere else, so ransomware, accidental deletion, fire, or theft can still take out every drive in the array at once.
Are ZFS or Btrfs snapshots a backup?
Not by themselves. Snapshots are excellent for rolling back accidental changes or deletions, but they live on the same pool as the data they protect, so anything that destroys that pool, hardware failure, theft, fire, or targeted ransomware, takes the snapshots with it. They’re a complement to a 3-2-1 setup, not a replacement for the offsite copy.
How often should a homelab back up its data?
It depends on how much data loss is tolerable if the last backup is the one restored. Nightly jobs are a common default for anything that changes daily, photos, documents, database dumps, while slower-changing data can run less often. Both Duplicati and Kopia handle incremental runs efficiently enough that daily scheduling rarely costs much in bandwidth or storage.
Do I need two separate offsite copies for 3-2-1?
No, one offsite copy satisfies the baseline 3-2-1 rule. Adding a second, immutable offsite copy is what the extended 3-2-1-1-0 approach covers, which makes sense for anything genuinely irreplaceable, but it’s an enhancement on top of 3-2-1, not a requirement to meet it.
Duplicati or Kopia for a homelab’s offsite backup?
Either covers the job for a single machine backing up to one destination. Duplicati’s web UI and wider destination list make it the simpler default; Kopia is worth picking instead when more than one machine needs to share the same offsite repository, or when object-lock ransomware protection on the storage backend matters.
The 3-2-1 rule isn’t complicated, which is exactly why it’s easy to talk yourself out of finishing it: a NAS with a healthy RAID array already feels safe, and a snapshot policy feels like it covers the rest. Neither one gets a copy of the data out of the building. Our Duplicati and Kopia pages cover installing and configuring either tool in full, the TrueNAS vs Unraid comparison digs into the storage layer this all sits on top of, and the homelab setup guide for beginners is the place to start if the rest of the stack isn’t built yet.