A server that was working yesterday and is dead this morning is almost never a lost-data situation on its own. The data is still on the drives. What decides whether you get it back is what happens in the next hour: which buttons get pushed, which drives get pulled, and whether anyone tries a rebuild. This guide walks through the checks in the order we would do them, and it is blunt about the steps that turn a recoverable outage into a permanent loss.
- Do not re-create, re-initialize, or rebuild a RAID array to see if it comes back.
- Do not run CHKDSK, fsck, or a file system repair on a volume that suddenly went missing.
- Do not pull drives out of a running server. If you must, power down first and label every drive with its bay number.
- Do not accept a prompt that offers to initialize a disk or format a volume.
First ten minutes: what to check, in order
- Power and fans. No lights and no fans means a power supply, a power strip, or a breaker. That is the best news you can get, because the drives are untouched.
- Beeps and LEDs. Write down the beep pattern and any amber or red drive lights. Photograph the front of the server with the bay numbers visible. On a NAS, note the exact message on the display or in the app.
- What the screen says. A message from the RAID controller (degraded, foreign configuration, missing member) is different from an operating system error. Write it down word for word before rebooting.
- Whether it reaches the operating system. If it boots but a share or a volume is missing, stop here and go to the section on missing volumes. The array has a problem and the OS is offering to make it worse.
- Network, switches, and the router. Users saying the server is down sometimes means the switch is down. Ping the server from a machine on the same switch before assuming the box has failed.
What the symptom usually means
| What you see | Most likely cause | Risk to data |
|---|---|---|
| No power, no fans | Power supply or upstream power | Low. Drives are fine. |
| Powers on, no display, beeps | Memory, motherboard, or CPU | Low. Drives are fine, but do not try random parts swaps. |
| Controller says degraded | One member drive failed | Medium. The array still works, but a second failure ends it. Replace only after backing up. |
| Controller says foreign config or missing array | Controller lost its configuration, or drives were moved | High. Importing the wrong configuration or re-creating the array overwrites metadata. |
| Boots, but the data volume is gone | Array or file system damage | High. Any repair or initialize prompt is destructive. |
| NAS beeping, drives clicking | Mechanical drive failure inside the array | High. Power down; a clicking drive damages itself every minute it runs. |
The three mistakes that lose the data
1. Rebuilding onto a failing drive
A degraded array still serves data from the remaining drives. When a new drive is inserted, the controller reads every sector of every surviving drive to rebuild parity. If one of those survivors has bad sectors, which is common in drives that were bought and installed together, the rebuild stalls or the controller drops the second drive. Now the array is offline and two drives need cleanroom-grade imaging instead of one.
2. Re-creating the array
Creating a new array with the same drives looks harmless in the controller menu. It writes fresh metadata and, on many controllers, starts a background initialization that zeroes parity. The old data is still physically there for a while, but the map to it is gone, and every hour of initialization overwrites more.
3. Running repairs on the volume
CHKDSK and fsck were written for single healthy disks with minor file system faults. Run against a volume sitting on a broken array, they see garbage and confidently rewrite it. We regularly receive servers where the array could have been rebuilt virtually, but the repair tool had already rewritten the directory structure.
Hardware failure or software failure?
A rough rule: if the problem appeared after a power event, a physical move, or years of uptime, suspect hardware. If it appeared after an update, a configuration change, a failed backup job, or a ransomware notice, suspect software. Hardware failures are usually the easier recovery, because the data is intact and only the path to it is broken. Software failures range from trivial to severe, and the severity depends almost entirely on how much was written after the fault.
What a data recovery lab actually does with a dead server
- Every member drive is imaged individually on hardware that tolerates bad sectors, so a weak drive is read once, gently, and never again.
- The array is rebuilt virtually from the images. Drive order, block size, parity rotation, and offset are worked out from the data itself, not from the controller.
- The file system is reconstructed from the virtual array and files are extracted to new media. Your original drives are not written to at any point.
- For NAS units, the same process applies. Most consumer and small business NAS boxes use standard Linux RAID and file systems underneath.
This is the process behind our RAID and server data recovery service, and it is why the first instruction is always to stop and power down rather than experiment. See also our guide to hard drive failure symptoms if one of the member drives is clicking or not spinning.
Getting back online after the recovery
Recovered data comes back on new drives or by secure download. Before you rebuild the server, replace every drive from the original batch, not only the one that failed, and put the new array on a backup schedule that has actually been tested with a restore. A RAID array is not a backup. It protects uptime, not data.
Frequently asked questions
Can data be recovered from a crashed server?
In most cases, yes. A server that will not boot usually has a failed drive, a failed controller, or a corrupted volume, and the data is still on the disks. The cases we cannot help are the ones where someone re-created the RAID array, forced a rebuild onto a failing drive, or ran a repair that overwrote the data before the drives reached a lab.
Should I rebuild the RAID array myself?
Not until you know why it degraded. A rebuild reads every sector of the remaining drives, and if a second drive is weak, the rebuild fails part-way and can leave the array in a state that is much harder to recover. If the data matters, image the drives first or send them to a lab that will.
Two drives failed in my RAID 5. Is it gone?
Not necessarily. Drives are often dropped from an array for transient errors while most of their data is still readable. A lab images each member drive individually, then rebuilds the array virtually from the images, using the healthiest copy of every block.
The server boots but the data volume is missing. What happened?
The operating system is on a separate disk or partition from the data, and the data volume has either lost its RAID configuration, its file system, or one drive too many. Do not initialize the disk when Windows or the NAS interface offers to. Initializing writes a new empty structure over the old one.
How long does server data recovery take?
We evaluate the drives within 48 hours of receiving them and send a written quote. Most standard recoveries are completed in 10 to 12 business days after you approve the quote, and faster options are available for an added fee. Server jobs with many drives can take longer because every drive is imaged in full.
Server or NAS down with data on it?
Power it down, leave the drives in place, and talk to us before anyone attempts a rebuild. Free evaluation, written quote, no data no fee.
RAID & Server RecoveryContact UsInstant AI Evaluation
