For most surveillance servers, the answer is no more than 12 drives per RAID 6 set. Past 12 bays, the right build is RAID 60: two or three separate 12-drive RAID 6 sets striped together into one array, instead of one array spanning every drive in the chassis. That is the standard Arxys builds to on every VideoX appliance with more than 12 bays, and it is a decision we made deliberately after modeling how these arrays actually behave when a drive fails under a live recording load.
The 16-bay is the one chassis that breaks this rule on purpose, and it is worth knowing why before a client asks.1 It runs as a single 16-drive RAID 6 instead of splitting into smaller sets, because at 16 drives the capacity cost of a second RAID 6 set (another two drives’ worth of parity overhead) stops being worth it, and a single 16-drive set keeps more capacity usable while holding the box at the price it needs to be. The rebuild exposure is a little wider than a 12-drive set’s, but it stays inside the window we are comfortable standing behind, which is why we make that one exception and no others.
Here is the one line worth keeping in your back pocket for the next client walkthrough:
“The best balance of efficiency and protection is no more than 12 drives per RAID set. Anything bigger, 24-bay or 36-bay, gets split into two or three 12-drive RAID 6 sets striped together as RAID 60, instead of one giant array.”
Say that once in a walkthrough and you have said more about how the box actually protects footage than most spec sheets do in a page. And when a sharper integrator pushes on it, the answer holds, because the 12-drive cap is a choice we made on purpose, not a hardware limit we are hiding behind.
Why stripe width is the number that actually matters
RAID 6 gets sold as the fix for large drives, and it is, up to a point people do not usually mention. RAID 6 survives two drive failures in the same set. What it does not do is shrink the window you are exposed during a rebuild. That window is the real risk, and stripe width, how many drives sit in one RAID 6 set, is what drives it.
Here is the part that trips people up. Stripe 24 or 36 drives into a single RAID 6 set, and a rebuild does not take dramatically longer than a 12-drive set would. Every drive in the set is read in parallel to reconstruct the failed one, so wall-clock rebuild time is bound mostly by how fast the replacement drive can be written, not by how many drives are being read. The danger of a wider set is not a slower rebuild. It is that you now have 24 or 36 drives all under sustained read stress at the same time, for the full length of that rebuild, on today’s high-capacity disks that can run well over a day. More drives under stress for the same long window means a higher chance that one of them throws an Unrecoverable Read Error (URE) or fails outright before the rebuild finishes. That is the exposure that actually loses arrays.
Splitting a 24 or 36-bay chassis into 12-drive sets under RAID 60 keeps that exposure contained. If a drive dies, only the 11 surviving drives in its own 12-drive span carry the rebuild read load. The other one or two spans keep recording and serving playback without taking on any of that rebuild stress. Each span runs its own dual-parity protection, and while RAID 60 stripes those spans into a single volume, the rebuild I/O stays local to the span that lost a drive. That is the trade: a few drives of capacity against a much smaller pool of drives exposed during every rebuild. Not a close call.
We planned the rebuild times, not just the redundancy
Most vendors quote you a RAID level and stop there. We went further, because the RAID level only tells you what happens the instant a drive dies, not how long you sit exposed afterward. On a 12-drive RAID 6 span built from 24TB enterprise helium drives, running behind a Broadcom hardware RAID controller with a live 200-camera H.265 recording load, we modeled a real single-drive rebuild in the range of roughly 40 to 55 hours. Not a spec-sheet fantasy of an idle array, but the number you actually get while cameras keep writing footage the whole time the rebuild runs.
That figure is why the 12-drive cap exists. A hardware RAID controller reconstructs the full drive during a rebuild, so a bigger set does not finish faster, it just puts more drives under that same multi-day stress. Keeping each span at 12 drives holds the pool of exposed drives small, and pairing that with RAID 60 on the larger chassis means a rebuild in one span never touches the others. We also leave rebuild priority tuned so the controller leans harder into the rebuild during quieter recording periods and backs off when cameras are busy, which keeps footage capture intact without letting the rebuild drag on longer than it has to. This is the level of detail that separates a box that was designed for surveillance from a general-purpose server that happens to have drive bays.
RAID terms, in plain English
You do not need the engineering-class version of any of this to use it correctly in front of a client. Here is the field version.
| Term | What it means, in one line |
| Parity | Extra data written alongside your footage that lets the array rebuild a drive that dies, without needing that drive’s original data. |
| RAID 6 | Dual parity per set, spread across every drive rather than sitting on two dedicated disks. Any two drives in the set can fail at the same time and the set keeps running. |
| Stripe / stripe width | How many drives sit in one RAID 6 set sharing the same rebuild. This is the number that sets how many drives are exposed during a rebuild, not the bay count of the chassis. |
| Span | One complete RAID 6 set (12 drives, in our builds) inside a larger array. Each span fails and rebuilds on its own. |
| RAID 60 | Multiple RAID 6 spans striped together into one array the OS sees as a single volume. Full RAID 6 protection inside each span, with rebuild stress contained to the span that lost a drive. |
| P + Q Parity | The two math schemes a hardware RAID controller uses to calculate RAID 6’s dual parity: XOR for the first parity block (P), Galois Field algebra and Reed-Solomon coding for the second (Q). Together they let the set survive two simultaneous drive failures. |
What to say when the client keeps asking
These are the follow-ups that come up most in a walkthrough, with the answer that holds up.
“Isn’t that wasteful, more parity?”
You are giving up the capacity equivalent of two drives per 12-drive span instead of two for the whole chassis, yes. RAID 6 parity is distributed across all the drives in a span rather than parked on dedicated disks, and reserving that overhead per span is what keeps rebuild stress contained to one small pool of drives instead of the whole array. The capacity you trade buys you a much smaller exposure window on every rebuild.
“What actually happens if a drive dies?”
Only the 11 surviving drives in that one 12-drive span carry the rebuild. The other one or two spans in the chassis keep recording and serving playback, untouched by the rebuild load. The one thing worth being precise about: RAID 60 stripes those spans into a single volume, so each span tolerates two failures on its own, but a third failure inside any single span before its rebuild finishes takes the whole volume down. That is exactly why we keep each span small and the rebuild window short.
“So how many drives can I actually lose?”
Two per span, safely. On a 24-bay running two spans, that is up to four drives total, as long as no single span loses more than two. On a 36-bay running three spans, up to six total, same condition. It is not “any four drives anywhere,” it is two per span, and knowing that difference is what keeps you from overpromising to a client.
“We’ve always used RAID 5, why change now?”
RAID 5 was fine when drives were 2TB. On today’s 16TB-plus drives, a single-parity rebuild can run well over a day, and a single second failure or URE during that window loses the array outright. RAID 6 is the floor now, not the upgrade.
“Does this get worse as drives get bigger?”
It does, which is exactly why the 12-drive cap is not arbitrary. Drive capacity keeps climbing every generation, rebuild windows stretch right along with it, and the exposure math this policy is built around keeps getting less forgiving, not more.
RAID protects the drives. It does not protect against a power failure.
One more piece worth having straight before a client asks, because it is easy to conflate two things that solve different problems.
Every Arxys server with a hardware RAID controller ships with a CacheVault module. When the controller caches a write before it hits disk, CacheVault gives the controller just enough backup power to flush that cached write safely to flash the instant power drops, so an in-progress write survives a sudden outage instead of getting corrupted or lost. It protects the controller’s cache for the few seconds it needs, not the server.
A UPS is a separate, necessary layer on top of that. It keeps the whole server running long enough to shut down cleanly, or ride out a short outage entirely. CacheVault protects the write in flight; a UPS protects the server it is flying through. Every Arxys deployment needs both. Recommend a UPS on every job, full stop, and you have closed the one gap CacheVault was never designed to cover.
If a client is already feeling the pinch of rising drive prices covered in our recent piece on HDD cost trends, this is the other side of that same coin: the drives are getting more expensive and the stakes of losing an array to a bad rebuild are climbing right along with them. A 12-drive RAID 60 set and a UPS on every install is how that risk gets managed instead of just hoped away.
1 The 16-bay is the only Arxys chassis where we do not apply the 12-drive cap. Every other capacity follows the doctrine above without exception.
