Dell PowerEdge Server Down? Don't Rebuild the RAID — Call Us First.
UK enterprise data recovery since 2002. PERC H310/H330/H730/H740/H755, all RAID levels, Windows Server, VMware ESXi, Hyper-V. Emergency turnaround for business-critical servers. No-fix-no-fee.
What this means and what to do next
When a Dell PowerEdge server goes down with a RAID failure, the cost is rarely the hardware — it is the business interruption. ERP systems, Exchange databases, SQL Server instances, file shares, virtual machine datastores: a PowerEdge running production workloads typically holds the operational heart of an SME or a department. Data Clinic recovers data from failed PowerEdge servers regularly, across every PERC generation from H200 through H755, and across every RAID level Dell ships.
The most common PowerEdge failure pattern we see is not a single disk dying. It is a long-running degraded array — one disk failed weeks ago, nobody noticed because the email alert went to an inbox no one reads, and then a second disk fails on a RAID 5 and the array goes offline in the middle of a working day. PERC controllers handle this transition badly: the array drops to Inactive or Foreign state, the operating system loses its disk, virtual machines hang, and the natural reaction is to try to recover the array through the iDRAC or OMSA UI. That reaction is the moment most recoverable data is destroyed.
The recovery path for a PowerEdge depends on the controller, the number of failed disks, and what has happened since the failure. In almost all cases the right first action is the same: stop the server, document the physical layout, and image every disk as a forensic copy before any rebuild is attempted. Once the images exist, the array can be reconstructed virtually on our equipment — meaning the original disks are never written to, the RAID configuration can be tried multiple ways, and the data can be extracted file-by-file regardless of whether the array is technically rebuildable.
The common Dell PowerEdge failure scenarios — and what they mean for recovery
1. Two or more disks failed on a RAID 5 (or three on RAID 6). This is the catastrophic case. The array is offline, the OS is gone, the VMs are unreachable. The PERC controller will offer to import the foreign configuration or initialise a rebuild — neither action is safe. The recoverable state of the array is captured in the physical disks as they sit right now. Every action taken by the controller after the second disk failure has the potential to write parity data that wasn't there at the moment of failure, corrupting otherwise recoverable files. The recovery path is to image all surviving disks, identify which disk failed first (usually the one with older SMART logs), and reconstruct the array using the surviving disks plus the first-failed disk's image — not the second-failed disk.
2. PERC controller failure or battery fault. PERC controllers have an onboard cache (typically 512MB or 1GB) protected by a battery or capacitor. If the battery fails and the server loses power before the cache can be flushed to disk, the array can come back inconsistent — the parity does not match the data. Symptoms: filesystem corruption messages on boot, missing files, VMs that won't start. A PERC controller can also fail electrically: the same model controller will read the array configuration if swapped in correctly, but a mismatched controller or a forced configuration import can scramble the array. We image the disks first and then test controller swaps against the images, never the originals.
3. Failed firmware update on the PERC or the iDRAC. Firmware updates pushed through Lifecycle Controller occasionally fail mid-flash, leaving the controller in a state where it presents disks but cannot read array metadata. The disks themselves are intact and the data is intact — the controller just cannot assemble the array. Recovery is to image the disks, reconstruct the RAID parameters from the metadata patterns Dell uses, and extract the filesystem. We see this most often after a Lifecycle Controller catalog update that bundles a PERC firmware change the customer didn't realise was included.
4. Virtual machine corruption on a working array. The hardware is fine, the array is online, but a specific VM's virtual disk (VMDK or VHDX) is corrupt — typically after an ESXi snapshot consolidation failure, a Hyper-V dirty shutdown, or a guest OS filesystem corruption inside the VM. The data is recoverable but the recovery is at the VMDK/VHDX level, not the array level. We mount the virtual disk file as a forensic image and recover the guest filesystem (NTFS, ext4, XFS) using the same techniques as a physical drive recovery.
How Data Clinic recovers data from a failed Dell PowerEdge server
When you call about a PowerEdge that has gone offline, the first thing we do is talk you through how to safely shut the server down without giving the controller a chance to attempt automatic recovery. We then arrange same-day or next-day collection from anywhere in the UK by secure courier — or, for the most critical cases, we can dispatch an engineer to your data centre to image the disks on site so the server itself never leaves the premises.
Each physical disk is then imaged on our PC-3000 platform using the manufacturer's diagnostic firmware to handle any disks that are themselves failing. Once we have forensic images of every disk, the original disks are set aside untouched. RAID reconstruction is performed virtually against the images, which lets us test multiple disk-order, stripe-size and parity configurations without risking the only copy of the data. For VMware datastores, we mount the VMFS and extract VMDKs individually — typically prioritising the production VMs your business is waiting on.
Recovered data is delivered on a new external drive, a NAS, or directly into a fresh storage volume on a replacement server that we can build to your specification. We provide a written technical report describing the failure, the recovery actions taken, and the integrity of the recovered data — standard documentation for insurance claims, supplier disputes, and compliance audits. More about our RAID data recovery service →.
Get a free initial diagnosis in 60 seconds
Use the diagnostic tool below to capture the failure signature on your PowerEdge — array status, OMSA / iDRAC messages, and how many physical disks have dropped. We'll route the case to the right engineer based on what you tell us.
What our customers say
"Three years of family photos on a drive that suddenly failed. Data Clinic collected next day, kept me updated through the cleanroom work, and got everything back. Worth every penny."
"Honest, fixed-price, no-fix-no-fee. Quoted by another lab at three times the price. Recovered 100% of my files."
"Reasonable cost, clear communication, and they were straight with me about what was recoverable and what wasn't. Recommended."
Frequently asked questions
Can you recover a PowerEdge with two failed disks on a RAID 5?
In most cases yes, provided no one has tried to force the array online or initiated a rebuild after the second failure. The data is captured in the physical state of the surviving disks plus the first-failed disk — recovery is a matter of imaging all of them and reconstructing the array virtually. The second-failed disk is often physically failing and may need cleanroom work to image, but the array can usually be reconstructed without it as long as the first-failed disk's image is good. Call before doing anything to the server.
My PERC is showing the disks as Foreign — should I import the configuration?
Not until we have spoken. A Foreign configuration import will rewrite the controller's metadata on the disks based on what it currently thinks the array should look like. If the import succeeds the array may come back; if it doesn't, the original metadata is gone and recovery becomes significantly harder. The safest action is to leave the disks as Foreign, power the server down, and call us. We can advise on whether the import is safe given the specific failure pattern.
We have a backup but it is 36 hours old. Should we restore from backup or recover the array?
Both, in parallel. Start the restore from backup onto replacement hardware so the business has a working system to keep operating. Send the failed disks to us in parallel — we can typically deliver the last 36 hours of data (the gap between the backup and the failure) as a separate dataset, which you can merge into the restored system. This minimises downtime and minimises data loss simultaneously.
How long does PowerEdge RAID recovery take?
Imaging the disks takes 12–48 hours depending on the capacity and health of each disk. RAID reconstruction and data extraction typically takes another 24–72 hours depending on the complexity of the configuration and the number of VMs. For standard cases, expect 3–7 working days from collection to data delivery. For emergency service (charged at a premium), we target 48–72 hours for the critical VMs and follow up with the remaining data after.
Will the recovery work on a vSAN cluster, not just a single host with local PERC?
Yes. vSAN failures (typically two-host-failure scenarios on a three-host cluster, or component object corruption after a maintenance window) are recoverable but more complex than single-host PERC failures. We image every disk in every host, reconstruct the vSAN object layout, and extract the VMDKs. vSAN recovery is best handled by sending the entire cluster (or all the disk groups) — partial sets significantly reduce what we can recover.
Do you cover other server platforms — HPE ProLiant, Lenovo ThinkSystem, Supermicro?
Yes. The principles are the same: image the disks first, reconstruct the array virtually, extract the data. HPE Smart Array controllers, Lenovo MegaRAID, Supermicro Broadcom — all use RAID metadata patterns we recognise. The diagnostic tool below covers all major server platforms; if your server isn't listed, call and we'll discuss it.