📖 Chapter 09 — Snapshots & Scrubs

The two features that save your data when everything else goes wrong.

Learning Objectives

• Explain what a ZFS snapshot actually is (and is not)
• Configure snapshot retention policies that match how you actually lose files
• Restore a deleted file from a snapshot
• Schedule scrubs and SMART tests to catch dying drives before they fail

Introduction

Two of ZFS's best features are bundled in this chapter because they have the same job: protect your data when something goes wrong. Snapshots protect against accidental deletion, file corruption, and ransomware. Scrubs catch drive errors before they become data loss. SMART tests catch dying drives before they fail catastrophically.

Together, these three automations are the difference between "I lost the family photos when my kid formatted the wrong drive" and "I lost the family photos when my kid formatted the wrong drive... but I restored them from Tuesday's snapshot in 30 seconds."

Snapshots

A snapshot is a read-only copy of a dataset at a specific moment in time. It captures every file, every folder, every byte. The moment the snapshot is taken, it becomes a frozen point you can roll back to.

What a snapshot actually is (and isn't)

This is the part most newcomers get wrong.

A snapshot is not a copy. When ZFS takes a snapshot, it doesn't duplicate the data. Instead, it marks the current state of the data as "this is what the snapshot refers to." As you write new data to the dataset, the old data that the snapshot refers to stays where it is — but ZFS knows not to overwrite it.

This means:

• Snapshots are nearly instantaneous. Even a 10TB dataset snapshots in milliseconds, because no data is being copied.
• Snapshots initially use almost no space. Only the differences between the live data and the snapshot count against the pool. If you take a snapshot and then don't change anything, the snapshot uses 0 additional space.
• Snapshots grow over time. As you write more new data, the snapshot's "old version" has to stay around. Eventually, a long-retention snapshot on a heavily-written dataset can take significant space.
• Snapshots live in the same pool as the data. They're not a backup. If the pool dies, the snapshots die with it. (Backups are covered in Volume 6.)

What snapshots protect against

• Accidental deletion. "I deleted the wrong file." Roll back to the snapshot from 5 minutes ago.
• Accidental overwrites. "I saved over the only copy of my tax return." Roll back.
• Bad app updates. "Immich upgraded itself and now my library is corrupted." Roll back the Apps/immich dataset to before the update.
• Ransomware. A ransomware attack that encrypts your files can't encrypt the snapshots (they're read-only). Restore from a snapshot taken before the infection.
• File corruption (silent bit rot). ZFS checksums every block. If the live data's checksum is wrong but the snapshot's is right, ZFS uses the snapshot's data to repair the live copy. You didn't even know there was a problem.

Snapshot retention policies

The conversation's recommended schedule for a family NAS:

Not every dataset needs every level. The conversation's recommendations per dataset:

The "before each app update" rule is important. Snapshots of app data are how you roll back a bad update. If Immich's database corrupts during an update, you roll back to the snapshot from before. The app's catalog does this automatically when you check the "snapshot before update" option.

How to actually use snapshots

Restoring from a snapshot is easier than most people think.

Scenario: "I deleted the wrong file"

You deleted Photos/2024/Hawaii/trip.jpg an hour ago. You want it back.

1. Open the TrueNAS web UI.
2. Go to Storage → Snapshots.
3. Find the snapshot of tank/Photos from 1 hour ago (look at the "Created" column).
4. Click the three-dot menu → Browse.
5. Navigate to Photos/2024/Hawaii/trip.jpg. You can see the file as it was 1 hour ago.
6. Click the file → Download or Restore.
7. The file is back in your live Photos dataset.

That's it. No terminal, no ZFS commands, no magic. The web UI does it.

Scenario: "My whole dataset got messed up"

Worse situation: a bad app update corrupted your entire Photos library. You want to roll back the whole dataset.

1. Stop the apps that use the dataset (e.g. Immich).
2. Open the snapshot UI.
3. Find the snapshot from before the bad update.
4. Click Rollback.
5. The dataset's live state is replaced with the snapshot's state. The bad data is gone; the good data is back.
6. Restart the apps.

Note: rollback destroys any changes made after the snapshot. If you've added 100 new photos between the snapshot and now, those are lost. For "lost a single file," prefer the file-restore approach above.

Scenario: "I want to see what's in a snapshot without restoring it"

The Browse feature lets you see the entire snapshot as a folder structure, read-only. You can copy files out of it without affecting the live data. This is the most common operation.

Setting up snapshot policies in TrueNAS

TrueNAS has a built-in "Snapshot Tasks" scheduler that takes snapshots on a cron schedule and prunes old ones based on retention rules.

1. Data Protection → Periodic Snapshot Tasks → Add.
2. Choose the dataset (e.g. tank/Photos).
3. Set the schedule (e.g. "Hourly" — every hour, on the hour).
4. Set the retention: how many snapshots to keep.
5. Set the naming scheme: usually auto-%Y-%m-%d_%H-%M (e.g. auto-2026-07-18_14-00).
6. Save.

