Ayush Pande is a PC hardware and gaming writer. When he's not working on a new article, you can find him with his head stuck inside a PC or tinkering with a server operating system. Besides computing, his interests include spending hours in long RPGs, yelling at his friends in co-op games, and practicing guitar.
When I buy a new NAS, I’ve got an entire checklist of things I go through before making the deal. The RAM, for instance, is something I pay a lot of attention to when I plan to arm it with a ZFS-laden distribution. Likewise, unless I’m planning to put together a simple OpenMediaVault server, I ensure that the CPU powering my storage hub has the x86 (or x86-64, for pedantic folks) architecture.
On the drive front, I always aim for units with at least four HDD bays, and if it’s within the budget, a handful of M.2 slots for the boot OS. Since we’re on this subject, I’m also quite staunch about checking the S.M.A.R.T. metrics and running stress tests on brand-new drives before I shove them into my NAS. But above all else, I always ensure that I mix and match HDDs from different manufacturers when I order new ones for my NAS units.
Unfortunately, my NAS setup isn’t robust enough to survive multiple drive failures
Unlike PSUs, storage drives are often among the first NAS components that bite the dust. Hard drives, in particular, are prone to mechanical failure, as they rely on physical components like platters, motors, and arms that are prone to degradation after years of use. Certain S.M.A.R.T. metrics can be telltale signs of a failing HDD, but you could just as easily have a drive function well for years, only for it to ascend to tech heaven the next day due to some random manufacturing defect.
Now, let’s say you bought a couple of HDDs belonging to the same batch in bulk. This means that all the drives in your pool will age together, and essentially get exposed to the same amount of stress. This increases the chances of your drives failing at the same time, which can be a death sentence for many home labbers (including yours truly). Not to mention, hard drives manufactured in a batch tend to share physical and firmware issues, which can cause the same defect to hit multiple HDDs simultaneously.
Unfortunately, typical consumer NAS units aren’t equipped to handle simultaneous drive failures. I’ve got a RAID 10 storage pool, which can only tolerate up to two dead HDDs, and that too if they belong to different mirrored sets. In the more conventional RAID solutions that can only tolerate a maximum of one failed drive, correlated batch failure becomes a real threat to your storage pool.
I even pick drives from different batches for my Proxmox clusters
Since I’d rather avoid dealing with simultaneous drive failures, I follow the iron code of grabbing drives from different manufacturers altogether. If I stuck to a single manufacturer and switched vendors, there’s still a slim possibility that my new storage companions might belong to the same batch.
I’ve got a handful of server nodes as well, and although all the data from these workstations gets backed up to my local (and remote) NAS units, I still follow the same principle of picking HDDs from different manufacturers when I want to create some storage pools for my cluster experiments. After all, my high-availability Proxmox cluster would be rendered useless if the ZFS pools on two nodes go down at the same time.
That said, I’d never mix drives with different specs
I don’t want to deal with the annoying issues of a hybrid pool
Before you call me out for choosing different hard drives for my storage and virtualization servers, let me confirm that the differences only extend to the manufacturing date and the company making the HDD. For the rest of the specifications, including the RPM, cache size, and (most importantly) capacity, I take great care to ensure that all HDDs remain identical.
Yes, I’m aware that Unraid and a couple of other distributions already support storage pools built with completely different HDDs, but I’m a TrueNAS user first and foremost. Although the latter has added provisions to combine different capacity drives in recent updates, I’d have to contend with ZFS limiting the usable storage of the vdev to the size of the smallest drive.
Since I’d like to reduce the chances of my precious storage pools getting rendered unusable, I rely on snapshot replication alongside my HDD-specific iron code. To be more precise, I’ve got a spare NAS receiving snapshots from my local storage server every once in a while. That way, even if I somehow end up with more than one failed drive on my local workstation, I’d be able to recover all the data from my remote server. And if this situation gets flipped around and my offsite NAS gets afflicted with dead drives, I can remotely activate the hot spares and initiate the recovery tasks from my local PC.
