ZFS does not keep your data secure

ZFS checksums every block it writes and re-checks it on every read. When the stored checksum and the data disagree, the filesystem knows a drive handed back garbage, and on a redundant pool it rebuilds the correct block from parity before the application ever sees the bad one. That one behavior - end-to-end integrity with self-healing - is the reason Ubiquiti building its enterprise NAS on ZFS is a real engineering decision and not a spec-sheet checkbox. It also creates a false sense of safety, because ZFS protects exactly one property of your data and people assume it protects all three.

Integrity, availability, confidentiality - ZFS only owns one

Security people talk about the CIA triad: confidentiality, integrity, availability. ZFS is built almost entirely around integrity. Its checksums catch bit rot, silent disk corruption, and a drive that quietly returns the wrong sector. Copy-on-write means a write either completes fully or not at all - there’s no half-updated stripe, which is how ZFS sidesteps the classic RAID “write hole” that can corrupt a traditional array during a power loss mid-write.

What ZFS does not do is keep your data available when two drives die in a single-parity pool, and it does nothing for confidentiality unless you turn encryption on. An administrator who reads “enterprise-grade ZFS data integrity” and assumes the box is therefore secure has confused one guarantee for three. Integrity means the data you read back is the data you wrote. It says nothing about who else can read it or whether you can reach it at 2 a.m. during an incident.

RAID-Z is redundancy, not a backup

RAID-Z comes in three flavors: RAID-Z1 survives one drive failure, Z2 survives two, Z3 survives three. On a seven-bay class of hardware, the tempting default is one big RAID-Z1 pool because it gives you the most usable space. That default is where a lot of data loss starts.

Here’s the arithmetic that matters. When a drive fails in a RAID-Z1 pool, every remaining drive has to be read in full to rebuild the replacement - a “resilver.” With 12TB or larger drives, that resilver can run for a day or more, and during that entire window you have zero redundancy. If a second drive throws an unrecoverable read error while you’re rebuilding - and large drives carry a non-trivial error rate across tens of terabytes of reads - the pool is gone. This isn’t theoretical; it’s the specific reason storage engineers stopped trusting single parity on high-capacity disks years ago. On anything holding data you can’t recreate, RAID-Z2 is the floor.

And redundancy of any level is still not a backup. RAID-Z survives a dead disk. It does not survive a ransomware process encrypting every file over SMB, an admin running the wrong destroy command, a firmware bug, a fire, or a theft. The 3-2-1 rule predates ZFS and ZFS doesn’t repeal it: three copies, two media types, one offsite. A NAS is one copy. Treating it as the backup is the single most common mistake I see in small-business storage.

The misconfigurations that turn strengths into weaknesses

ZFS gives you good defaults and enough rope to undo all of them.

No ECC memory is the quiet one. ZFS verifies data on disk, but it cannot verify data sitting in RAM before it’s written. If a memory bit flips between the application and the disk, ZFS faithfully checksums the corrupted version and stores it as “correct” forever. Enterprise storage should use ECC RAM for exactly this reason; consumer-grade boxes often don’t, and the integrity story has a hole in it that no amount of RAID-Z fills.

Scrubs that never run are another. A scrub is ZFS reading the entire pool and repairing any silent corruption it finds against parity. It’s how self-healing actually happens on cold data. If the appliance doesn’t schedule scrubs - or an admin disables them because they cause disk noise and load - bit rot accumulates undetected until you go to read an old file and the parity you needed to repair it has rotted too. Monthly scrubs are the baseline.

Encryption-at-rest left off means a stolen or RMA’d drive is readable by anyone who plugs it in. Snapshots not enabled means you’ve thrown away ZFS’s best ransomware defense, covered next. And a single shared admin account with a weak password attached to a cloud login undoes every storage-layer protection at once.

The attack surface is the management plane, not the filesystem

