Data-Hoarding

There’s no single right NAS OS, there are three genuinely different philosophies, and the “which one is best” debate mostly happens because people are comparing them against different priorities without saying so. If you know what you’re actually optimizing for, capacity efficiency, mixed-drive flexibility, or full control, the choice mostly makes itself. Here’s what each one actually trades off. TrueNAS: ZFS-first, and it means it TrueNAS (SCALE, the Linux-based version, is the current default recommendation over the older FreeBSD-based CORE for most new builds) is built entirely around ZFS, and that shapes everything about how it works. You get real checksumming, snapshots, and the RAIDZ redundancy levels covered in the ZFS pool layout guide elsewhere on this site, all through a genuinely mature, well-tested web UI with a large ecosystem of documentation and community troubleshooting behind it. ...

Most media library problems aren’t storage problems, they’re organization problems. Enough drive space and a working RAID array doesn’t help if your media server can’t identify half your files, or if a “quick reorganization” three years from now turns into a multi-day project because everything’s tangled together. Here’s a folder and naming structure that holds up regardless of which media server you’re running, and why the small decisions you make on day one matter more than they seem to. ...

Somewhere in every data hoarder’s history there’s a drive that seemed like a great deal, went into an array without a second thought, and then turned a routine rebuild into a multi-day nightmare or a dropped drive. Almost every time, the actual cause is the same three letters: SMR. This isn’t an obscure edge case. It’s happened at scale, publicly, more than once - manufacturers quietly shipping SMR drives in product lines everyone assumed were CMR, and the data hoarding and NAS communities finding out the hard way when arrays started misbehaving. If you’re buying drives for a NAS, a ZFS pool, or any kind of RAID array, this is one of the few things worth actually understanding before you buy, not after. ...

Updated Aug 12, 2026: added ZFS-vs-traditional-RAID comparison, a rebuild-risk worked example, and a monitoring checklist. “RAID is not a backup” gets repeated so often it’s lost meaning. Here’s the version that actually helps you pick a redundancy level instead of just feeling vaguely guilty about your array. What redundancy actually protects against Redundancy (RAID-Z1, RAID-Z2, mirrors, whatever flavor) protects against drive failure, full stop. It does not protect against: Accidental deletion (redundancy dutifully replicates your mistake) Ransomware or file corruption that writes bad data (same problem) Fire, theft, flooding, or anything that takes out the whole box at once Controller or power supply failure that kills multiple drives simultaneously That’s what backups are for, and it’s a separate problem from redundancy. This post is specifically about the “how many drives can I lose without losing data” question. If you only take one thing from this post, take the 3-2-1 rule for the data you actually care about: 3 copies, on 2 different types of media, with 1 copy off-site. Redundancy is not one of the three copies - it just keeps your primary copy available while a drive is being replaced. ...