An Unraid parity drive is a dedicated disk that stores a mathematical calculation (not files) across every data disk in your array, so if one drive dies, Unraid can rebuild its entire contents from the surviving disks.
If you are building your first NAS for long-term preservation, the two hardware decisions that confuse people most are the unraid parity drive and the cache drive. They sound similar, they both sit inside the same box, and they do completely different jobs.
Parity is about survival. It exists so a single dead hard drive does not turn into permanent data loss across your archive of public domain collections, Linux distributions, and large datasets.
Cache is about speed. It gives your incoming writes a fast landing zone so downloads and file transfers are not throttled by the slower parity math happening on spinning storage devices.
Get both right and you end up with a quiet, expandable archive box that ingests data quickly and shrugs off a drive failure. Get them confused and you either lose files you cannot replace or spend money on hardware that solves the wrong problem.
Unraid Parity Drive Protection: What Happens During a Disk Failure
When a data disk drops out of an Unraid array, the parity disk lets the system emulate that missing disk immediately, so your shares stay readable while you order a replacement. The math behind it is simple XOR arithmetic, and the way Unraid stores files makes a worst-case failure far less catastrophic than it would be on a striped array.
How Parity Data Reconstructs a Failed Data Disk
Parity records whether the number of ones at each block position across all data disks is odd or even. That single bit is enough to solve for any one missing value.
Say three data disks hold 1, 0, and 1 at the same position. Two ones is even, so parity stores 0. Lose the middle disk and Unraid XORs the survivors with parity: 1 XOR 1 XOR 0 returns 0, exactly the bit that vanished.
Repeat that across every sector and the whole failed disk comes back onto a replacement drive. Nothing about your files needs to be understood, only the bits.
Why Unraid Arrays Keep Files on Individual Disks
Each data drive in an Unraid array carries its own ordinary filesystem. A 40 GB archive written to Disk 3 sits entirely on Disk 3, not sliced across the array.
Two practical benefits follow. Only the disk being read has to spin up, which keeps a large archive box quiet and cool. And if you ever exceed what parity can cover, the remaining data disks are still normal filesystems you can mount in any Linux box.
Parity Protection Versus Traditional RAID
Traditional RAID 5 stripes data plus one parity block; RAID 6 adds a second; RAID 1 mirrors everything at 50 percent overhead. All of them require matched drives and lose the entire volume if you exceed their tolerance.
| Model | Drives lost tolerated | Mixed drive sizes | Failure beyond tolerance |
|---|---|---|---|
| Unraid single parity | 1 | Yes | Surviving disks still readable |
| Unraid dual parity | 2 | Yes | Surviving disks still readable |
| RAID 5 | 1 | No | Whole array lost |
| RAID 6 | 2 | No | Whole array lost |
| RAID 1 | 1 (per mirror) | No | Mirror lost |
Choosing Drive Sizes and Calculating Usable Capacity
Usable capacity in Unraid is simply the sum of your data drives. Parity drives contribute zero usable space, and their size sets a hard ceiling on how large any single data disk can be.
Why Every Parity Disk Must Match the Largest Data Drive
Parity is calculated position by position down the full length of every disk, so the parity disk needs room to cover the longest one. Each parity disk must be at least as large as your biggest data drive.
A 4 TB, an 8 TB, and a 16 TB drive can live in one array happily, but parity has to be 16 TB or larger. Run dual parity and the rule applies to both parity disks.
Buy your largest, most durable drives as parity. High-endurance CMR NAS models like the Seagate IronWolf Pro or WD Red Pro are the right class here; avoid SMR drives for parity entirely, because their write behavior makes rebuilds painfully slow.
How Mixed Drive Sizes Affect Storage Capacity
Mixed sizes waste nothing on the data side. Add up the data drives and that is your usable pool.
An eight-bay chassis of 8 TB drives works out like this:
- Single parity: 7 data disks = 56 TB usable
- Dual parity: 6 data disks = 48 TB usable
Remember that advertised terabytes are decimal, so the number Unraid reports will look roughly 9 percent smaller. Plan around the reported figure, not the box art.
Planning Future Array Expansion Without Replacing Drives Twice
The trap is buying a data drive larger than current parity. You cannot slot a 20 TB disk into a data bay while parity is 16 TB.
Two ways out: promote the new drive to parity and demote the old parity disk to data, or upgrade parity first and add the big disk afterward. Either path costs you a full parity rebuild, so buying one size ahead on parity saves real time later.
Single Parity, Dual Parity, and Rebuild Risk
One parity disk survives one failure at a time; two independent parity calculations survive two simultaneous failures. The deciding factor is usually how long your array takes to rebuild and how much irreplaceable archival data sits on it.
When Single Parity Is a Reasonable Starting Point
For a first build with three to six drives and a rebuild window measured in hours rather than days, single parity is a sensible trade. One disk of overhead, one disk of protection.
It fits best when most of the array holds re-downloadable public domain archives or Linux distributions. The calculus changes fast once the drives get bigger and the collection gets harder to replace.
What Dual Parity and Parity 2 Can Recover From
Parity 2 is not a copy of parity 1. It uses a weighted calculation, the same principle RAID 6 relies on, producing a second genuinely independent equation.
Two independent equations solve for two unknowns, which is why dual parity rebuilds any two disks that fail together. Its real value is covering a second failure that happens during a rebuild, when every disk is being hammered.
How Parity Rebuilds Work After a Drive Failure
You stop the array, swap in the replacement, assign it to the same slot, and start the array. Unraid then reads every remaining disk plus parity and recomputes the missing disk block by block.
Expect all drives running flat out for many hours; on 16 TB or larger disks, a day or more is normal. Two things can break a single-parity rebuild: another outright disk failure, or an unrecoverable read error on a surviving disk at the exact moment parity needs every sector readable. Bigger and more numerous drives make both more likely.
Cache Drives Versus Parity for Faster Archive Ingest
Parity protects data; cache accelerates writing it. Because every array write also updates parity, raw array write speed on spinning disks often lands well under what a fast connection can deliver, and an SSD cache pool removes that bottleneck entirely.
How an SSD Cache Improves Usenet Download Writes
Usenet download clients write, unpack, and verify large temporary files, which is exactly the random-write pattern spinning drives handle worst. Pointing your download and unpack shares at an NVMe cache pool lets that work finish at SSD speed, then Mover relocates the completed data to the parity-protected array on a schedule.
The difference is dramatic in practice. Grabbing a large dataset that crawled at spinning-disk speed with parity updates in the loop can saturate a gigabit link when it lands on NVMe first.
A 1 TB or 2 TB NVMe drive with decent sustained write endurance, such as a Samsung 990 PRO or a WD Black SN850X, is plenty for most home lab archive workflows. Pair it with a provider that can actually fill the pipe: a premium Usenet service like Newshosting or Easynews delivers the retention, SSL encryption, and simultaneous connections that make a fast cache drive worth having. Guides on datahoarder.io cover provider selection and newsreader configuration in more depth.
Cache Pools, Redundancy, and Temporary Data Risk
Cache pools sit outside the array, which means no parity protection. If a single-drive cache dies before Mover runs, whatever was sitting on it is gone.
That is fine for unpack scratch space. It is not fine for AppData, VM images, or files you have not yet moved. Two SSDs in a mirrored BTRFS pool cover that gap cheaply.
Turbo Write and Read/Modify/Write Compared
Default array writes use read/modify/write: read the old data block, read the old parity block, compute, then write both. That is four operations for one write and roughly halves throughput.
Turbo write (reconstruct write) spins up every disk, reads all of them, and computes new parity directly. Writes get much faster, at the cost of every drive spinning and drawing power during the transfer.
| Mode | Disks active | Write speed | Best for |
|---|---|---|---|
| Read/modify/write | 2 | Slower | Idle, low-power archive boxes |
| Turbo write | All | Faster | Bulk ingest sessions |
Configuring and Expanding the Storage Array Safely
Slot assignment and filesystem choices are where beginners accidentally destroy data. The rule that saves you: Unraid only formats a disk when you explicitly tick the format box, so read every confirmation before starting the array.
Assigning Parity, Data, Cache, and Unassigned Devices
In Main, storage devices fall into four roles: parity slots, numbered data slots, cache pools, and Unassigned Devices for anything outside the array.
Assign your largest drive to Parity first, then data disks, then SSDs to a cache pool. Preclearing new drives before assignment catches infant-mortality failures before they matter.
Never assign a drive holding data you want to keep into a parity slot. Parity slots get overwritten with calculation data immediately.
Selecting XFS or BTRFS Without Risky Reformatting
XFS is the practical default for array data disks: stable, fast, easy to recover with standard tools. BTRFS earns its place on multi-device cache pools, where it handles mirroring and checksumming.
Changing a disk’s filesystem means reformatting, which erases it. The safe method is to empty the disk first by moving its contents to other array disks, then change the format on the empty drive.
License Limits, Disk Settings, and Array Operations
Your Unraid license key caps how many attached storage devices you can use, counting parity, data, and cache together. Count your planned bays before buying a tier.
Useful disk settings to review early:
- Spin-down delay: saves power on archive drives that idle most of the day
- Default filesystem: set to XFS so new array disks inherit it
- Turbo write: enable on demand, or automate it with a tuning plugin
- Scheduled parity check: monthly, with corrections disabled by default
Array operations such as adding disks, replacing parity, or changing slots all require stopping the array first.
Maintenance, Parity Checks, and a Real Backup Strategy
A parity check verifies that the parity math still matches your data disks. It is genuinely useful maintenance, and it is nothing like a backup.
What Parity Checks Verify and What They Cannot Repair
A check reads every sector on every disk and compares the computed parity against what is stored. Sync errors point to an unclean shutdown, a failing cable, or a drive going bad.
Run automated checks in non-correcting mode. If a data disk has silently returned bad sectors, a correcting check writes that damage into parity and makes a future parity rebuild reproduce the corruption faithfully. Investigate SMART data and UDMA CRC counts before you let anything write corrections.
Why Parity Cannot Restore Deleted, Corrupted, or Encrypted Files
Parity protects against exactly one event: a disk dying. Delete a share by mistake and parity dutifully records the deletion.
The same applies to ransomware encrypting your files, a bad power event taking multiple drives, controller failure writing garbage, or the whole chassis being stolen. In every one of those cases, parity is perfectly accurate and perfectly useless.
Building Independent Backups for Irreplaceable Archives
Sort your archive by replaceability. Public domain collections you can re-fetch need only parity; family photographs, scanned documents, and original recordings need real copies.
A workable pattern for a home lab:
- Parity-protected array as primary storage
- A second local copy on an external drive or a second box
- One off-site copy, encrypted, in cloud storage or a rotated drive kept elsewhere
- A quarterly restore test, because an untested backup is a hypothesis
That last step catches more problems than any parity check will. Restore a handful of files, verify checksums, and log the date.