RAID Rebuild Speed: Priority Settings and What Slows It Down
A rebuild is the most dangerous period in the life of a RAID array. Protection is gone or reduced, every surviving drive is working harder than usual, and the set stays that way until the rebuild finishes. How long that takes is not fixed. It is largely a setting, and on most servers nobody has ever looked at it.
This guide explains what the rebuild priority setting actually does, what really limits rebuild speed, how to estimate how long a rebuild will take, and why the background tasks running on your controller may be the reason it is crawling.
What rebuild priority controls
Every hardware RAID controller has a setting that decides how it splits its effort between serving the host and rebuilding the array. Vendors name it differently — rebuild rate, rebuild priority, background initialisation rate — but it works the same way, usually as a percentage.
At a low setting the controller prioritises the application. Users barely notice the rebuild, and the array stays degraded for much longer. At a high setting the rebuild finishes sooner and the application feels it.
Defaults are conservative. Many controllers ship around 30%, chosen so that a rebuild never generates complaints. That is a reasonable default for a vendor and frequently the wrong choice for you, because it optimises for comfort during the exact window when the array is least protected.
The trade-off, stated honestly
Raising the rate is not free. On a busy array, a high rebuild priority produces real, noticeable latency for users. The question is which risk you prefer.
On a RAID 5 set, a second drive failure during the rebuild destroys the array. That is not theoretical: drives bought together tend to fail together, and the rebuild puts every remaining member under sustained full-stripe read load, which is exactly the workload most likely to expose a drive that was already marginal. Our guide on how long enterprise drives last covers why correlated failure is normal rather than bad luck.
So for a parity array holding data that matters, a slow day is usually the better trade than a long exposure. For a RAID 10 or RAID 6 set, where a second failure is survivable, you can afford to be gentler.
What actually limits the speed
Raising the priority helps only if the priority is the constraint. Often it is not.
The replacement drive's write speed is the hard ceiling. A rebuild cannot write faster than one drive accepts data, no matter how fast everything else is. On a 7,200 RPM nearline drive that is on the order of a couple of hundred megabytes per second sequentially, and considerably less once host I/O is interleaved.
RAID level changes the work. Rebuilding a mirror is a straight copy. Rebuilding RAID 5 means reading every remaining drive and recomputing parity for every stripe. RAID 6 recomputes two parity values. More protection means more rebuild work.
Host load competes directly. A rebuild on an idle array can run several times faster than the same rebuild on a busy one.
Background tasks compete too, and this is the one people miss. Patrol read, consistency check and background initialisation are all scheduled controller activities that consume the same resources. A consistency check that kicked off on schedule mid-rebuild will slow the rebuild substantially. If a rebuild is inexplicably slow, check what else the controller is doing before touching the priority.
A failing neighbour slows everything. If another drive in the set is returning errors and retrying, the rebuild waits on it. Our guide on reading drive health data covers spotting that drive before it becomes the second failure.
Estimating how long it will take
The arithmetic is simple and the real answer is always worse.
Divide the capacity of one drive by the sustained write rate you can realistically achieve. A 4TB member rebuilding at 100 MB/s is roughly eleven hours of pure writing. At 50 MB/s, because the array is busy and priority is at default, it is over twenty.
Scale that up and the design implication becomes obvious. A 12TB or 14TB member can take a day or more, and on a heavily loaded array with a low rebuild rate, several days. That is the window a single-parity array is exposed for, and it is why RAID 6 rather than RAID 5 is the defensible choice above a few terabytes. See RAID levels explained.
The controller's own estimate is usually optimistic early on, because it extrapolates from an initial burst before host load arrives. Treat the first estimate as a floor.
Copyback means two passes
If the array rebuilt onto a hot spare, replacing the failed drive triggers copyback: the data is copied from the spare onto the new drive so the array returns to its original layout and the spare becomes a spare again.
That is a second operation of similar length. The array is not degraded during it, so it is far less urgent, but it does consume performance and it surprises people who thought they were finished. Our guide on global versus dedicated hot spares covers the behaviour.
What to do during a rebuild
Do not run the backup. A full backup during a rebuild adds heavy sequential read across every drive, which is the same load profile most likely to surface a second failure, while slowing the rebuild. Shift the schedule.
Do not start a consistency check or patrol read. Suspend scheduled ones if the window overlaps.
Avoid rebooting. Most modern controllers resume a rebuild after a restart, but it is an unnecessary risk during the one period where the array has no margin. If a reboot is unavoidable, confirm the rebuild resumed rather than restarted.
Do confirm the backup is current before you do anything else. A degraded array is the moment to discover whether your restore actually works, not after. See the 3-2-1 rule.
Set it before you need it
The rebuild priority is worth deciding deliberately, per array, while nothing is broken. Write the choice down with the reasoning, because the person handling the failure at 2am will not want to make that judgement call under pressure.
Alerting matters just as much. A rebuild that starts and completes overnight with nobody informed leaves you with a failed drive still in a bay and, if a hot spare was consumed, no remaining protection. Alert on rebuild start, rebuild completion, and available spare count reaching zero. Our guide on hardware monitoring covers the full set, and identifying RAID controllers and cache covers where these settings live on common platforms.
Sourcing
We supply enterprise SAS and SATA drives with carriers matched to the server generation, plus RAID controllers, cache modules and batteries for Dell PERC, HPE Smart Array and LSI platforms. If you are mid-rebuild and need the replacement drive matched exactly on capacity, interface, speed and sector format, send us the service tag or an existing drive part number. Request a bulk quote or email sarah.jane@techsellerusa.com.
Common questions
What does the RAID rebuild priority setting do?
It decides how the controller splits its effort between serving the host and rebuilding the array, usually expressed as a percentage. A low setting keeps application performance up and leaves the array degraded for longer; a high setting finishes the rebuild sooner at the cost of noticeable latency for users. Many controllers default to around 30%, which is chosen to avoid complaints rather than to minimise risk.
Should I raise the rebuild priority?
On a single-parity array such as RAID 5 holding data you care about, usually yes. A second failure during the rebuild destroys the set, and drives bought together tend to fail together, so shortening the exposure window is worth a slow day. On RAID 6 or RAID 10, where a second failure is survivable, you can afford to leave it lower and protect application performance instead.
My rebuild is extremely slow even at high priority. Why?
Priority only helps if priority is the constraint. Check whether a patrol read or consistency check is running, because those consume the same controller resources and are scheduled activities that can start mid-rebuild. Also check whether another drive in the set is returning errors and retrying, since the rebuild waits on it. Finally, the replacement drive's own sustained write speed is a hard ceiling no setting can raise.
How long should a rebuild take?
Divide one drive's capacity by the sustained write rate you can realistically achieve. A 4TB member at 100 MB/s is roughly eleven hours of pure writing, and at 50 MB/s on a busy array it is over twenty. A 12TB or 14TB member can take a day or considerably more. The controller's own early estimate is usually optimistic, because it extrapolates from an initial burst before host load arrives.
Can I run backups during a rebuild?
Better not to. A full backup adds heavy sequential read across every surviving drive, which is the load profile most likely to surface a second failure, and it slows the rebuild at the same time. Shift the schedule until the rebuild completes. Do make sure a current backup already exists before you start, because a degraded array is the wrong moment to discover the restore does not work.
Is it safe to reboot during a rebuild?
Most modern controllers checkpoint progress and resume after a restart rather than starting over, so it usually survives. That said, it is an avoidable risk taken during the one window where the array has no margin left. If a reboot is unavoidable, confirm afterwards that the rebuild resumed from where it was rather than restarting from the beginning.
If you are mid-rebuild and need a matching replacement drive quickly, send us the service tag or an existing drive part number.
