An ordinary filesystem trusts the storage beneath it. If a drive returns data that has silently changed — a bit flipped by a cosmic ray, a controller error, a cable problem — the filesystem passes it up as correct, because it has no way to know otherwise. That failure mode is real, it is rare per byte and not rare across large amounts of data over years, and it is invisible.
ZFS checksums every block and verifies on read. With redundancy available, it repairs what it finds.
What changed in 2026
- Availability broadened. Better packaging and support across operating systems made it accessible outside its traditional environments.
- Expansion capability matured. The ability to add drives to an existing redundant group, historically a significant limitation, became practical.
- Home server adoption grew. Increasing awareness of data integrity among people storing years of personal media drove interest.
- The memory debate quieted. Consensus settled toward error-correcting memory being recommended and not the absolute requirement earlier discussion suggested.
What it provides
| Feature |
What it does |
| End-to-end checksums |
Detects corruption anywhere in the path |
| Self-healing |
Repairs detected corruption from redundant copies |
| Copy-on-write |
Never overwrites in place; consistent on-disk state |
| Snapshots |
Instant, near-free point-in-time copies |
| Send and receive |
Efficient replication of snapshots to another system |
| Compression |
Transparent, frequently improving performance |
| Integrated volume management |
No separate layer beneath the filesystem |
| Scrub |
Scheduled verification of all stored data |
Self-healing requires redundancy. Checksums alone tell you data is corrupt; a redundant copy is what allows reconstruction. A single-drive pool detects corruption and cannot fix it, which is better than not knowing and short of the point.
Snapshots deserve emphasis because they change how you think about backups. Because the filesystem never overwrites in place, a snapshot is just a reference to blocks that already exist — instant to create and consuming space only as data diverges. Taking frequent snapshots is cheap enough to be automatic, and it protects against accidental deletion and ransomware in a way redundancy does not.
The memory question
The long-running argument is whether error-correcting memory is mandatory. The strong version of the claim — that non-correcting memory can cause ZFS to destroy a pool — is overstated. The dismissive version — that memory does not matter — is also wrong.
The reasonable position is that error-correcting memory protects data in flight, before checksums are computed. Corruption occurring in memory gets checksummed as correct and written faithfully as corrupt data. That is a real exposure and it applies to any filesystem; ZFS does not create it.
So error-correcting memory is worth having for a system storing data you care about, and its absence is not a reason to avoid ZFS in favour of a filesystem that provides no integrity checking at all.
Running it properly
Schedule scrubs. A scrub reads all data and verifies checksums, repairing what it can. Monthly is a common cadence. Without scrubs, corruption sits undetected until you happen to read the affected data, possibly when the redundant copy has also degraded.
Configure redundancy appropriate to your drive count and capacity. Larger drives take longer to rebuild after a failure, and a longer rebuild window means more exposure to a second failure — which argues for configurations tolerating two failures on large arrays, the same reasoning as in NAS buying guide.
Enable compression. Modern algorithms frequently improve throughput because reading less data from disk outweighs the decompression cost.
Monitor pool health and act on it. A drive reporting errors should be replaced before it fails completely.
And remember redundancy is not backup. Snapshots protect against deletion; replication to another system protects against fire and theft.
Common mistakes
- Single-drive pools. Detects corruption without the ability to repair it.
- No scheduled scrubs. Corruption discovered too late.
- Treating redundancy as backup. Different problems.
- Filling the pool completely. Copy-on-write performance degrades badly near capacity.
- Not monitoring health. Failing drives replaced after failure rather than before.
- Avoiding ZFS over the memory argument. No checksums at all is worse.
FAQ
Can I use it on a desktop?
Yes, and the benefits are largest where you store irreplaceable data. Snapshots alone justify it for many.
How much memory does it need?
More than a simple filesystem, primarily for caching. Modern guidance is less demanding than older rules of thumb suggested.
Can I expand a pool?
Adding drives to an existing redundant group became practical, and it remains less flexible than some alternatives. Plan capacity ahead where possible.
What about the alternatives?
Other filesystems offer checksumming with different tradeoffs — see Btrfs snapshots guide.
Where to go next
For an alternative approach, read Btrfs snapshots guide. For the hardware, NAS buying guide and NVMe endurance explained.