📖 Chapter 01 — The 3-2-1 Rule

The discipline that protects against disaster. Three copies, two media, one offsite.

Learning Objectives

• Apply the 3-2-1 backup rule to every dataset that matters
• Choose the right backup media for each use case
• Set up offsite backup (rotation or cloud)
• Test backups regularly to verify they actually work

Introduction

You have a NAS with RAIDZ2. You have snapshots. You have scrubs. The data is well-protected against single-drive failures and silent corruption. But none of it protects against: the house burning down, the NAS being stolen, a ransomware attack that encrypts everything, or the entire machine failing catastrophically.

For data that matters, you need backups. Real backups — copies of the data on different media, in different places, that you can restore from. This chapter is the 3-2-1 rule and how to apply it.

The 3-2-1 rule

The 3-2-1 rule is the industry standard for backups:

• 3 copies of the data (the original + 2 backups)
• 2 different media types (e.g., NAS drives + external USB drive, or NAS drives + cloud)
• 1 off-site (in a different physical location than the original)

For the family NAS: the original is on the NAS. Copy 1 is on an external drive, kept offline. Copy 2 is off-site — either a rotated drive at a friend's house or a cloud backup.

What "backup" really means

A backup is a copy of data that survives the failure of the original. "Backup" is sometimes misused to mean: a snapshot (which is on the same media as the original, so doesn't survive a media failure), a sync (which is a copy but on the same machine, so doesn't survive a machine failure), or a redundant array (which is good for drive failures but not for theft or fire).

A real backup: a copy of the data on different media, in a different place, that you can restore from even if the entire NAS is destroyed.

The 3-2-1 setup for the family NAS

For TK's build, the 3-2-1 setup:

1. Copy 1 (original): the NAS, with the pool, datasets, snapshots. Local, fast, well-protected against single-drive failures.
2. Copy 2 (local backup): an external USB drive, kept offline, replicated to weekly. The drive lives in a fireproof safe in a different room from the NAS.
3. Copy 3 (offsite backup): another external USB drive, rotated weekly with a friend or family member. Or a cloud backup (Backblaze B2, Wasabi, AWS S3 Glacier) for less hands-on setup.

The pattern: the NAS is the working copy. The local backup is for fast recovery from accidents (deleted a file, corrupted a dataset). The offsite backup is for disaster recovery (the NAS is gone).

What to back up

Not every dataset needs 3-2-1. The classification:

The principle: the more irreplaceable the data, the more copies. The more regenerable, the fewer.

Local backup: the external drive

The local backup is an external USB drive, formatted as a ZFS pool, replicated to from the main pool.

The setup:

1. Buy an external desktop drive. 8-16 TB. NAS-rated if possible (WD Red, Seagate IronWolf, Toshiba N300).
2. Plug it into the NAS. Use TrueNAS to "Import Disk" and create a ZFS pool on it.
3. Configure a TrueNAS replication task: source tank, destination the external drive's pool, schedule weekly.
4. After the replication, unmount the drive.
5. Store the drive in a fireproof safe in a different room from the NAS.

The first replication copies everything (hours). Subsequent replications are incremental (minutes). The drive is offline except during replication, so a ransomware attack on the NAS can't reach it.

Offsite backup: rotation or cloud

For the offsite backup, two patterns:

Rotation

Buy two external drives. Rotate them weekly:

• Week 1: drive A in the NAS, replicates, then goes to the offsite location (friend, family, office)
• Week 2: drive B in the NAS, replicates, then goes to the offsite location
• Week 3: drive A comes back, replicates again, goes back offsite

This pattern: you always have a recent offsite backup. The offsite drive is never online at the same time as the NAS, so even a coordinated attack can't get both.

Cloud

For less hands-on backup, use a cloud provider:

• Backblaze B2: $6/TB/month, reliable, well-integrated with tools like rclone.
• Wasabi: $7/TB/month, no egress fees, good for "I might need to restore this."
• AWS S3 Glacier: very cheap ($1/TB/month) but slow to restore (hours). Best for "I want this to exist somewhere, but I don't expect to restore quickly."

For the family NAS, the conversation's recommendation: rotation if you have a friend or family member nearby; cloud if you don't. The cost of two external drives ($200-400) is less than a year of cloud storage for a multi-TB archive. The convenience of cloud is more for people without an offsite location.

The replication task

TrueNAS has a built-in replication task. The setup:

1. Data Protection → Replication Tasks → Add.
2. Source: the source dataset (e.g., tank/Family or tank/Media/Archive).
3. Destination: the external drive's pool.
4. Schedule: weekly (or daily, if you want).
5. Mode: incremental. Only the changes since the last replication are sent.
6. Retention: keep the last N snapshots on the destination. (For the local backup, keep all snapshots. For the offsite, keep recent ones.)

TrueNAS will run the replication on the schedule. The first run copies everything. Subsequent runs are fast.

Testing backups

The single most common backup failure: the backup is set up, the backup is running, but the backup doesn't actually contain the data you think it does. A scheduled task that errors out silently. A replication that breaks. A drive that disconnects mid-backup.

The fix: test the backup by restoring from it.

1. Quarterly, pick a project from the archive (or a folder from the family data).
2. Restore it from the backup (the external drive, the cloud, whatever).
3. Verify the files match the originals (compare checksums if you want to be rigorous).
4. Verify the project can be opened, the photos can be viewed, the documents can be read.

This is the only way to know the backup actually works. "Set and forget" is a recipe for discovering the backup is broken at the moment you need it.

The 10-year cost of cold archive

For a 5 TB archive, growing at 1 TB per year:

• External drive 1: $200 (one-time, lasts ~5 years)
• External drive 2: $200 (one-time, lasts ~5 years, offsite)
• Cloud backup: $5-30/month depending on provider and amount

Over 10 years: $400-500 in drives, $600-3600 in cloud. For 5-15 TB of irreplaceable data, this is reasonable insurance.

What NOT to back up

• Snapshots themselves. Snapshots are stored on the pool. Backing up a snapshot is backing up a view of the data, not the data itself. The replication task sends the actual data; the snapshots on the destination are recreated.
• Cache files. DaVinci Resolve's cache, browser caches, app caches. These are regenerable.
• Container images. The Docker image is reproducible from the Dockerfile. The container's data is what matters; the image can be re-pulled.
• Logs. Logs are useful for diagnosis, but they're regenerable (or you can get them from the running system).

Engineering Note

Summary

3-2-1: three copies, two media, one offsite. The original on the NAS. A local backup on an external drive, kept offline, replicated weekly. An offsite backup via rotation (two drives, swap weekly) or cloud. The irreplaceable data (photos, archives, configs) gets 3-2-1. The regenerable data gets less. Test by restoring, quarterly. The cost is small; the protection is real.

Checklist

• ⬜ Buy two external drives for backup (8-16 TB each, NAS-rated)
• ⬜ Configure TrueNAS replication tasks for the irreplaceable datasets
• ⬜ Set up offsite rotation (or cloud backup)
• ⬜ Set a calendar reminder to swap the drives weekly
• ⬜ Quarterly: restore a project from the backup, verify the data is intact
• ⬜ Document the backup procedure in the runbook (Chapter 7)

Looking Ahead

Chapter 02 is monitoring and alerting. Once the backups are in place, the next step is knowing when things break. Uptime Kuma for service monitoring, alerting for critical events, the discipline of observability. The chapter that turns "I think the system is working" into "I know the system is working, and I know when it stops."

Ch 01 · v0.1 · drafted from the original ChatGPT conversation, July 2026