Drive failure has a dramatic version and a quiet one, and the quiet one is the reason to build a NAS carefully. The dramatic version clicks, or stops spinning, or takes the machine down with it, and you find out inside a minute. The quiet version looks like this: you open a photo from years ago and half the frame is grey static, while every other file in the same folder opens perfectly. Nothing crashed. A sector decayed, the drive handed back whatever it had, and an ordinary filesystem passed those bytes along because it has no way to know they are wrong. Nobody warns you about that when you decide to build your own storage, and it is the case that quietly costs people photographs they cannot re-acquire. So this guide is built around detection as much as capacity, with the heat, dust and power cuts of an Indian flat taken as given.
how much storage do you actually need
Measure, do not guess. Add up what you have today, then work out how fast it grows. Phone photos are the usual surprise: two phones shooting video add more in a year than most people assume, and none of it compresses.
| What you are storing | Growth pattern | Planning note |
|---|---|---|
| Phone photos and video | Steady, never shrinks | The one category you cannot re-download |
| Personal documents and code | Slow, small | Tiny on disk, highest value per byte |
| Films and shows you own | Lumpy, large | Replaceable from the original discs or files |
| Machine backups | Grows with snapshot retention | Budget for several versions, not one copy |
| Lab experiments and VM images | Bursty, deletable | Keep on separate, cheaper space |
Then apply two multipliers. Redundancy costs capacity — a mirrored pair gives you half the raw total — and no filesystem enjoys being full, so plan to stay below roughly eighty percent used. I would rather buy two larger drives now than four smaller ones and run out of bays in eighteen months.
Decide early whether the box does storage only or also runs services. Doing both is common and works well, provided you split the disks: the containers from my Docker Compose home server stack belong on a separate SSD while bulk data sits on spinning disks. Keeping the operating system off the array makes rebuilding either half far less frightening.
choosing drives without overthinking it
NAS-rated drives are about vibration and duty cycle
Drives sold for NAS use — WD Red Plus, Seagate IronWolf, Toshiba N300 and similar — cost more per terabyte than desktop drives. You are not buying speed. You are buying firmware tuned for continuous running, tolerance for the vibration of several drives in one chassis, and error handling that gives up on a bad sector quickly instead of retrying until the array declares the drive missing. For two drives the difference is modest. For four or more, it is real.
check whether a drive is SMR before you buy it
Shingled magnetic recording overlaps tracks to raise capacity, which makes sustained writes slow in a specific, nasty way. Everything feels fine until you replace a failed drive and the array rewrites the new disk end to end. On an SMR drive that rebuild can crawl, and a rebuild taking days is a rebuild during which a second failure finishes you off.
Labelling has improved but is not reliable. Search the exact model number plus “CMR or SMR” before ordering, and prefer drives documented as conventional recording for anything joining a redundant set.
mismatched drives are fine, with caveats
Most home labs grow out of whatever was lying around, and that is allowed. Two rules keep it sane. A mirror or parity set sizes itself to the smallest member, so pairing a 4 TB drive with an 8 TB one wastes half the larger disk. And drives from the same batch tend to fail at around the same time, so buying two different models spreads that risk for free.
RAID is not backup, and this matters more than any other line here
Redundancy keeps you online when a drive dies. It does nothing about the other ways data disappears. Delete a folder by mistake and the array faithfully deletes it from every disk at once. Ransomware gets stored redundantly too. A controller that goes strange can corrupt every member, and a power surge can take the whole box.
So a NAS with mirrored drives is one copy of your data that tolerates one hardware failure. You still need versioned copies elsewhere, at least one of them outside your house. The arrangement worth copying is snapshots pushed to an external drive plus one off-site copy, set out in the rsync backup script guide. Build the NAS, then build the backup.
filesystems: ext4, btrfs or ZFS
This is where people stall for weeks. All three choices work. They differ in what they can prove to you about your own data.
| Filesystem | Strength | Cost or catch |
|---|---|---|
| ext4 plus mdadm | Boring, universal, easy to recover with any live USB | No data checksums, so corruption is invisible |
| btrfs | Checksums, cheap snapshots, add drives flexibly | Parity modes still carry warnings; mirroring is the safe path |
| ZFS | End-to-end checksums, scrubs, snapshots, send and receive | Wants RAM, and growing a pool is less flexible (RAIDZ expansion only arrived in OpenZFS 2.3) |
If you want the least surprising option and will back up diligently, ext4 on a mirrored mdadm pair is genuinely fine, and it is what I would hand a beginner. If you want the filesystem to detect rot, pick btrfs or ZFS. On two drives I would use btrfs mirrored. On four or more, ZFS.
ZFS and its appetite for RAM
The folk rule of one gigabyte of RAM per terabyte came from deduplication workloads and gets repeated far beyond where it applies. Plain ZFS without dedup runs on modest machines; it just gives back less read cache. The honest version: 8 GB is a workable floor for a small home pool, more RAM buys cache rather than safety, and dedup is the feature that turns RAM into a hard requirement. Leave it off. Compression is cheap and usually a net win.
silent bit rot, and what checksums do about it
The half-grey photo described at the top of this article is bit rot. A sector degrades, or the drive returns bad data without reporting an error, and the filesystem passes it along because it has no idea the bytes are wrong. ext4 will not notice. btrfs and ZFS store a checksum with every block, compare on read, and if a redundant copy exists they repair the bad one and log it. For anything genuinely irreplaceable, that difference is the whole argument.
Checksums only help if something reads the data, which is what a scrub is for: a scheduled pass that verifies everything, so rot is found while a good copy still exists.
SMART monitoring and scheduled scrubs
Drives keep their own health log and most people never look at it. Install smartmontools, read the attributes that predict failure, and let the daemon message you when they move.
sudo apt install smartmontools
# Does the drive think it is healthy?
sudo smartctl -H /dev/sda
# The attributes worth watching, and recent self-test results
sudo smartctl -A /dev/sda
sudo smartctl -l selftest /dev/sda
# Kick off a long self-test; it runs in the background for hours
sudo smartctl -t long /dev/sdaFive attributes carry most of the signal: Reallocated_Sector_Ct, Current_Pending_Sector, Offline_Uncorrectable, UDMA_CRC_Error_Count and Temperature_Celsius. A handful of reallocated sectors that never grows is survivable; the same number climbing week on week means order a replacement now. Rising CRC errors usually mean a bad SATA cable, which is a cheap and satisfying fix.
# ZFS: verify every block, then read the report
sudo zpool scrub tank
sudo zpool status -v tank
# btrfs equivalent
sudo btrfs scrub start /mnt/data
sudo btrfs scrub status /mnt/data
# mdadm: a consistency check, no checksums involved
echo check | sudo tee /sys/block/md0/md/sync_action
cat /proc/mdstatRun a scrub monthly and a long SMART self-test weekly, scheduled rather than remembered. A timer that also tells you when it finished is the difference between monitoring and hoping.
practise a drive failure before you have one
The worst time to learn a rebuild is during a real one. Do it deliberately, while nothing is wrong.
- Take a fresh backup and confirm you can open files from it. From the moment you pull a drive until the rebuild finishes, the array has no redundancy left.
- Write down which physical drive is which. Serial numbers on a sticky note taped inside the case, matched to device names from
lsblk -o NAME,SERIAL,SIZE. - Power down and physically unplug one drive of a mirror. Not a command — the actual cable, so you learn which one you grabbed.
- Boot up. Confirm your data is still readable and the array reports itself degraded.
- Reconnect it and run the resilver or rebuild. Time how long it takes and note the load on the surviving drive.
- Write the exact commands you used into a text file kept somewhere you can reach from your phone.
Two things usually come out of this drill: people cannot identify a physical drive from its device name, and a rebuild takes far longer than they assumed. Both are better learned on a calm afternoon.
heat, dust and power cuts
A drive spec sheet assumes a data centre. A flat in Patna in May is not that. Through peak summer the same drives run noticeably warmer than they do in January, and heat is the variable most under your control. One slow intake fan moving air across the drive cage does more good than any software setting. Keep the box off carpet, out of a closed cupboard, and lifted off the floor where dust lives.
Dust is the slow killer. Every couple of months, power down and blow out the intake and heatsinks. Monsoon adds humidity, so avoid rooms where damp collects.
A write interrupted mid-flight is how filesystems get corrupted. A small UPS that survives the gap between mains dropping and the inverter picking up is the cheapest reliability upgrade in a home lab.
Better still, wire the UPS to the machine over USB and let the NUT daemon shut the box down cleanly when battery runs low. An orderly shutdown during a long cut beats a hard power loss every time.
common mistakes
- Treating the array as a backup. It protects against one drive dying, not against you, ransomware or a power event.
- Buying all drives from one batch on one day. Matched wear means correlated failure.
- Never scrubbing. Checksums that nothing verifies are a feature you paid for and did not switch on.
- Running the pool above ninety percent full. Write performance falls off a cliff.
- Ignoring SMART until something breaks. Pending sectors usually announce themselves weeks ahead if anyone is reading.
- Cheap USB enclosures for array members. They drop off the bus under load and often block SMART access to the drive. Use direct SATA.
FAQ
should I buy a ready-made NAS or build one?
Buy one if you want it to work without becoming a hobby, and you value the mobile apps and the warranty. Build one if you already have a spare machine, want other services on the same box, and would rather not depend on a vendor’s firmware schedule. Building suits people who enjoy the tinkering.
can I start with a single drive?
Yes, as long as you are honest that one drive has no redundancy and therefore needs a backup more urgently than an array does. One good drive plus a real backup target beats two mirrored drives and no backup. Add the second drive later and convert to a mirror then.
is an old laptop enough to run a NAS?
For a couple of drives over USB and light file sharing, sometimes. The limits are real: one SATA bay, USB enclosures that misbehave under sustained load, no airflow across a drive cage. It is a great first server and a compromised NAS. Plenty of people start with the build in my old laptop home server guide and move bulk storage to a small tower within the year.
what will I actually do with all this storage?
Family photos and machine backups fill most of it in most households. After that, most people point a media server at the films they already own so the household can watch from any TV in the flat — the natural next build, covered in my Jellyfin media server guide.
Pick drives you can identify by serial, a filesystem that checks its own work, and a scrub schedule you do not have to remember. Then go and practise a rebuild while nothing is broken, because that hour is the cheapest insurance in this entire project.
Update history: added a fresh-backup step to the drive-failure drill, noted that RAIDZ expansion arrived in OpenZFS 2.3, corrected the USB enclosure SMART wording and added the Linux md documentation to Sources.
Sources
- OpenZFS documentation — pool layout, scrub behaviour, and the real story on memory and deduplication.
- btrfs documentation — checksums, scrub, snapshots and the current status of each RAID profile.
- smartmontools project — the smartctl and smartd tools used for the health checks above.
- Linux md (software RAID) documentation — the sync_action check used for mdadm arrays.