My NAS corrupted years of files because I ignored three critical setup mistakes

My NAS corrupted years of files because I ignored three critical setup mistakes

Published Aug 26, 2026, 1:00 PM EDT His love of PCs and their components was born out of trying to squeeze every ounce of performance out of the family computer. Tinkering with his own build at age 10 turned into building PCs for friends and family, fostering a passion that would ultimately take shape as a career path. Besides being the first call for tech support for those close to him, Ty is a computer science student, with his focus being cloud computing and networking. He also competed in semi-pro Counter-Strike for 8 years, making him intimately familiar with everything to do with peripherals. Before I had my current NAS setup, I haphazardly set up a storage box to act as overflow for my workstation. In the pre-AI era, getting a few spinning disks with decent capacity didn't require a serious budget calculation, so without a second thought, I bought what I thought was a decent-enough box with network access, plugged the drives in, and used it to store files just fine for years. That was, until I started seeing issues when copying over files. Weird corrupted files and shockingly terrible transfer speeds were just the start of my issues. Thankfully, none of the lost data was mission-critical, but it did teach me 3 big lessons about building a NAS that I carried forward to my current build. I used a filesystem that had no checksums I just went with what was default for that box, and that was a mistake When initially setting up the array, I just clicked through the setup wizard without thinking much about it. This stuck me on ext4, and while it's lightweight, it lacks any sort of checksum system. Without checksums, the filesystem simply trusts the drive can hold the data without corruption. The drive returns bytes, the filesystem passes them along without verification, and as a result, things like bit rot or a failing sector on the drive itself can cause data corruption silently. Nothing about the ext4 will tell you that something went wrong, and that's the worst part. This cropped up for me in the form of archives that wouldn't extract. I couldn't get some of my .zip, .rar. or .7z files to extract after copying, and the telltale sign that something went wrong was a handful of video files that were once completely pristine, now unable to play without some seriously garbled visuals. On a filesystem with checksums, like ZFS or btrfs, every read gets verified against a checksum as it happens, and when paired with redundancy, it also becomes the mechanism in which the corrupted file gets repaired with the good copy. These checksums aren't free computationally, though. ZFS needs more RAM than ext4, and btrfs in a RAID5 or 6 still carries some write caveats, so for some, they won't be a drop-in replacement. I could've chosen ZFS if I had simply paid attention during the install, and I came to regret it years later. SMR drives came back to bite me Terrible performance Credit: Seagate When buying drives for this box, I made a really crucial error. I sorted the page by price-per-terabyte, and bought what I thought was the best value. Great reviews, reputable brand, everything checked out across the surface level details. It wasn't until I got the drives, plugged them in, and attempted to write a ton of data to them. Speeds slowed to an absolute crawl, and it was even worse when I attempted a rebuild. The drives I had purchased turned out to be SMR, and that was the source of these ailments. SMR stands for shingled magnetic recording, and in contrast to CMR, where data is written onto dedicated tracks with each having its own lane, SMR shingles these tracks like roof shingles in order to pack more data onto the platter. The downside of this approach rears its head when you try and rewrite data on a specific track, because in order to do so, it also has to deal with all the shingled data on top of it. The practical result is horrible sustained write speeds that look nothing like the rated speed of the drive. SMR drives were quite commonplace in NAS-branded drives when I put together this box in around 2019, with WD, Seagate and Toshiba all guilty of failing to label which recording technology was used in storefronts. To be fair, I didn't go hunting for that information, but on a NAS-branded drive, myself and many others were buying under the pretense that the drive would be well-suited to NAS duties, which these drives simply weren't. You can now find this information under the datasheet for the drive, which is easily found through a quick search. I bought all the drives from one place, all at once Same order, model, retailer, and batch This didn't come back to bite me, but in retrospect, it was a decision I should've taken more seriously. When you buy a few drives that are sequential in serial number, that usually means they're from a similar production batch. Drives from a specific batch will tend to share failure characteristics, which means correlated failures. I didn't experience any outright drive failures, but buying drives like this can open you up to a cataclysm of failures. Drives also tend to fail on a "bathtub curve," where most drives fail either at the earliest stage of their lifespan, or in the distant future, but uncommonly in the middle. If a drive batch has a defect and you bought your drives from the same batch, that's potentially a big issue. What my build looks like now I solved most of the issues with the previous NAS My new NAS lives inside my home lab, and features two used enterprise Seagate Exos 7E8 8TB SAS drives connected via an IBM branded LSI HBA card. This sounds a lot more complicated than necessary, but each hardware decision had rationale behind it this time, unlike my previous build. For the drives, going SAS obviously has its downsides in initial setup cost, but the price-per-terabyte on these drives pre-owned is quite good considering current costs of storage. A used HBA card and cables can be grabbed for under $50, and once you deal with the potential setup headaches of getting everything to boot, it's no different than having the drives plugged directly into the motherboard via SATA. So long as you buy from a reputable retailer and ensure they've been recertified, they're an easy win. For the filesystem, I went with native ZFS through Proxmox. The 8TB drives are being run in a mirror, which cuts my potential 16TB of storage in half, but that redundancy with ZFS helps protect against any potential corruption. Sustained performance can saturate my 2.5GbE connection easily, and this is perfect for what I actually use my NAS for. The one caveat that comes with this setup are the drives. They both come from the same production window in 2021, which leaves me open to the correlated failures I mentioned previously. The reason why I'm not worried in this instance is that they both have wear histories that diverged before I owned them. They both have similar power-on hours at just above 4,000, but one has 46 start-stop cycles, while the other has 2,050. We're beginning to get to the middle of that bathtub curve: if they were going to fail, they probably already would've.

Original Source

Read the full article at Xda-developers →

KhanList aggregates and links to publicly available news content. We do not host full articles from third-party sources. Always verify important information with original sources.