Request a quote → Server down · Emergency
Scenario · controller failure

RAID controller failed: the data is on the disks, not on the controller.

A failed RAID controller does not lose data in itself — most of the disks are still intact. The risk is doing the wrong thing on the replacement controller: initialisation, clear foreign config, an unintended rebuild. The correct procedure preserves the array.

What NOT to do

Three operations that end the recovery.

  • Initialize the array on the new controller: it destroys the existing configuration. It is the most destructive command in the controller menu.
  • Clear Foreign Config before reading it: you lose the information on slot order, chunk size and RAID level.
  • Pre-emptive rebuild with no actual degradation: it adds stress to the array at its most fragile moment and can lead to a double disk failure if one of the disks is marginal.
What we do

Safe re-import, in 4 steps.

  1. Preliminary documentation: physical disk order (photographed), output from the old controller if still readable, any pre-failure events.
  2. Controller replacement with an identical or compatible model (firmware matrix checked).
  3. Foreign config re-import: reading the vendor DDF / proprietary metadata, importing the array in the correct order, integrity check.
  4. Validation: array online in read-only mode at first, I/O verified error-free, then a gradual return to normal operating mode.
FAQ

The questions we get most often.

Does the new controller have to be exactly the same model?

Ideally yes. In practice it often works with a controller from the same family too (e.g. PERC H730 → H730P, Smart Array P440ar → P408i-a) provided the firmware is compatible and the RAID algorithm is supported. Cross-vendor (e.g. PERC → MegaRAID) does not work: the DDF metadata is different.

Without the old controller, how do you work out the slot order?

The DDF metadata (or the proprietary equivalent) written to the disks by the controller carries the slot information. On healthy disks this metadata is readable even without the original controller: we parse it to rebuild the array virtually before importing it onto the new controller.

What if the controller fault has already damaged the consistency of the array?

Rare but possible (e.g. a controller that kept writing partially during the fault). In that case the re-imported array will be inconsistent and has to be handled as a more complex RAID 5/6 recovery, working on clones. The initial diagnosis tells us whether we are in the simple scenario or the complex one.