One failed disk doesn't mean everything is lost.
RAID & Server Data Recovery for Businesses
When a RAID fails or the server stops reading data, repeated restarts or starting a new rebuild without inspection can multiply the problem.
- +25
- Years of experience
- +50K
- Cases handled
- 99%
- Success rate after diagnosis
Don't start a rebuild before understanding the array.
When does a business need a RAID inspection?
- 01
One or more failed disks
A Failed or Degraded disk appears inside the RAID array.
- 02
File access stopped
Shared folders or server services are no longer available.
- 03
Rebuild or NAS failure
A rebuild failed, or the NAS and SAN stopped reading data.
Every disk carries part of the story.
RAID data recovery
The data is spread across more than one disk. We start by understanding the storage structure, the number of disks, the RAID type and error messages, then choose the right path while preserving disk order and settings.
Inspect the case
Choose the path
Safe recovery
Supported devices & brands
Servers and storage systems we work with
Every RAID controller has its own way of writing and ordering data across disks. These are the environments that most often reach the lab, and what changes in handling each one.
Dell PowerEdge servers
PERC controllers keep array metadata both on the controller and on the member disks. Importing or clearing a foreign configuration can rewrite that metadata, so we read the disks outside the controller first.
HP ProLiant servers
Smart Array controllers write their own metadata to the start of every member disk, and the bay a disk came from is part of the answer. We record the position of each disk before it leaves the chassis.
Synology NAS
Built on mdadm and LVM with Btrfs or ext4 above them, and SHR can spread different disk sizes across more than one array level. The whole structure has to be understood before anything is assembled.
QNAP NAS
Thin volumes and snapshots add a layer above the array itself. Damage to that layer can block access to the files even when every disk reads perfectly.
Software RAID
Windows Storage Spaces and Linux mdadm hold the array definition inside the operating system rather than in separate hardware. When the system is gone, the layout has to be derived from the disks themselves.
SAN and disk shelves
LUNs, VMFS volumes and virtual disk files mean an array inside an array. We rebuild the lower layer first, then open the virtual disks stored within it.
How we handle a stopped array
- 01
Document the array before touching it
We record the RAID type, the disk count, every bay number, the controller model and the log messages. Disk order is labelled physically, and nothing is written to any member disk.
- 02
Image every disk read-only
Each disk is copied sector by sector through a read-only interface in the lab. Weak disks are handled first with a gentler read strategy, and all later work happens on the images, never the originals.
- 03
Rebuild the array virtually
From the images we determine the stripe size, block order, parity rotation and start offset, and identify which disk dropped out first so its stale data stays out of the calculation.
- 04
Extract and verify
The file system is read from the reconstructed array, then we open samples — databases, virtual disks, shared folders — to confirm they are intact before handover on a separate medium.
The first-hour decision
When should the system be stopped?
Every new write to a damaged array makes recovery harder. These signs call for stopping and documenting before any action.
- The array has gone Degraded and a second disk is showing read errors.
- A rebuild started then stopped, or performance collapsed.
- A volume vanished, or turned RAW or unmounted.
- The controller asked to Initialize, Create New Array, or Import Foreign Configuration.
- The disk order changed, or the disks were moved to another machine.
- A NAS, SAN or file server stopped after a power cut.
- VMware or Hyper-V machines or databases will no longer open.
- There are signs of encryption or mass deletion — in which case this is a security incident too.
For orientation, not depth
A simple guide to RAID levels
A brief explanation to help you describe your case. The actual parameters are read from the disks, not guessed.
Spreads data across two or more disks for performance with no redundancy. Losing part of one disk can affect files spanning the whole array, and analysis needs every disk, its order, and the striping parameters.
Normally creates an identical copy. Even so, deletion or logical corruption can propagate to both copies, and disks may not be perfectly in sync after a fault or a rebuild.
Uses distributed parity and normally tolerates one disk failing while healthy. The danger appears when another disk is weak, or when a rebuild starts on ageing disks.
Uses double parity and tolerates more failures by design, but data corruption, a wrong order, or several disks failing during a rebuild can make recovery complex.
Combines mirroring and striping. The outcome depends on which disks failed and on the actual mirror pairs, not on the number of failed disks alone.
What we do before opening any files
- 01
Documenting the structure
Disk order, the state of each disk, the controller model, system messages, and any rebuild or replacement are all recorded. Photographs of the bays and the management interface are more reliable than memory after a few days.
- 02
An independent image of each disk
Each disk is examined on its own and imaged sector by sector where possible. Nothing is written to the original disks, and no single disk is treated as representing a distributed array.
- 03
Establishing the array parameters
Disk order, stripe size, parity direction, offset, and the state of replacement or older disks are analysed, then a virtual array is assembled over the images.
- 04
Checking the file system and services
Once the volume appears logically, the file structure, virtual machine stores and databases are reviewed. A successful RAID rebuild does not automatically mean every file is intact.
- 05
Prioritising and verifying
Systems and files are recovered by their impact on operations, then a sample of documents, videos and databases is opened for verification before handover.
Between the extremes
Common cases and likely outcomes
- 01
A disk failed, then the rebuild failed
The replacement disk may be healthy while another disk holds failing sectors that never showed in normal operation. Keep the original and the replacement together; comparing their state may be necessary.
- 02
A NAS shows an unmounted volume
The disks may be relatively healthy while the problem lies in the RAID structure, the file system, or the device configuration. Do not create a new storage pool and do not format the disks.
- 03
The controller or server was swapped
A new controller may read the data differently or ask to initialise. Do not agree. The old and new controller models are needed, along with a copy of the configuration if one exists.
- 04
VMware or Hyper-V cannot see the machines
The array may be rebuildable while VMDK or VHDX files or the datastore structure are damaged. The outcome may be a complete machine, partial virtual disks, or extraction of important files only.
- 05
A database will not start after storage returns
A returned volume does not prove database consistency. Data files and logs are examined and copied before any repair writes over them.
Most damaging
Avoid these steps
- Do not start another rebuild and do not initialise.
- Do not change the disk order or the bay positions.
- Do not replace more than one disk at a time.
- Do not force an offline disk online and do not clear a foreign configuration.
- Do not update controller or NAS firmware during the incident.
- Do not return older disks to a working pool before images of them are kept.
- Do not restore backups over the damaged system before the cause is known.
- Do not assume a hot spare holds a complete copy; its role depends on the state of the rebuild.
What we need from the system administrator
- 01
Machine and controller
Make and model of the server, NAS or SAN, and the controller model.
- 02
Array configuration
The expected RAID level, the number of disks, and each disk's capacity.
- 03
Photographs of the bays
Clear photographs of the disks in position before they are removed.
- 04
The state of each disk
Online, Failed, Degraded, Foreign or Rebuilding.
- 05
A timed sequence of events
First alert, replacement, rebuild, power loss or update.
- 06
What was removed or added
Which disk was taken out or added, and which the team believes is the older one.
- 07
Systems and services
Operating system, file system, and the services that matter.
- 08
Encryption
Whether encryption is present, and where BitLocker or NAS keys are held.
- 09
Virtual environments
Whether VMware, Hyper-V or databases are involved, and the names of critical systems.
- 10
Backups
Their state and the last successful restore test.
- 11
Security indicators
Whether ransomware or unauthorised access is suspected.
FAQ
Order, type and state decide the path.
It depends on the RAID type, the number of affected disks and the state of the data on each disk.
Yes, a NAS can be inspected when its disks fail or its file system is damaged.
Stop the attempt, don't change the disk order, and request a specialist inspection.
Every new write and heavy read adds strain. Coordinate preserving the state and a safe shutdown according to how critical the service is, and do not start a rebuild automatically before the disks are assessed.
No. It is a standby disk that joins a rebuild, not an independent backup. The rebuild may fail, or corrupted data may be written onto it.
The order may be deducible from the data, but it adds complexity. Send every disk, the photographs and the logs, and do not try random orders.
No. Data is distributed across the set, and we usually need every disk — plus any that was removed or replaced during the incident.
Handover to separate storage or a clean environment is better. Writing to the original array before verification can cost you the chance to go back.
Photographs, logs and information can be gathered remotely, but examining the disks and imaging them may require receiving the media or structured access to the environment.
It depends on the number of disks, their capacity and condition, read speed, and the structure of the services. We give an estimate after examining the set, not from the RAID level alone.
Not necessarily. Rebuilding the storage is one step; database consistency is another that needs the data files and logs, or an application copy, to be examined.
RAID 0, 1, 5, 6 and 10, plus NAS and SAN systems — rebuilt logically without writing to the original disks.
Send every disk in the array, labelled in its original order; RAID recovery needs the disks read together to understand how data is distributed.
Stop the server immediately — continuing to run it or letting it auto-rebuild can multiply the damage. We work on images of the disks, never the originals.
Next step
Send case detailsStop the system before the fault doubles.
Send the RAID type, the number of disks and the error messages. We review the case before any step that could change the data structure.