Hot Spares: Global vs Dedicated and Getting Them Right
A hot spare is a drive sitting in the server doing nothing, waiting for another drive to fail so the controller can rebuild onto it automatically. It is one of the cheapest pieces of resilience you can buy, and it is also one of the most commonly misconfigured, because a spare that is the wrong size or the wrong interface looks exactly like a working one until the day it is needed.
This guide covers what a hot spare actually buys you, the difference between global and dedicated assignment, the matching rules that decide whether a spare can be used at all, and the monitoring gap that lets a rebuild happen without anybody noticing.
What a hot spare actually buys
It buys time, not capacity. The spare contributes nothing to usable space and nothing to performance. What it removes is the gap between a drive failing and a human putting a replacement in the bay.
That gap is the whole risk. A parity array running degraded has no protection left, and every remaining drive is working harder than usual during a rebuild. If the failure happens on a Friday evening and someone arrives on Monday, the array spent an entire weekend one failure away from total loss. A hot spare starts the rebuild within seconds.
On large drives this matters more than it used to. A 12TB rebuild can run for a day or more, and adding two days of waiting on top of that is a long time to be exposed. Our guides on RAID levels and how long enterprise drives last cover why second failures cluster around rebuilds.
Dedicated hot spares
A dedicated spare is assigned to one specific array or disk group. It will only ever rebuild into that array, and it sits idle if a drive fails anywhere else.
Use dedicated when the arrays are not equal. If one array holds the production database and another holds a scratch volume, a dedicated spare on the database guarantees it is there when that array needs it. With a shared pool, the scratch volume could take the spare first purely because it failed first.
Dedicated also makes sense when arrays differ in drive type, because a spare that only fits one of them is effectively dedicated anyway.
The cost is utilisation. Dedicating one spare per array on a server with three arrays means three idle drives and three bays consumed.
Global hot spares
A global spare is available to any array on the same controller that it is compatible with. One drive covers several arrays.
Use global when the arrays are similar in importance and built from similar drives. It is the better default for most servers, because the probability of two arrays failing before you can replace the first drive is low, and you get the same protection from fewer idle drives.
The catch is first come, first served. The controller does not know which array matters more. If the array you care least about fails first, it takes the spare, and the important array is now unprotected until you physically replace something. If that outcome is unacceptable, dedicate.
A common middle path on larger servers is a global spare for the general pool plus a dedicated spare on the one array that must never be exposed.
The matching rules that catch people out
This is where configurations silently fail. A spare must be usable by the array, and the requirements are stricter than people assume.
Capacity. The spare must be at least as large as the drive it replaces. Larger is acceptable, and the excess is wasted. Smaller is rejected, and a 900GB spare assigned to an array of 1.2TB drives will simply never be used. The controller may accept the assignment without complaint.
Interface. A SATA drive cannot replace a SAS drive. On many controllers the reverse is also blocked, and mixing within an array is usually prevented anyway. Our guide on SAS versus SATA versus NVMe covers why.
Sector format. A 512n spare and a 4Kn array are not compatible, and this one is easy to get wrong when buying a replacement years after the original build. See 512n, 512e and 4Kn.
Rotational speed, in practice. A 7,200 RPM spare will usually rebuild into a 10K array, and then the array runs at the speed of its slowest member. It works, but performance quietly drops and nobody connects the two events.
The carrier. The spare has to be in the bay, which means it needs the correct caddy for that server generation. Our guide on backplanes, caddies and bay blanks covers identification.
Verify the assignment took effect rather than trusting that you made it. The reliable test is what the controller reports about the spare's state, not what you remember configuring.
Copyback, and why there are two rebuilds
Most controllers support copyback, and it surprises people the first time they see it.
When a drive fails, the array rebuilds onto the spare. The array is now healthy, but it is running on what used to be the spare, and there is no spare left. When you replace the failed drive with a new one, copyback copies the data from the spare onto the new drive so that the array returns to its original slot layout and the spare goes back to being a spare.
That means a second rebuild-length operation after you swap the drive. It is not a fault. If you are timing maintenance, plan for it, and expect degraded performance during both passes.
Some controllers can also start a copy to the spare on a predictive failure rather than waiting for the drive to die, which is better because the original drive is still readable and the array never runs degraded. If your controller supports it, turn it on. Our guide on reading drive health data covers the attributes that trigger it.
How many spares
There is no universal number, but some reasonable anchors:
Every parity array holding data you care about should have access to at least one spare, global or dedicated. An array with no spare and no engineer on site is a weekend of exposure waiting to happen.
One spare per enclosure or shelf is a common pattern on larger storage, because it keeps the rebuild traffic local and avoids a spare that is technically compatible but on the wrong side of an expander.
More spares on larger drives. The longer the rebuild window, the more valuable a second spare becomes, because it covers a failure during the rebuild.
Keep cold spares on the shelf as well. A hot spare is consumed the moment it is used. If your supplier needs a week to get you a drive for an end-of-life platform, the shelf spare is what lets you restore protection quickly. Our guide on spares strategy for end-of-life hardware covers how many to hold.
The monitoring gap
Here is the problem with hot spares working properly: they hide the failure.
A drive fails at 2am. The controller rebuilds onto the spare. By morning the array is optimal and performance is normal, and unless something was actively watching, nobody knows anything happened. The server now has a failed drive in a bay and no spare, and the next failure is the one that hurts.
So the alerting has to cover more than array health:
- A physical drive changing to failed or predictive failure state
- A rebuild starting or completing
- A hot spare changing from available to in use
- The spare count for each array dropping to zero
The last one is the one people leave out, and it is the one that tells you protection is gone while everything still reports as healthy. Our guide on hardware monitoring covers the wider set of signals worth alerting on.
And the obvious point that still needs making: a hot spare protects against a drive failing. It does nothing about deletion, corruption, ransomware, a controller fault or a fire. See the 3-2-1 rule and why RAID is not backup.
Sourcing
We supply enterprise SAS and SATA drives with carriers matched to the server generation, which is what a usable spare actually requires. If you are adding spares to an existing array, send us the service tag or an existing drive part number and we will match capacity, interface, speed and sector format rather than just the size. Request a bulk quote or email sarah.jane@techsellerusa.com.
Common questions
What is the difference between a global and a dedicated hot spare?
A dedicated spare is assigned to one specific array and will only rebuild into that array. A global spare is available to any compatible array on the controller. Global gives better utilisation because one drive covers several arrays; dedicated gives certainty, because the spare cannot be taken by an array you care less about. A common approach on larger servers is a global spare for the general pool plus a dedicated spare on the one array that must never be exposed.
Can a hot spare be a different size from the array drives?
It can be larger, and the extra capacity is simply wasted. It cannot be smaller. A spare smaller than the drives in the array will never be used, and the dangerous part is that some controllers accept the assignment without complaint, so the configuration looks correct right up until the day a drive fails and nothing happens. Always verify what the controller reports about the spare rather than trusting that the assignment was made.
Why does my array rebuild twice after I replace a drive?
That is copyback working as designed. The first rebuild puts the data onto the hot spare when the original drive fails. When you fit a replacement in the failed slot, copyback copies the data from the spare back onto the new drive so the array returns to its original layout and the spare becomes a spare again. Plan for two rebuild-length operations and expect degraded performance during both.
Can I use a SATA drive as a spare for a SAS array?
No. A SATA drive cannot replace a SAS drive in an array, and most controllers will refuse the assignment or refuse to use it. Sector format matters too: a 512n spare cannot rebuild into a 4Kn array. Rotational speed is a softer constraint, in that a 7,200 RPM spare will usually rebuild into a 10K array, but the array then runs at the speed of its slowest member, which is a performance drop nobody connects to the rebuild months later.
How many hot spares should a server have?
At minimum, every parity array holding data you care about should have access to one, global or dedicated. On larger storage, one spare per enclosure is a common pattern because it keeps rebuild traffic local. Add more where the drives are large, because a long rebuild window increases the chance of a second failure during it. Keep cold spares on the shelf as well, since a hot spare is consumed the moment it is used.
Do hot spares mean I do not need monitoring?
The opposite. A hot spare working correctly hides the failure: the drive fails overnight, the rebuild completes, and by morning the array reports optimal with normal performance. The server now has a dead drive in a bay and no remaining spare, and nobody knows. Alert on drive state changes, rebuild start and completion, and specifically on an array's available spare count reaching zero. That last one is the signal that protection is gone while everything still looks healthy.
If you are adding spares to an existing array, send us the service tag or an existing drive part number and we will match every attribute that has to line up, not just the capacity.