Nobody competent attacks ZFS directly. They attack the things wrapped around it. On this kind of NAS that means the web management interface, the SMB and NFS shares it exports, and - the big one - the vendor cloud account used for remote access.

This is the part that should shape your threat model. UniFi devices are designed to be adopted into a cloud-managed account, and that account becomes a single point of compromise for everything under it. Ubiquiti disclosed a breach in early 2021 in which an attacker reached cloud infrastructure through stolen credentials; the lesson wasn’t “Ubiquiti is uniquely bad,” it was “your storage is now reachable through an identity provider you don’t fully control.” If someone phishes the credentials to your cloud account and you haven’t enforced multi-factor authentication, RAID-Z2 and monthly scrubs are irrelevant. They log in as you.

The practical hardening here is boring and effective: enforce MFA on every cloud account, don’t expose the management interface or SMB to the internet, put the NAS on a segmented VLAN that only the hosts that need it can reach, and disable remote cloud access entirely if you don’t use it. Most NAS compromises are an exposed service and a reused password, not a clever filesystem exploit.

Ransomware and the snapshot question

ZFS snapshots are read-only, point-in-time references to the pool’s state, and they’re cheap because copy-on-write means a snapshot only costs the blocks that change after it’s taken. This is a genuinely strong ransomware control. When malware encrypts your files over a share, it’s writing new blocks; the snapshot still points at the unencrypted originals. You roll back and you’ve lost minutes, not everything.

The catch is in the words “read-only.” A snapshot protects your data from anything that writes through the filesystem, but it does not protect against an attacker who has gained administrative control of the NAS itself. With admin rights, zfs destroy deletes snapshots as easily as it created them, and modern ransomware crews specifically hunt for and delete local snapshots and shadow copies before they trigger encryption - precisely because they know snapshots would otherwise neuter the attack.

That’s why snapshots on the same box are a recovery feature, not a backup, and why the management-plane hardening above is load-bearing. The complete control is replication: ZFS can send snapshots to a second machine, ideally one where the receiving system, not the NAS admin account, controls retention and deletion. An attacker who owns the NAS can’t reach back and erase history that lives on a system they don’t have credentials for. Offsite, immutable, separate authority - that’s the property that survives a full appliance compromise.

What you trade against a traditional RAID stack

A traditional hardware RAID controller - the kind in a legacy file server - does redundancy at the block level and trusts each disk’s own error reporting. If a drive returns the wrong data without flagging an error, the controller writes it through; it has no independent checksum to catch the lie. That silent-corruption blind spot is exactly what ZFS closes, and it’s the strongest technical argument for this class of NAS over an older array.

The trade runs the other way on attack surface. A standalone RAID box managed over a local-only interface, or a Linux server running mdadm with backups handled by separate tooling, has a smaller and more auditable management footprint than an appliance designed to be adopted into a vendor cloud. ZFS buys you integrity; the cloud-managed packaging around it spends some of that back as exposure. Neither model is strictly safer - they fail differently. The honest comparison is better data integrity against a larger identity-based attack surface, and you secure each half on its own terms.

Where this leaves a real deployment

ZFS on a Ubiquiti enterprise NAS is a strong foundation for integrity and a neutral one for everything else. The filesystem will tell you the truth about your bits. It will not configure redundancy you didn’t choose, run scrubs you didn’t schedule, enforce MFA you didn’t turn on, or keep a copy somewhere the ransomware can’t reach.

If you run one of these, the short list is: RAID-Z2 minimum on large drives, ECC RAM if the hardware offers it, scheduled monthly scrubs, scheduled snapshots with sane retention, encryption at rest on, MFA on the cloud account, the management plane and shares off the public internet and behind a VLAN, and replicated snapshots to a second system the NAS admin can’t delete. Do those and ZFS’s integrity guarantees are backed by the availability and confidentiality controls it was never going to provide on its own. Skip them and you have a very honest filesystem faithfully checksumming data an attacker already owns.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

---

#ad Contains an affiliate link.