Open A Recovery Case Open Case

RAID NAS SAN and Server Data Recovery

RAID, NAS, SAN & Server Data Recovery

Aesonlabs provides professional data recovery from failed RAID arrays, NAS systems, SAN storage and virtual server environments. These cases can involve several dependent storage layers, beginning with the individual physical disks and RAID configuration and extending into storage pools, filesystems, virtual disks and guest operating systems.

RAID recovery is not simply a matter of replacing a failed disk and rebuilding the array. When multiple members have failed, become unstable or fallen out of synchronization, an incorrect rebuild can overwrite information required for recovery.

RAID failed? Do not rebuild it yet. If the array, NAS or server has become degraded or inaccessible, avoid initializing the storage, forcing disks online, replacing several members or repeatedly attempting a rebuild. A rebuild writes new data across the array and can permanently overwrite the previous RAID state.
RAID State Visualizer

Healthy, Degraded and Failed Arrays Do Not Behave the Same Way

Different RAID layouts tolerate failure differently. The danger usually begins when an array is already degraded and a rebuild, re-sync or replacement is attempted before the condition of the remaining members has been verified.

Use the visualizer below to see how common RAID types change from a healthy state to a degraded array, then to a failed or unsafe recovery scenario.

Healthy Degraded Failed / Offline Rebuild Risk
RAID 0 Striped array — no fault tolerance
Healthy
All member disks are online. The array is accessible while every disk remains healthy.
Key point: on a degraded array, the next action matters. Rebuilds, forced imports and disk reordering can overwrite the last recoverable state.
Preserve the Original State

Disk Order and Member Condition Come First

Before removing any disks, clearly label each drive according to its original bay or slot number and, whenever possible, photograph the complete drive arrangement. Do not shuffle the disks after removal.

Our objective is to preserve the original media, determine the condition and role of each member disk and reconstruct the storage configuration without modifying the source array.

Recovery Workflow

How Professional RAID Recovery Works

RAID recovery is approached layer by layer: physical members first, then RAID geometry, then filesystems, storage pools and any virtual environments above them.

01

Preserve & Identify Members

Disk order, bay position, controller history and the condition of every original member are documented before reconstruction begins.

02

Diagnose & Image Unstable Disks

Failed or weak members are handled individually and, where possible, imaged to controlled working copies before logical RAID work begins.

03

Reconstruct RAID Geometry

Disk order, RAID level, stripe size, parity rotation, data offset and member roles are determined from metadata and disk contents.

04

Rebuild the Logical Storage Layer

The reconstructed array is examined for filesystems, LVM, storage pools, ZFS, VMFS and other logical structures without writing to the originals.

05

Recover & Verify Data

Files, virtual disks and guest filesystems are recovered from the reconstructed storage and evaluated for completeness and consistency.

RAID Configuration Reconstruction

When the original RAID configuration is damaged, unavailable or stored inside a failed controller, the array can often be reconstructed independently of the original hardware. Depending on the RAID type, this can include disk order, RAID level, stripe or block size, parity rotation, data offset, number of members and the condition of each disk.

Member Health

Multiple-Disk RAID Failure

A recovery case may involve one completely failed disk, another partially readable member and several healthy drives. This mixed condition is one of the main reasons a forced rebuild can be dangerous.

Controller Independence

Controller Failure

A failed RAID controller does not necessarily mean the original controller must be repaired. In many cases, RAID parameters can be reconstructed directly from the member disks and available metadata.

Controlled Imaging

Work From Disk Images Where Possible

If one or more members are unstable, those drives are addressed first. Controlled images allow logical reconstruction to proceed without repeatedly stressing weak original media.

Layered Storage

RAID Is Only One Layer

Above the physical array may be storage pools, filesystems, snapshots, virtual disks, datastores and guest operating systems. Each layer is evaluated separately.

Supported Configurations

Conventional, Nested and Software-Defined RAID

Aesonlabs can evaluate small two-disk mirrors, multi-disk parity arrays and large enterprise storage systems. As the number of members and logical layers increases, so does the complexity of identifying the original configuration and determining which components remain usable.

RAID 0 RAID 1 RAID 5 RAID 6 RAID 10 RAID 50 RAID 60 Software RAID Vendor-Specific Layouts ZFS / RAID-Z Microsoft Storage Spaces

NAS, SAN and Virtual Server Recovery

Network Storage

NAS Data Recovery

NAS systems from vendors such as Synology, QNAP, Western Digital, Buffalo, Netgear and Asustor can combine Linux RAID, proprietary metadata, LVM, storage pools, EXT4 or Btrfs, snapshots and encryption.

