The arithmetic, which is simpler than the marketing
Every redundancy scheme spends some of the drives you bought on being able to lose drives. Single parity gives you the capacity of all the drives but one, so eight twelve-terabyte drives yield eighty-four terabytes. Dual parity costs two drives, so the same eight yield seventy-two. A two-way mirror halves the total outright, and a three-way mirror leaves a third. Striping with no redundancy gives you everything and protects nothing.
Two rules follow that catch people out. The first is that every drive counts as the smallest one — put a sixteen terabyte drive into an array of twelves and eight of its terabytes sit there unused unless the storage layer specifically supports mixed sizes. The second is that the parity cost is a fixed number of drives, not a percentage, so it hurts far more in a small array than a large one. Dual parity on four drives spends half the purchase; on sixteen it spends an eighth. That is the real reason wide arrays look efficient, and it comes with its own problem.
The problem with wide arrays and big drives
When a drive fails, the array reconstructs its contents onto a replacement by reading every remaining drive from end to end. At a sustained 120 MB/s a twelve terabyte drive takes about twenty-eight hours if nothing else is happening, and considerably longer if the array is still serving its normal workload while it rebuilds. During all of that, single parity means there is no redundancy left. A second failure ends the array.
What makes this more than a theoretical worry is that the remaining drives are being worked harder than they ever are in normal service, they are the same age as the one that just died, and they very likely came from the same batch. The conditions that produced one failure are being applied to the survivors at maximum intensity for a day or more. This is the argument for dual parity on large drives, and it is worth understanding as an argument about exposure time rather than as a quote of an error-rate statistic.
| Scheme | Usable from n drives | Survives | Where it fits |
|---|---|---|---|
| Striped | n | Nothing | Scratch space that is regenerated, never anything you would miss |
| Single parity | (n − 1) | One drive | Small drives, short rebuilds, a real backup elsewhere |
| Dual parity | (n − 2) | Two drives | Large drives, where rebuilds run for days |
| Two-way mirror | n ÷ 2 | One per pair | Fast rebuilds, high transaction workloads, expensive capacity |
| Three-way mirror | n ÷ 3 | Two per set | Where rebuild speed matters more than the cost of capacity |
Why the folder shows less than the box promised
Three separate deductions stack between the invoice and the free-space figure, and only one of them is anybody being sneaky. Drive capacity is quoted in decimal terabytes of a million million bytes; the operating system usually counts in binary units of 1,099,511,627,776 bytes and calls them the same thing. That gap alone is about nine percent and grows slightly with capacity. Then the filesystem takes its own overhead for metadata, and checksumming or snapshotting filesystems take noticeably more than plain ones. Then there is the fill target, which is not overhead but a decision: copy-on-write filesystems in particular degrade sharply once they are close to full, and a pool that is one bad week away from being completely full is a pool you cannot manoeuvre in.
Put together, budgeting around three quarters of the vendor-usable figure as genuinely available working space is not pessimistic. It is what you should plan against, and it is why the growth projection in the calculator runs against the fill target rather than against the raw number.
Redundancy is not backup, and this is not a slogan
An array that survives a drive failing is protecting you against exactly one thing: a drive failing. Every other way of losing data goes straight through it. A deleted file is deleted from every drive at once. Corruption written by a failing controller or a bad cable is written to the parity too. Ransomware encrypts what it can reach, and it can reach the array. A theft or a fire takes the whole chassis, spare drives and all.
The separate thing you need is a copy that is not in the same box, ideally not in the same building, and ideally not writable by the machine that would be compromised. Snapshots help against deletion and against some ransomware, and they are not offsite. What an offsite copy has to satisfy to actually count is covered in the cloud backup guide, and if the data in question is footage, the shoot storage and backup calculator sizes the three-copy version of the problem directly.
Things worth deciding before you buy drives
Expansion is the one people regret. Some storage layers let you add a drive to an existing group and grow in place; others require you to add a whole new group of the same width, which turns a one-drive purchase into a five-drive purchase. Find out which yours does before the array is full rather than after.
Then there is what keeps it alive during a power event. An array interrupted mid-write is the scenario where redundancy quietly stops helping, so a backup unit that is actually wired to trigger a shutdown is part of the build rather than an accessory — size it with the UPS sizing calculator. And the drives themselves make heat and draw power continuously, unlike most of a desktop, which feeds into the power supply wattage calculator and the case airflow calculator. Spinning drives in a poorly ventilated chassis run hot for years, and heat is one of the few failure factors you get to control.
Questions people ask
Is dual parity worth losing another drive of capacity?
On large drives, usually. The question is not how likely a second drive is to fail in the abstract; it is how likely one is to fail during the specific day or two when the array is reading every surviving drive end to end and has no margin left. That window scales with drive size, so the case for dual parity gets stronger every time capacities go up. On small drives with rebuilds measured in hours, single parity is a more reasonable trade. Either way it is a trade you should make on purpose rather than by accepting a default.
What happens if I mix drive sizes?
Most schemes treat every drive as if it were the smallest, and the extra capacity on the larger drives is stranded. Two sixteen terabyte drives in an array of twelves contribute twelve each, and eight terabytes sit unreachable. Some storage layers handle mixed sizes properly by splitting drives into blocks and placing redundancy across them, which recovers most of the difference. Check what yours does before buying a larger drive expecting to use it, and enter the smallest drive here either way.
How long does a rebuild really take?
Longer than the arithmetic, often by a factor of two or more. The figure here divides drive capacity by a sustained rate, which is the idle-array best case. A real rebuild competes with whatever the array is normally doing, and many systems deliberately throttle rebuild speed to keep serving users, which trades a longer window of no redundancy for a system that stays usable. If you can, run a rebuild once as a drill on a new array before it holds anything, and time it. That measured number is worth more than any estimate.
Do I still need backups if I have dual parity?
Yes, and the two are not substitutes for each other in either direction. Redundancy handles hardware failure without downtime, which backups handle slowly and badly. Backups handle deletion, corruption, ransomware, theft and fire, which redundancy does not handle at all. The array and the backup fail in completely different ways, which is exactly why you want both. A copy in the same chassis is not a backup, and neither is a second folder on the same pool.
Should I use a hot spare or just keep a cold drive on the shelf?
A hot spare starts the rebuild the moment a failure is detected, which shortens the exposure window by however long it would have taken you to notice and swap a drive — potentially days if the failure happens while you are away. The cost is a drive of capacity sitting idle. A shelf spare costs nothing in capacity but only helps if you are there. If the array is somewhere you visit daily and it emails you when something fails, a shelf spare is reasonable; if it lives in a cupboard you forget about, spend the drive.