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.
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 original array.
RAID Failed? Do Not Rebuild It Yet.
If a RAID, NAS or server has become degraded or inaccessible, avoid initializing the array, forcing disks online, replacing multiple members or repeatedly attempting a rebuild.
A rebuild writes new data across the array. If the wrong disk is introduced, disk order is incorrect or another member contains unreadable sectors, the rebuild can permanently overwrite the previous RAID state.
Before removing any disks, clearly label each drive according to its original bay or slot number and, whenever possible, photograph the complete drive arrangement.
Disk order is extremely important. Do not shuffle the drives after removal and do not assume that the operating system or controller will automatically identify the correct sequence later.
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.
Our engineers examine the member disks and available metadata to determine the parameters required to recreate the original storage layout. 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.
If one or more members are unstable, physically damaged or producing read errors, those drives are addressed individually before logical reconstruction begins.
Where possible, unstable media is imaged or cloned first. The RAID can then be reconstructed from controlled disk images rather than repeatedly stressing the original drives.
Supported RAID Configurations
Aesonlabs can evaluate conventional, nested and vendor-specific RAID configurations including:
- RAID 0
- RAID 1
- RAID 5
- RAID 6
- RAID 10
- RAID 50
- RAID 60
- Software RAID and proprietary storage layouts
- ZFS and RAID-Z storage pools
- Microsoft Storage Spaces and similar software-defined storage
The number of disks can range from small two-drive mirrors to large enterprise storage systems. As the number of members and logical layers increases, so does the complexity of determining the original configuration and identifying which components remain usable.
Multiple-Disk RAID Failure
RAID redundancy is not a backup.
A RAID 5 array can normally tolerate a single missing member, while RAID 6 can normally tolerate two. Problems frequently arise when an array continues operating in a degraded state and another disk develops bad sectors, drops offline or fails completely before the first issue is resolved.
A recovery case may therefore 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. A controller may treat a weak or outdated member as valid and write parity or reconstructed data over sectors that were previously still recoverable.
NAS Data Recovery
NAS systems commonly combine several technologies within a single appliance. Recovering the RAID layer may therefore represent only the first stage of the recovery.
Systems from manufacturers such as Synology, QNAP, Western Digital, Buffalo, Netgear and Asustor can use Linux RAID, proprietary metadata, LVM, storage pools, EXT4 or Btrfs filesystems, snapshots and encryption.
A failed NAS may appear to contain ordinary hard drives, but the logical structure across those drives can be substantially more complex than a conventional desktop disk.
For this reason, simply transferring the disks into another NAS chassis or allowing the replacement unit to initialize the array is not recommended unless the exact configuration and state of the original storage is understood.
SAN Data Recovery
SAN environments are among the more complex storage recovery cases because the physical RAID may represent only the lowest layer of the storage architecture.
Above the member disks may be RAID groups, storage pools, logical unit numbers, volumes, snapshots, virtual datastores and individual virtual machines.
A failure at one layer can make all of the storage above it appear inaccessible even when much of the underlying data remains intact.
Successful SAN recovery therefore depends on determining where the original failure occurred before attempting repair or reconstruction.
Large SAN systems can also contain multiple RAID groups or disk shelves. In these cases, contact Aesonlabs before removing the media so that we can determine which disks belong to the affected storage group and what information should be preserved before the system is dismantled.
VMware & Virtual Server Recovery
Virtual server recovery can introduce another logical layer above the physical storage system.
Aesonlabs can evaluate cases involving damaged VMware datastores, VMFS filesystems, inaccessible or deleted VMDK files, corrupted virtual machines, snapshot-related failures and virtual disks located on failed RAID, NAS or SAN storage.
Depending on the failure, the underlying RAID may first need to be reconstructed before the VMware datastore can be addressed.
Once the storage layer is stable, the VMFS filesystem, virtual disk files and individual guest filesystems can be evaluated separately.
The same principle applies to other virtualized server environments: the physical media, RAID structure, storage pool, virtual disk and guest operating system are treated as separate recovery layers rather than as one large filesystem.
Controller Failure Does Not Necessarily Mean Data Loss
A failed RAID controller does not automatically mean that the original controller must be repaired or supplied for the data to be recovered.
In many cases, the relevant RAID parameters can be reconstructed directly from the member disks and available metadata.
This is particularly useful with large rackmount servers and storage appliances where shipping the entire chassis and controller hardware would be impractical.
Unless specifically requested, the RAID controller is usually not required. The member disks themselves are considerably more important.
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, clearly mark each one with its original bay or slot position. For example:
Bay 1, Bay 2, Bay 3, Bay 4, and so on.
Taking clear photographs of the installed disk order before removal is strongly recommended.
If the system contains multiple RAID groups, storage pools, disk shelves or virtual storage layers, contact us before removing anything. This helps prevent drives from unrelated arrays being mixed together.
Heavy server chassis, controllers and rackmount hardware generally do not need to be shipped unless the recovery specifically requires them.
Remote RAID & Server Recovery
Certain logical storage and server failures may be suitable for remote diagnosis or recovery, particularly when the hardware is operational and the server or SAN system cannot reasonably be transported.
Remote recovery is generally most appropriate when the physical disks are healthy and the problem exists at the logical, filesystem, storage-pool or virtualization layer.
Cases involving unstable, failed or physically damaged member disks normally require the affected media to be delivered to our laboratory so that the drives can be examined and imaged individually.
For complex enterprise storage environments, we determine whether remote work or physical media recovery is more appropriate after reviewing the storage architecture and failure circumstances.
Encrypted RAID, NAS and Virtual Storage
Encryption can introduce an additional dependency after the underlying storage has been reconstructed.
BitLocker, encrypted NAS volumes, encrypted virtual machines and vendor-specific encryption may require the original password, recovery key, encryption certificate or other system component.
Reconstructing the RAID does not bypass encryption. Clients should retain 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 for RAID Recovery?
RAID, NAS, SAN and server recovery requires more than standard file-recovery software.
A successful recovery can require physical disk diagnostics, individual member imaging, reconstruction of RAID geometry, identification of stale or missing members, filesystem recovery and, in virtualized environments, additional 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.
This approach allows us to preserve the original storage state while determining exactly which layer is responsible for the data becoming inaccessible.
Start a RAID Recovery Case
If your RAID array, NAS, SAN, server or VMware datastore is no longer accessible, avoid unnecessary rebuild or initialization attempts.
Before removing any disks, label their original bay positions and photograph the installed drive order.
Submit a recovery case with the number of disks, RAID or storage system type, symptoms you observed and any changes that were made after the failure.
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 condition of the remaining disks should be established before a rebuild is attempted.
Potentially. Recoverability depends on the RAID level, number of failed members, condition of the remaining disks and whether the failed or unstable drives can be partially imaged. Every member should be evaluated individually before reconstruction.
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. Cases involving failed or unstable physical disks generally require the media to be delivered to our laboratory.
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.
Get Your RAID or Server Evaluated
If a RAID array, NAS, SAN or virtual server environment has failed, stop rebuild and initialization attempts until the condition of the storage has been established.
Submit the case with the number of drives, RAID or storage platform, failure symptoms and any actions that were taken after the problem began.