A 110-user business locked out of its file server after a RAID configuration was reset by accident. No disk had failed — the array simply no longer existed as far as the controller was concerned.
← All case files · from £500 + VAT
A business of roughly 110 staff lost its main file server after RAID controller settings were reset during routine maintenance. The effect was immediate and total — financial records, HR files and client databases all became unreachable at once, and a company of that size stops working very quickly without them.
What made it unusual is that nothing had actually broken. Every disk was healthy and spinning. What had been destroyed was the controller's description of how those eight disks fitted together: stripe size, disk order, parity rotation. The data was entirely intact and completely unreadable at the same time.
no reallocated sectors of consequence, no mechanical symptoms, no SMART warnings.
which meant a full reconstruction was arithmetically possible rather than merely hopeful.
and on this controller family that configuration isn't written back to the members in a form the array can restore by itself.
The temptation in this situation is obvious and dangerous: re-create the array through the controller and see whether it mounts. On many controllers, creating an array initialises it — and initialisation writes. Doing that would have overwritten the structures needed to work out the original geometry, converting a straightforward job into a poor one.
Every disk was imaged read-only before any analysis started, and all subsequent work ran against those images rather than the originals. The geometry was then re-derived from the data itself. Stripe boundaries were located by looking for structural repetition across members; disk order was established by testing candidate permutations against known file-system structures until one produced coherent metadata instead of noise; parity rotation and offset were confirmed the same way.
With the geometry proven rather than assumed, the RAID 5 was assembled virtually — entirely outside the original controller, which was never asked to rebuild anything.
Everything. The file system mounted cleanly from the assembled volume, and the recovery was complete because all eight disks were healthy, the parity was intact, and only the map had ever been missing.
Databases were checked for structural consistency rather than simply copied across, and payroll and financial records were opened and confirmed against the structure the client expected before the set was returned on fresh media. The business resumed with its records whole, four days after the disks arrived.
A lost configuration is not lost data. When a controller forgets an array, the contents are almost always still sitting on the disks exactly as they were — what has gone is the description of how to read them, and that can be reconstructed by analysis.
The thing that turns this into an unrecoverable job is what gets done next. Don't initialise, don't re-create the array to “see if it works”, and don't let a rebuild run. Power the server down, keep the disks in bay order, label them, and send them in. Server and RAID recovery starts from £500 +VAT, quoted in writing after a free 48-hour diagnostic.
Not by rebuilding it. Every member is imaged read-only first, then the array geometry — stripe size, disk order, parity rotation and offset — is re-derived from the data and the array assembled virtually from those copies. Parity fills any stripe where only one member is unreadable. Forcing a controller rebuild writes to the disks and is the most common way a recoverable array becomes an unrecoverable one.
RAID, NAS and server recovery starts from £500 plus VAT, fixed in a written quote after a free 48-hour diagnostic. Where drive-level physical work is needed we take a 50% deposit up front, with the balance payable only on a successful recovery.
Either works, but bay order is what matters. Label each disk with its bay number before removing it, and note the controller model if you can. Don't run a rebuild and don't re-insert a disk the controller has ejected.
Bring the drive to our Oxford Science Park reception, or post it over — it costs nothing to learn what went wrong. You’ll have a written figure from the fixed bands before any work begins.