Checksums, scrubs, snapshots and RAID-Z explained from the OpenZFS and TrueNAS docs, with a mirror vs RAID-Z1 vs RAID-Z2 table and the reason ZFS is not a backup.
“A single case of bit corruption can render some or all of your data unavailable.” That sentence comes from the OpenZFS documentation on pool redundancy (zpoolconcepts), and it describes the failure ZFS was built around: not a dead disk, which announces itself, but a disk that quietly returns the wrong bytes.
A ZFS home NAS answers that with four mechanisms, each covered below: checksums on every block, scrubs that go looking for damage, snapshots that undo mistakes, and parity or mirroring that repairs what the checksums find. Then comes the part people skip. None of it is a backup, and the TrueNAS documentation says so in as many words. A decision table at the midpoint compares mirror, RAID-Z1 and RAID-Z2 for a small build.
Checksums: how ZFS knows data went bad
TrueNAS’s ZFS primer puts the basic fact simply: “As ZFS writes data, it creates a checksum for each disk block.” On a later read, the stored checksum is compared with the data returned. The dataset property that controls this is checksum, which “controls the checksum used to verify data integrity.” The default, on, selects an appropriate algorithm, currently fletcher4, and the docs add that this may change in future releases. Sha256, sha512, skein, edonr and blake3 are also listed, and the last four need pool features enabled. The same page says disabling checksums “is NOT a recommended practice” (zfsprops).
Detection alone leaves you with a known-bad block. Repair needs a second copy, which is why OpenZFS says a pool must use some form of redundancy to take advantage of these features. On mirrored or RAID-Z pools, TrueNAS says ZFS repairs detected corruption using the redundant copies (TrueNAS ZFS primer). A single-disk pool can still notice damage, which is useful, but it has nothing to heal from.
The design underneath is copy-on-write. TrueNAS describes ZFS as “a transactional, Copy-On-Write (COW) file system,” where writes go to free space instead of overwriting existing blocks. The same design is why snapshots are cheap. For another take on filesystems that verify themselves, see the Linux 7.0 self-healing XFS write-up.
One more property is easy to confuse with redundancy. copies controls the number of copies of data stored for a dataset, and the manual is explicit that these are “in addition to any redundancy provided by the pool, for example, mirroring or RAID-Z.” Extra copies on a single disk do not rescue a pool from losing the disk.
Scrubs: finding damage before you need the file
Checksums are verified on read, so a block nobody opens could sit damaged for years. A scrub reads everything. Per the OpenZFS manual, “a normal scrub examines all data in the specified pools and verifies each block’s checksum,” and for replicated devices (mirror, raidz or draid) “ZFS automatically repairs any damage discovered during the scrub” (zpool-scrub).
zpool scrub tank
zpool status tankThe first command starts a scrub on the pool named tank; the second reports progress and summarizes results when it completes. Scrubs are I/O-intensive, so ZFS allows one at a time. Options exist to pause (-p) and stop (-s) one.
TrueNAS’s primer advises scheduling regular scrubs so ZFS can read all the data blocks and validate their checksums, and it notes that TrueNAS schedules a monthly scrub for each pool by default. Whether a plain ZFS install on another system schedules scrubs is not covered by these pages, so check that platform’s own documentation.
Snapshots: undo for human error
A snapshot is “a consistent image of a dataset at a specific point in time,” per the zfs-snapshot manual, and the concepts page adds that it is read-only, can be created extremely quickly, and initially consumes no additional space in the pool. As the live data changes, the snapshot holds on to the old blocks and grows. The synopsis shows the shape of the command:
zfs snapshot [-r] [-o property=value]... dataset@snapname...In practice that means naming a dataset, an @ sign and a label, for example tank/photos@before-cleanup, where the dataset name is a made-up placeholder. Because the snapshot keeps the earlier blocks while the live data moves on, it preserves a state to recover from after a deleted folder or a bad overwrite. The recovery commands themselves are not covered by the pages used here, so consult the OpenZFS manual for them. TrueNAS also supports periodic snapshot tasks, and its primer recommends periodic snapshots and automated replication as part of a snapshot-backup strategy.
RAID-Z levels: mirror, Z1 or Z2?
OpenZFS defines the options in plain terms. A mirror replicates data identically across all its components and “can withstand N-1 devices failing, without losing data.” A raidz group can have single, double or triple parity, written raidz1, raidz2 and raidz3, tolerating one, two or three failures; raidz alone is an alias for raidz1. The minimum number of devices in a raidz group is one more than the number of parity disks, and the recommended group size is between 3 and 9 “to help increase performance.” Spares can be added; the docs add that shared spares add some risk.
TrueNAS’s pool wizard adds two cautions: a mirror needs at least 2 disks in the VDEV, and a stripe, which has no redundancy, loses all data in the VDEV if one disk fails and is not recommended for critical data (TrueNAS pool creation).
| Layout | Minimum disks | Failures survived | Judgment call (opinion) |
|---|---|---|---|
| Mirror | 2 | N-1 (one, in a two-way mirror) | Simplest to reason about; suits a two-bay box or a small first pool. |
| RAID-Z1 | 2 (parity plus one) | 1 | More usable space from 3 or more disks, but one failure leaves no margin until the rebuild ends. Pair it with strong backups. |
| RAID-Z2 | 3 (parity plus one) | 2 | The cautious choice for a four-disk or larger pool; a second disk can fail and the data is still intact. |
The minimums for the two RAID-Z rows are derived from OpenZFS’s “parity plus one” rule; TrueNAS’s wizard page does not state RAID-Z minimums. The last column is a recommendation, not a documented fact, and weighs capacity against how much risk a household accepts.
Creating the pool uses commands from the OpenZFS manual. These two examples are the manual’s own, using device names that will differ on your system:
zpool create tank mirror sda sdb mirror sdc sdd
zpool create tank raidz sda sdb sdc sdd sde sdfThe first builds a pool of two mirrors; the second builds one raidz vdev from six disks. Check the manual for the full syntax before a real build (zpool-create). A small always-on machine to host all this is covered in the Raspberry Pi home server guide, though a Pi is a light platform for a pool of this kind and that is, again, opinion.
Drives are the main purchase. Look for models sold for NAS use and check each listing; no specific drive is linked here because product pages could not be verified.
Why ZFS is not a backup
The TrueNAS primer is direct: “RAID and disk redundancy are not substitutes for a reliable backup strategy.” Redundancy protects against a failed disk. It does not protect against deleting the wrong dataset, an accidental overwrite, a fire, a theft, or a bug that damages the pool itself. Snapshots are stored locally. The primer says “ZFS stores snapshots locally, but you can also replicate them to a remote ZFS pool.”
Replication is built in. zfs send creates a stream representation of a snapshot, which “can be redirected to a file or to a different system (for example, using ssh).” The manual’s example sends a snapshot to another pool on another host, then follows with an incremental (zfs-send):
zfs send pool/fs@a | ssh host zfs receive poolB/received/fs@a
zfs send -i a pool/fs@b | ssh host zfs receive poolB/received/fsThe destination machine, preferably one in a different place, is the part that turns a resilient NAS into a backed-up one. The 3-2-1 backup rule guide lays out the general pattern of multiple copies, on different media, with one off-site, and a ZFS replica is one way to fill a slot in it. Mirrors, parity, scrubs and snapshots keep the primary copy healthy. Only a separate copy keeps the data.
Sources