For a dataset with multiple retention levels (hourly + daily + weekly + monthly), you create multiple periodic snapshot tasks, each with its own schedule and retention. The TrueNAS docs walk through this. The result is the layered retention shown in the table above.

Scrubs

A scrub is ZFS's monthly self-check. It reads every block in the pool, verifies its checksum, and repairs any errors it can.

What a scrub does

ZFS stores a checksum for every block. When you read a file, ZFS checks the checksum. If the checksum doesn't match, ZFS knows the data is corrupted and (if a redundant copy exists) repairs it.

A scrub is when ZFS reads every block and verifies the checksum, not just the blocks you're currently reading. This catches:

• Silent bit rot (a drive returned bad data without reporting an error)
• Drives that are starting to fail but haven't crossed the SMART threshold yet
• Filesystem metadata corruption (the "filesystem is broken" cases)

Setting up monthly scrubs

1. Data Protection → Scrub Tasks → Add.
2. Choose the pool (e.g. tank).
3. Set the schedule: once a month. The conversation recommends the second Sunday of each month, at a low-traffic time (e.g. 2 AM).
4. Set the threshold days: 30 (so a missed scrub will be retried within 30 days).
5. Save.

TrueNAS will run the scrub automatically. The first scrub after a fresh pool creation can take 12-24 hours on a 6×12TB pool; subsequent scrubs are faster (typically 8-12 hours).

While a scrub is running, the pool is slower. Don't run heavy workloads during a scrub. This is why the conversation recommends 2 AM.

SMART tests

SMART is the drive's own self-monitoring system. It tracks dozens of health metrics: reallocated sectors, spin-up time, temperature, command timeouts. SMART tests are the way you ask the drive to actively scan itself for problems.

Two kinds of SMART tests

• Short test: quick (~2 minutes), runs a subset of the drive's self-tests. Catches obvious problems. Run weekly.
• Long test: thorough (~8-12 hours for a 12TB drive), runs the full self-test. Catches subtle problems. Run monthly.

Setting up SMART tests in TrueNAS

1. Data Protection → S.M.A.R.T. Tests → Add.
2. Choose all the data drives (you can use the "select all" shortcut).
3. Set the schedule: weekly for short, monthly for long.
4. Save.

TrueNAS will email you (or show in the alert panel) if a SMART test reports a failure. Don't ignore these emails. A SMART failure on a drive in a RAIDZ2 pool is the warning before the failure. Replace the drive.

What to do when SMART reports a problem

SMART is reporting errors on drive 3 of 6. The pool is degraded but still running (because RAIDZ2 can tolerate 2 drive failures).

1. Identify the failing drive by serial number. The SMART test result shows the serial number; the TrueNAS Storage → Disks page also shows serials. Match them up.
2. Order a replacement drive. Same model is best, but any drive of equal or greater capacity works (ZFS will use the actual capacity of the smallest drive).
3. Shut down the NAS.
4. Replace the drive (the failing one's serial number is on the label).
5. Power on. The NAS detects the new drive.
6. Go to Storage → Manage Devices on the pool. The new drive is listed as "available" or "replacement."
7. Click Replace on the failed drive. Select the new drive. Confirm.
8. ZFS starts a resilver. This reads every block from the surviving drives, computes the parity, and writes the new data. For a 6×12TB pool, expect 12-24 hours.
9. While the resilver runs, the pool is degraded but functional. Don't stress it.
10. When the resilver completes, the pool is back to healthy.

The whole process is designed so a single drive failure doesn't lose data. The point of the SMART tests is to give you advance warning so you can replace the drive on your schedule, not at 3 AM during a crisis.

Engineering Note

Summary

Snapshots are instantaneous, space-efficient, in-pool, read-only copies of a dataset at a point in time. They protect against accidental deletion, file corruption, and ransomware. Scrubs verify every block's checksum monthly and repair silent corruption. SMART tests catch drives that are about to die before they actually die. All three should be scheduled, automated, and monitored. They are not backups — for that, see Volume 6.

Checklist

• ⬜ Configure snapshot tasks for each major dataset (Family, Photos, Videos, Documents, Private/*, Apps)
• ⬜ Verify a snapshot is being created (check Storage → Snapshots tomorrow)
• ⬜ Test the file-restore workflow: delete a file, restore it from a snapshot
• ⬜ Schedule monthly scrubs for the pool
• ⬜ Schedule weekly short SMART tests and monthly long SMART tests
• ⬜ Configure email alerts (TrueNAS → System → Email) so SMART failures and scrub errors reach you

Looking Ahead

Chapter 10 is the chapter that pulls it all together. The full build: the exact dataset tree, the exact permissions, the exact snapshot policies, the exact app list, the exact maintenance schedule. The configuration that runs on TK's pool, in one place. This is the chapter you reference when you forget "wait, how did we set up the Private datasets again?"

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