Recovering the RAID layer may therefore represent only the first stage of the recovery.

Enterprise Storage

SAN Data Recovery

SAN environments may contain RAID groups, storage pools, LUNs, volumes, snapshots, datastores and virtual machines above the physical disk layer.

Large systems can also contain multiple RAID groups or disk shelves, so storage-group membership must be preserved before dismantling the system.

Virtualization

VMware & Virtual Server Recovery

Recovery can involve damaged VMFS datastores, inaccessible or deleted VMDK files, corrupted virtual machines, snapshot-related failures and virtual disks located on failed RAID, NAS or SAN storage.

Remote Work

Remote RAID & Server Recovery

Some logical storage and server failures may be suitable for remote work when the physical disks are healthy and the system cannot reasonably be transported.

Failed or unstable member disks normally require physical media evaluation and imaging in the laboratory.

Preparing the Media

What Should You Send Us?

For most RAID recovery cases, the complete server or NAS chassis is not required. We normally require the original member disks that formed the affected array.

Before removing the drives, mark each one with its original bay or slot position—Bay 1, Bay 2, Bay 3, and so on—and photograph the installed order. If the system contains multiple RAID groups, pools or disk shelves, contact us before removing anything.

Heavy server chassis, controllers and rackmount hardware generally do not need to be shipped unless the recovery specifically requires them.

Server RAID drives labelled by bay position
Preserve the original bay order before removing RAID or server drives.
Encryption Layer

Encrypted RAID, NAS and Virtual Storage

Reconstructing the RAID does not bypass encryption. BitLocker, encrypted NAS volumes, encrypted virtual machines and vendor-specific encryption may still require the original password, recovery key, certificate or other system component.

Clients should preserve all available credentials, recovery keys, certificates, configuration files and related system information.

What Not to Do After a RAID Failure

Do not repeatedly rebuild the array.
Do not initialize or format the storage when prompted.
Do not create a new RAID or storage pool using the original disks.
Do not force failed members online without understanding their condition.
Do not replace several disks at once and allow an automatic rebuild to begin.
Do not change the physical disk order after removing the drives.
Do not continue operating a severely degraded array when the data is important.

The safest recovery procedure generally involves preserving the original media, identifying the condition of each member and working from controlled disk images whenever possible.

Why Aesonlabs

RAID Recovery as a Layered Storage Problem

RAID, NAS, SAN and server recovery requires more than standard file-recovery software. A successful case can require physical disk diagnostics, individual member imaging, reconstruction of RAID geometry, identification of stale or missing members, filesystem recovery and, in virtualized environments, reconstruction of datastores and virtual disks.

Aesonlabs approaches these systems as a series of dependent storage layers. The physical disks are stabilized first, followed by reconstruction of the RAID or storage pool and then the logical filesystems or virtual environments above it.

Frequently Asked Questions

RAID, NAS & Server Recovery FAQ

In many cases, yes. RAID parameters such as disk order, RAID level, stripe size, parity configuration and data offset can often be reconstructed from the member disks without requiring the original controller.

Not if important data is already inaccessible or more than one member may be unstable. A rebuild writes to the array and can overwrite data needed for recovery. The remaining disks should be evaluated first.

Potentially. Recoverability depends on the RAID level, number of failed members, condition of the remaining disks and whether failed or unstable drives can be partially imaged.

Photograph the installed drive arrangement and clearly label every disk with its original bay or slot number. Do not change the disk order after removal.

Usually not. In most RAID recovery cases, the correctly labelled member disks are the most important components. Large server chassis and controllers generally do not need to be delivered unless the case specifically requires them.

Yes, depending on the failure. NAS recovery may involve the underlying RAID as well as Linux RAID metadata, LVM, storage pools, EXT4 or Btrfs filesystems, snapshots and other logical structures used by the appliance.

Potentially. Recovery can involve damaged VMFS datastores, missing or inaccessible VMDK files, corrupted virtual machines and failures originating in the RAID, NAS or SAN storage beneath the virtual environment.

Some logical storage and server failures may be suitable for remote work when the hardware is healthy and the system cannot reasonably be transported. Failed or unstable physical disks generally require laboratory evaluation.

The underlying storage may be recoverable, but encryption remains a separate layer. The appropriate password, recovery key, certificate or other encryption information may still be required to access the reconstructed data.

Start a Recovery Case

Have a Failed RAID, NAS, SAN or Server?

Submit the number of disks, RAID or storage platform, failure symptoms and any actions that were taken after the problem began. Before removing media, preserve the bay order and photograph the installed configuration.

Open a Recovery Case