3-2-1 Backup for a Small Homelab Without Backing Up the Whole NAS Offsite
15 May 2026
When I started trying to put a proper 3-2-1 backup strategy around my homelab, the thing that forced the redesign was not the tooling. It was the cost of pretending the whole NAS deserved an offsite copy.
3-2-1 is the familiar rule: three copies of important data, on two devices or media, with one copy off-site, as described in CISA’s Data Backup Options. In my case, though, only part of the estate gets that full treatment. The rest gets local recovery, local redundancy, or deliberate exclusion.
Once I looked at the rough numbers, the part I actually wanted protected offsite was under 700 GiB. The rest included about 4.3 TiB of TV and movies and roughly another 750 GiB of workstation and device backups. Backblaze’s current B2 pricing page lists pay-as-you-go storage at $6.95/TB/month, with the first 10 GB free. That put the smaller protected set at roughly $5 a month for storage, versus something closer to $40-45 if I treated the whole lot as cloud-worthy before growth or restore traffic.
The more useful question: am I paying to protect the right data, or just shipping everything to the cloud because it happens to live on the NAS?
This is the backup shape I ended up with. The setup has three jobs: fast rollback on the NAS, a second copy on another machine, and a smaller true offsite copy in the cloud. The details are deliberately sanitised, but the stack and the restore checks are real.
What Actually Earns Offsite Backup
The real question was simpler: what data actually deserves offsite cost?
For me, the answer was this:
| Class | Rough size | True offsite? | Why |
|---|---|---|---|
| Durable service state | ~40 GiB | Yes | Small and awkward to rebuild incorrectly |
| Personal files | ~190 GiB | Yes | High human value |
| Music library | ~435 GiB | Yes | Personally curated and not realistically replaceable |
| TV and movies | ~4.3 TiB | No | Large and replaceable enough in this setup |
| Workstation and device backups | ~750 GiB | No | Useful locally, not worth remote scope today |
| Temp, cache, transcode data | varies | No | Not meaningful backup material |
The music library is the clearest example of why this cannot just be a generic policy. It is not a streaming cache or a big pile of files I happen to own. It is a personally curated library of vinyl rips and collected music from my time as a DJ. That makes it a very different class of data from TV, movies, or ordinary scratch media.
Once I classified the data that way, the problem got much smaller. My real offsite set was the durable part of the estate: service state, personal files, and the music library. TV and movies, workstation backups, and temporary data still needed protection decisions, but they did not automatically earn cloud spend.
The Three Layers I’m Working With
1. The NAS
The main box is a NixOS NAS with a ZFS pool on RAIDZ1. That gives me single-disk fault tolerance, but I do not treat it as backup. Redundancy helps when a disk dies. It does not help with deleted files, bad updates, corruption propagated at the wrong moment, or losing the whole machine. The pool’s job is uptime, not recovery.
The datasets are organised by backup class, not convenience. Service state, personal files, media, workstation backups, and temporary data live in separate parts of the pool — so each one gets exactly the protection policy it earns.
When I say durable service state, I mean the app configuration, container volumes, and small databases that are awkward to rebuild badly.
The fact that the box runs NixOS declaratively also changes the recovery story. The host itself is closer to infrastructure as code than a hand-built server, so I am more willing to focus the backup strategy on the data instead of treating the whole host as a sacred object.
2. The Backup Box
The second layer is a small Raspberry Pi 5 backup box with an SSD/NVMe hat and a 2 TB NVMe. It receives selected ZFS send/receive replication from the NAS.
ZFS send/receive is the machine-to-machine copy here. It is not for quick versioned rollback; it is for having a separate copy if the NAS itself becomes the problem.
It has now been moved offsite and tested from the remote location. I still keep the location, access path, and host identity out of the public article, because the point is the pattern, not a treasure map.
3. The Cloud Copy
The third layer is Backrest -> Backblaze B2, running on the NAS.
I use Backrest because it gives me restic, the underlying file-level backup engine, without turning routine backup management into a command-line hobby.
I use B2 because the reduced protected set makes the price sensible, and I still want one copy that does not depend on the Pi box.
Which Layer Solves Which Failure
Once the data classes and tools were clear, the model was simple: snapshots for fast local recovery, the Pi replica for a second machine-level copy, and B2 for the smaller true offsite set.
In practice, durable service state, personal files, and the music library get all three layers. TV and movies stay local. Workstation and device backups stay local, and I accept that those backups are mainly protection against routine local failure rather than total site loss. Temporary data gets as little ceremony as possible.
| Class | Local ZFS snapshots | Pi replica | Backrest -> B2 | Why |
|---|---|---|---|---|
| Durable service state | Yes | Yes | Yes | Small, high-value, awkward to rebuild |
| Personal files | Yes | Yes | Yes | High human value |
| Music library | Yes | Yes | Yes | Personally curated and worth the extra copy |
| TV and movies | Light local only | No | No | Too large to justify remote scope here |
| Workstation and device backups | Local only | No | No | Useful, but not worth offsite cost today |
| Temp, cache, transcode data | Minimal | No | No | Not meaningful backup material |
ZFS Snapshots
Most of my durable service state lives on a dedicated ZFS appdata tree: the datasets that hold app state. That is the part I snapshot aggressively, because it is where quick rollback genuinely helps. In the live setup, those snapshots run every six hours.
This layer is for:
- deleted files
- bad updates
- accidental damage caught early
- small service-state mistakes
It is not for host loss or site loss. It is a fast local recovery layer, not the whole plan.
ZFS send/receive To The Pi Backup Box
Nightly selective replication to the Pi gives me a second copy of the data I want recoverable if the primary NAS itself is the problem:
- durable service state
- personal files
- music library
- a small amount of host-recovery data, mostly declarative system configuration and rebuild notes
Service state is not one neat folder, though. Some of it is protected by dataset replication and some by file-level cloud backup, so restores depend on knowing which layer owns which data.
Backrest -> Backblaze B2
The cloud layer is Backrest -> Backblaze B2, running daily against the reduced protected set.
This is where size, cost, and restore scope become real very quickly. It is also the only copy in this design that does not depend on my own second box.
Why So Much Stays Out Of Cloud Backup
The easiest bad backup plan is “send everything offsite and sort it out later.” I did not want that plan for two reasons.
First, cost and footprint. Once the cloud scope includes 4.3 TiB of TV and movies and another ~750 GiB of workstation and device backups, the monthly bill becomes large enough to shape the design.
Second, restore scope. A multi-terabyte cloud backup of mixed-value data sounds comprehensive, but in practice it can make the important part of the plan harder to see and harder to test.
The exclusions are practical:
- TV and movies are replaceable enough that I do not want to pay to keep them in
B2 - workstation and device backups are useful local recovery tools, but I accept that they are mainly protection against routine local failure, not total site loss
- temp, cache, and transcode paths are not meaningful backup material in the first place
The useful question is simpler than the tooling: what would you actually regret losing, and what can you maintain without lying to yourself about the cost?
Why I Test Restores Regularly
Backup jobs that never get tested are just scheduled optimism.
For me, that means doing small restore tests regularly enough that the process stays familiar:
- restore a file from snapshots
- pull something back from the replica box
- restore a small sample from
Backrest -> Backblaze B2
The point is to prove the layers still work before you need them to.
What Transfers To Other Small Homelabs
I would not tell anyone to copy this setup exactly. The decision process does transfer.
If your homelab contains a mix of durable state, personal files, media, and endpoint backups, these are the questions that matter:
- What would I genuinely want back after a serious loss?
- What can stay local?
- What actually deserves true offsite space and cost?
- Which technology is solving which failure mode?
For me, that led to ZFS snapshots for fast rollback, selective ZFS send/receive replication for a second copy, and Backrest -> Backblaze B2 for the smaller true offsite set.
The useful rule turned out to be simple: classify by human value and replacement cost first, then assign layers. Once I did that, the offsite copy was small enough to justify, the local layers had clear jobs, and the restore paths were testable without ceremony. The backup strategy that works is the one where you can name what each layer is for and what it costs you to keep.