Best NAS hard drives for TrueNAS (ZFS)

How TrueNAS uses your drives

A ZFS pool is built from vdevs - groups of drives with their own redundancy - and the pool stripes across them. You don't grow a vdev one disk at a time the way you do on Unraid; you plan a vdev, fill it, and add more vdevs later (or use RAIDZ expansion on recent versions). ZFS also checks everything it reads against a checksum and repairs silently corrupted data during a scrub. That self-healing is the reason people run it, and it's also why the drives have to be well behaved: the same scrub and resilver that protect you are brutal on a disk that can't keep pace.

CMR is not optional here

A resilver rebuilds a failed drive by reading across the whole pool and writing the replacement end to end, for hours. That is the exact workload an SMR drive is worst at - it fills its small conventional cache, drops to shingle-rewrite speed, and can stall long enough that ZFS marks it faulted and pulls it from an already-degraded pool. That's how a routine rebuild turns into lost data. So every drive in the list above is CMR, and it is the one specification on this page you should never compromise. The WD Red SMR mess in 2020 was exactly this failure, and it's why every drive page here states the recording tech.

Compatibility: any CMR drive, SATA or SAS

TrueNAS doesn't keep an approved-drive list and doesn't lock you to a brand - iXsystems' own guidance is essentially "use CMR, avoid the cheap SMR stuff." So compatibility comes down to the interface. A TrueNAS box with a plain SATA backplane takes any SATA NAS or enterprise drive; add an HBA (an LSI-style card in IT mode) and it takes SAS just as happily, which is why enterprise SAS drives show up in the list above. Both are fair game - pick on capacity, endurance and price, not on a vendor's blessing.

What to optimise for

Match drive sizes within a vdev, since ZFS plans around the smallest member. Once you have several large drives, run RAIDZ2 rather than RAIDZ1 - a second parity disk matters more as drives get bigger and rebuilds get longer, the same logic as RAID 6. Buy a matched set at once so the whole vdev ages together and you're not hunting a discontinued model in two years. For an always-on pool, the enterprise drives' higher workload rating and 5-year warranty earn their premium; for a quiet home box, NAS-class is fine. The storage planner works out usable capacity per layout, and the list above is ranked by real Backblaze failure rate so you can start from the drives least likely to trigger a resilver in the first place.

Why a ZFS pool still wants SSDs

Even an all-HDD pool usually has a job or two for flash. The table below lists DRAM-equipped SSDs for those jobs, the ones you can actually buy first, with power-loss protection flagged in its own column since that's the spec a SLOG turns on. Three roles, and it's worth being honest about which ones you actually need - and about which SSDs are easy to buy:

A SLOG (separate ZIL) only helps synchronous writes - NFS exports, or VM and database storage over iSCSI. It holds in-flight sync data before it lands on the pool, so if the drive loses power mid-write you lose that data, which is why a SLOG must have power-loss protection and why a random consumer SSD is the wrong choice. It does nothing for ordinary SMB file copies, so don't add one unless your workload is actually sync-heavy.

An L2ARC extends the read cache from RAM onto SSD. It only earns its place once you've filled the box with as much RAM as it takes and your working set still doesn't fit - and it even borrows a little RAM to index itself. Add memory first; reach for L2ARC second.

A special (metadata) vdev stores the pool's metadata, and optionally small files, on SSD. This is the one that helps almost everyone: browsing, snapshots and anything with lots of small files get dramatically quicker. The catch is serious - the special vdev is part of the pool, so if it dies the pool dies. So mirror it, and give it power-loss protection for the same reason a SLOG needs it: it holds live pool data, and a power cut mid-write is exactly what you're guarding against. Enterprise SATA SSDs are the sweet spot here - PLP and high endurance without paying for NVMe bandwidth this role never uses - which is what the PLP and endurance columns in the table below are for.

Some builders skip the spinning drives entirely and run an all-flash pool for the quiet, the low power draw and the speed. If that's you, the same SSD table is your starting point - just size up.

One honest caveat about that table: the datacenter SSDs that make the best SLOG and metadata drives are rarely stocked on Amazon except through resellers at silly markups, so a lot of them show no price - our gouge filter hides the inflated ones rather than pretend they're real. The rows that do carry a price are the consumer and prosumer DRAM SSDs, which are the right call for an L2ARC or a home box anyway. For a serious SLOG, buying the enterprise drive from a specialist is normal.

The short version

Fill the pool with matched CMR drives, RAIDZ2 once they're large, and never put SMR anywhere near it. Add SSDs deliberately, not by reflex: a mirrored metadata vdev helps most people, a SLOG only helps sync writes and only with power-loss protection, and L2ARC comes after RAM. Both tables are ranked so you start from the drives least likely to let you down - hard drives by measured failure rate, SSDs by warranted endurance.