For any surveillance array built on drives 8TB and above, RAID 6 is the correct default, not because it is more capacity-efficient, but because RAID 5's rebuild window on large drives has become a genuine data-loss risk. Here is the math that decides it.
For a surveillance array built on drives of 8TB or larger, RAID 6 is the correct default over RAID 5. The reason is not capacity efficiency — RAID 5 is more efficient with disk space, and that has not changed. The reason is that RAID 5 rebuilds on large drives take long enough, and carry a high enough probability of a second, unrelated read error during that window, that the rebuild itself has become the primary failure mode. RAID 6 does not fix this by making rebuilds faster. It fixes it by surviving the error that RAID 5 cannot. This is a rebuild-time problem, not a parity-overhead problem, and the distinction matters when you are sizing an array against a retention mandate rather than a spreadsheet. What actually happens during a RAID 5 rebuild When a drive in a RAID 5 set fails and is replaced, the controller cannot simply copy the missing data from somewhere. It has to read every remaining drive in the array, in full, and recalculate the missing drive's contents from parity. There is no shortcut. A RAID 1 or RAID 10 rebuild only needs to read the mirror partner of the failed drive, which is why mirrored arrays rebuild in a fraction of the time. RAID 5 and RAID 6 do not have a mirror partner to fall back on — the entire surviving array has to be read, sector by sector, before the new drive is trustworthy. For the duration of that read, a RAID 5 array is running with zero redundancy. If any surviving drive throws a read error it cannot correct on its own, the rebuild does not pause and retry gracefully — it fails, and the array is generally unrecoverable. This is the mechanism the rest of this article is about. Why large drives make this worse, not just slower The number that matters here is the drive's unrecoverable read error (URE) rate — the probability that any given bit read from a platter comes back wrong. Consumer-grade drives are typically rated at roughly one URE per 10 14 bits read. Enterprise and surveillance-rated nearline drives are usually rated an order of magnitude better, at roughly one URE per 10 15 bits. A rebuild's exposure to this error rate scales with the total volume of data that has to be read from the surviving drives, not with the number of drives in the set. An 8-drive RAID 5 array of 8TB drives has to read roughly 56TB during a rebuild — around 4.48 × 10 14 bits. Against an enterprise URE rate of 10 15 , that works out to something like a 30 percent chance of hitting an unreadable sector before the rebuild completes. Run the same rebuild on consumer-grade drives rated at 10 14 , and the odds move to somewhere around 96 percent — the rebuild is now more likely than not to fail on its own. This is worth sitting with because it is a genuinely new problem, not a constant one. The same RAID 5 design, run against 100GB-class drives years ago, carried something closer to a 1-in-28 chance of a URE during rebuild — low enough that RAID 5 was a defensible default. At 2TB-class drives the odds had already moved to roughly 60 percent. The math has not changed. The drives have. This is also why capacity efficiency is the wrong axis to optimise on when specifying the array. A 4-drive RAID 5 set of 600GB drives and an 8-drive RAID 5 set of 300GB drives read the same 2.4TB during a rebuild and carry the same URE exposure — drive count and array layout only matter insofar as they change the volume of data actually read. What RAID 6 changes, and what it does not RAID 6 does not make the rebuild shorter, and it does not make the underlying URE rate any better. What it changes is the consequence of hitting a URE during that rebuild. RAID 5 has one parity stripe, so a single unreadable sector on a surviving drive, encountered while the array is already down to one point of failure, ends the rebuild. RAID 6 carries a second, independent parity stripe, so a URE encountered during a rebuild can still be reconstructed from the remaining redundancy. The array survives the exact event that kills RAID 5. This is the honest way to describe RAID 6's advantage: it buys survivability across the rebuild window on large drives. It is not a capacity feature, and it should not be sold to a buyer as one. The real cost: write penalty, not capacity RAID 6 is not free. Every write to a RAID 6 array has to update two parity blocks instead of one. Spelled out, a small write requires reading the old data block, reading both old parity blocks, and then writing back the new data block and both recalculated parity blocks — five operations against one user write, versus three for RAID 5. This is the legitimate argument some practitioners make against RAID 6 for continuously-writing workloads such as busy databases and surveillance recording. It is worth being precise about when this penalty actually bites, rather than repeating it as a blanket warning. The penalty is heaviest for small, random writes, because each one triggers a full read-modify-write cycle. Multi-camera continuous recording is overwhelmingly large, sequential writes — a stream of video buffers landing on disk in order, not scattered small updates. Most enterprise RAID controllers coalesce sequential writes into full-stripe writes, where parity for the whole stripe is calculated once from the incoming data rather than read back from disk first. The read-modify-write penalty is largely a non-issue for this pattern. This is a reasonable engineering judgement rather than a universally documented fact, and it is the reason RAID 6 is now the industry default for larger NVR and VMS deployments despite the on-paper write penalty. Two more RAID 6 costs worth naming plainly rather than glossing over: it needs a minimum of four drives against RAID 5's three, and it gives up two drives' worth of capacity to parity rather than one. On a 12-drive shelf, that is the difference between 11 drives and 10 drives of usable capacity — a real number, but a smaller one than most buyers expect when they hear "dual parity." Where each RAID level still makes sense RAID 5 — small deployments, drives well under 8TB, and non-critical footage RAID 5 remains a reasonable choice for smaller camera counts on smaller drives, where the rebuild-time exposure described above is genuinely low. A 4-drive RAID 5 set on 2TB or 4TB drives does not carry the same URE probability as an 8-drive set on 16TB drives, because the total data read during rebuild is an order of magnitude smaller. If the footage is low-priority and a rebuild failure means re-provisioning storage rather than losing evidentiary or compliance-mandated recordings, RAID 5 is not reckless. RAID 6 — 8-drive-and-above arrays, and anything on drives 8TB or larger This is the default for most current surveillance deployments for a straightforward reason: NVR storage is increasingly built on 8TB to 18TB surveillance-rated drives to meet retention requirements, and at that capacity the RAID 5 rebuild math above stops being a theoretical concern. RAID 6 is the correct specification for anything in this range, and for any deployment where a rebuild failure means a genuine gap in retained footage. RAID 60 — very large, multi-shelf recorders For the largest builds, where a single RAID 6 set would span an impractical number of drives or where you want to isolate rebuild activity to one shelf at a time, striping across multiple RAID 6 sets (RAID 60) is the usual next step. This is worth a mention for completeness rather than detailed treatment here, since it is a shelf-architecture decision as much as a RAID-level one. Sizing the array against your retention requirement Retention is what forces large arrays, and large arrays are what force this decision. Sector regulators, state advisories and individual tenders each set their own minimum period, and they differ enough that the only figure worth sizing against is the one written into the requirement in front of you. Take it from the tender document rather than from a rule of thumb, and confirm it applies to every camera rather than to a named subset. Work backwards from that figure for a multi-camera deployment and you arrive quickly at large-capacity drives and large drive counts — which is exactly the regime where the RAID 5 rebuild math stops being academic. A deployment retaining two months of footage across sixteen or more HD or 4K streams very often lands on 8TB-plus surveillance-rated drives across eight or more bays, and that is the point at which RAID 6 stops being a preference and becomes the specification. Use surveillance-rated or nearline drives for this calculation, not desktop drives. Desktop drives are not built for continuous read/write cycles or for the vibration load of a multi-bay chassis, and their firmware is not tuned for the sustained workload a 24/7 recorder places on it. Surveillance-class drives are typically rated for annual workloads in the 180TB to 300TB range, which is the figure to check against your actual camera count and bitrate before assuming a drive is fit for the job. Working out the actual numbers for your deployment The URE-probability arithmetic above is straightforward but it is easy to get wrong by hand, particularly once you start comparing RAID 5 against RAID 6 across different drive counts and capacities. Our RAID calculator works out usable capacity, rebuild-time estimates and the underlying URE exposure for a given drive count, capacity and RAID level, so you can compare RAID 5 and RAID 6 configurations against your actual retention requirement rather than a rule of thumb. For a fully specified VMS or NVR server built around this sizing, our surveillance and VMS server range is built and burn-in tested in India to the drive counts and RAID configurations this article describes. If you are sizing an array against a specific tender requirement or retention mandate, our technical team can work through the configuration with you directly.