RAID Recovery

RAID recovery is not “run the vendor rebuild.” A rebuild reads every remaining disk hard and writes a new member. If a second disk is already weak — the usual reason the first one died — the rebuild is what kills the array. DiskDoctor clones every member first, including disks the controller marked failed, then reconstructs RAID 0, 1, 5, 6, and 10 in software from those clones.

RAID 0 has no parity. One dead disk means that stripe is gone unless the failed member can still be imaged. RAID 1 is a mirror; we clone both sides because the “healthy” disk is often the next to go. RAID 5 can survive one missing member if you do not rebuild onto a dying spare. RAID 6 can survive two, until someone starts a rebuild that stresses the remaining set. RAID 10 is mirrored stripes; two failures in the same mirror is a RAID 0 problem.

What to do: power the NAS, SAN, or RAID card down. Do not initialize disks in Windows. Do not run chkdsk on a member. Do not let Synology, QNAP, or a hardware card “repair” the volume. Label the slot order. Bring every disk, including ones that look fine.

What not to do: hot-swap a new disk into a clicking array. Reboot repeatedly hoping the volume mounts. Restore a backup over the degraded set. Send only the failed disk when the controller wrote parity across four others.

Rebuild versus recovery: a rebuild is a write operation the controller performs to regenerate a missing member. Recovery is a read operation we perform on clones. If the filesystem is already damaged, a rebuild will not put files back; it will finish destroying them. If you already started a rebuild, stop it and send the members anyway. Partial rebuilds are still often reconstructable.

Turnaround at the Columbia lab is typically 3–7 days for RAID after all members arrive. Emergency imaging is available by phone at (410) 937-7332. Evaluation is free. You get a fixed quote before paid work. No data, no charge on the recovery fee if we cannot retrieve the files you need. We do not publish a dollar menu because a two-disk RAID 1 is not a six-disk RAID 6 with a failed rebuild.

Enterprise and healthcare arrays are handled with chain-of-custody when you ask for it. Virtual disks sitting on RAID (VMDK, VHDX) are recovered after the array is reconstructed, not by installing a hypervisor on the broken members.

If another shop already ran recovery software on the live disks, say so. Remaining readable sectors can still be cloned. Every extra write lowers the odds. Ship or drop at 10015 Old Columbia Rd Suite B 215, Columbia, MD, or schedule Tysons.

Synology SHR, QNAP, Asustor, TrueNAS, Windows Storage Spaces, hardware cards from Adaptec, LSI/Broadcom, Dell PERC, and HP Smart Array all fail in the same human way: someone clicks Repair. The metadata layouts differ. The first physical step does not. Clone every member with hardware that can retry gently, then stop. We map stripe size, rotation, and parity position from those clones. Guessing the layout on live disks is how you add writes.

A clicking member is not “the failed disk you can ignore.” It still holds blocks the other disks do not. RAID 5 with one click plus a second timeout during rebuild is the classic two-hole stripe. RAID 6 with two clicks plus a rebuild is the three-hole case people think cannot happen. Both are why we ask for disks the controller marked failed, not only the ones that still blink green.

Slot order matters. Photograph the bays before you pull disks. If you already mixed them, send them anyway and say so. We can often brute-force order from clones; it takes longer. Do not install the members in a new NAS “to see if it mounts.” A new enclosure may initialize a foreign set.

Controllers also lie about “healthy.” SMART on a RAID member is often hidden or reset by the card. A disk that rebuilt yesterday can be the one that dies tomorrow because the rebuild was the heaviest read of its life. That is why a RAID 1 with one click still needs both clones, and why we do not trust a vendor status LED as a forensic fact.

After reconstruction we verify the filesystem — NTFS, ReFS, ext4, XFS, APFS, or a hypervisor datastore — on the assembled image, not by booting the original controller. If the array held VMs, we check VMDK/VHDX integrity next. A mountable NTFS volume that is missing the virtual disks is not a finished job.

Mail-in RAID: pad each disk separately, keep them in slot order in the box, include the NAS or card only if the layout is proprietary or you cannot pull the members safely. Do not send a running chassis with the array still rebuilding in the trunk of a car. Power it down at the office.

Delayed-write and cache: many NAS units acknowledge writes before they hit platters. A crash during a rebuild can leave a filesystem that looks mounted and is missing the last hours of files. We reconstruct what the clones hold. We cannot invent the writes that never reached disk. Say if you had a UPS event or a forced shutdown.

Encrypted arrays (BitLocker on a RAID volume, FileVault on a striped set, NAS volume encryption): we can often reconstruct the encrypted blob. We cannot unlock it without your key. Bring the password, recovery key, or KMIP note. “Can you just break it?” is not a service we sell.

Backup versus recovery: if last night’s backup finished, restore that and send the array anyway if you still need the gap. If the backup was the same RAID, you do not have a backup. A USB copy from three months ago is better than a rebuild. Do not restore a backup onto the degraded members.

SAN and virtualization: a LUN that disappeared after a controller failover is often still on the members. Do not present those disks to a new array as unused capacity. Clone first. VMware datastores and Hyper-V volumes are recovered after the RAID is assembled, then we check the virtual disks.

How to start: form on this page or call (410) 937-7332. List RAID level if you know it, how many disks, which bays failed, and whether a rebuild already started. Drop at Columbia or schedule Tysons. Evaluation is free. Fixed quote before paid work.