Data recovery from RAID 0, 1, 5, 6, 10 arrays and other configurations. Hardware and software RAID, consumer and enterprise units. EXALAB® has specialized in RAID data recovery since 2006—its own laboratory, express service.
RAID data recovery is the recovery of data from a disk array after the failure of one or more drives, a failed rebuild, controller failure, file system corruption, data deletion or physical damage to the server. We work with all configurations—RAID 0, 1, 5, 6, 10, 50, 60 and proprietary ones (SHR, X-RAID, BeyondRAID, TRAID)—with both hardware and software arrays and with file systems including NTFS, ReFS, ext4, XFS, Btrfs, ZFS and VMFS. We always perform recovery on binary copies of the drives; the originals remain untouched. Diagnostics are free, and RAID data recovery pricing starts at CZK 2,500.
RAID data recovery is one of the more complex disciplines in the field of data recovery. Every RAID configuration has its own specifics—a different way of distributing data, a different level of redundancy and different behavior when one or more drives fail. At the EXALAB laboratory we have been recovering data from RAID since 2006 and have experience with all common and less common configurations, from simple two-drive arrays to large enterprise storage with dozens of drives. The laboratory is operated by Microshop s.r.o., which holds ISO 9001:2016 and ISO 14001:2016 certification.
Our long-term success rate for RAID data recovery is around 95%. Diagnostics are provided free of charge and without obligation. We keep most spare parts in stock, and express service is available even outside business hours.
Consultation, diagnostics and pickup are always free of charge.
Symptoms:
This is the most common cause of RAID data loss. Drives in servers and NAS units usually run continuously and are exposed to higher thermal and mechanical stress than drives in ordinary computers. Failure can be caused by wear, a manufacturing defect, damage to the surface of the platters or read heads (HDD), controller or firmware failure (SSD), or by an electrical short or power surge. It often turns out that a drive flagged by the controller as faulty is physically fine, and the real cause is a logical or software error—typically a dropped but healthy mirror member in a RAID 1. Such recovery falls into the lower price category. The price depends on the number of drives in the array, the RAID configuration, the type and extent of damage, and whether anyone handled the array after the failure. We will tell you the exact price after free diagnostics. You always pay only for successful data recovery.
Indicative price: from CZK 2,500 (logical or software cause, typically RAID 1), from CZK 5,000 (hardware drive failure—faulty read heads, platters, electronics)
More information—drive failures in a RAID array
Free consultation, diagnostics, pickup
Symptoms:
A RAID controller can fail like any other electronic component, through wear, a depleted cache backup battery (BBU/FBWC), a firmware error or electrical damage. In a hardware RAID controller, the array metadata is stored both on the controller and on the drives. Simply replacing the controller with an identical model may not always help—especially if the firmware version differs or if the metadata on the drives has been damaged. Contact us; the consultation is free.
Indicative price: from CZK 5,000
More information—RAID controller failure and its consequences
Free consultation, diagnostics, pickup
Do not start a rebuild unless you are completely sure of the cause of failure! You can turn a solvable case into a complicated one—or worse…
Symptoms:
A failed rebuild is one of the most common causes of RAID data loss we encounter in practice. A RAID 5 rebuild typically occurs after one drive fails. During recalculation, the remaining drives are placed under extreme load—their entire capacity is read. If another drive fails at that moment, redundancy is lost. A power outage, a device firmware error or human factors can also contribute to a rebuild failure—for example, swapping slots or inserting drives in the wrong order. The price depends on the number and condition of the drives, the array configuration and the extent of damage.
Indicative price: from CZK 5,000
More information—why rebuilds fail and how to prevent it
Free consultation, diagnostics, pickup
Symptoms:
A RAID array in servers and NAS units typically uses file systems such as NTFS, ReFS, ext4, XFS, Btrfs or ZFS. The data structure is more sophisticated than on an ordinary drive in a computer. The problem can be caused by a software error, an unexpected shutdown, a power outage, a drive failure at a level that is not externally visible, ransomware or an unintended configuration change. Unprofessional manipulation of the array configuration or attempts to repair the file system directly on the array (fsck, chkdsk) can make the situation irreversibly worse. If it is a purely logical fault, recovery is cheaper; if diagnostics reveal a hidden drive failure, the case falls into the hardware price category.
Indicative price: from CZK 2,500
More information—inaccessible volume on RAID
Free consultation, diagnostics, pickup
Symptoms:
In the case of deleted data, it is crucial not to work with the device any further. Every additional write reduces the chance of successful recovery. If an entire volume has been formatted, the chance of recovery depends on the type of file system and on whether new data was written after formatting. For ransomware attacks on server and network storage (Deadbolt, Qlocker, eCh0raix), the recovery options depend on the specific malware variant and the extent of encryption. A user error, a software bug or an accidentally run script may also be to blame.
Indicative price: from CZK 2,500
More information—recovering deleted data from RAID
Free consultation, diagnostics, pickup
Do not power on the damaged server or drives! Further attempts to start them can make the situation irreversibly worse.
Symptoms:
Do not handle the device or the drives in any way and do not try to power them on. Do not connect damaged drives to other devices. Contact us and we will discuss the next steps together. We provide free pickup throughout the Czech Republic.
Indicative price: from CZK 5,000
Data recovery price list
Free consultation, diagnostics, pickup
RAID data recovery requires detailed knowledge of the specific array configuration—how data is distributed, where parity is stored, how the array responds to a drive failure and how a rebuild proceeds. We handle all common and less common configurations:
RAID 0 (stripe) distributes data across two or more drives without redundancy. The failure of any drive in the array means loss of access to all data. RAID 0 data recovery is nevertheless possible in most cases, but it requires block-level stripe reconstruction.
RAID 1 (mirror) mirrors data onto two or more drives. If one drive fails, the data is available from the other. Problems arise if both drives fail or if there is a file system error at the logical level.
RAID 5 distributes data and parity across three or more drives. It tolerates the failure of one drive. It is one of the most widely used configurations in servers and NAS. The failure of two or more drives or a failed rebuild are among the most common cases we handle.
RAID 6 is similar to RAID 5 but with double parity—it tolerates the failure of two drives at once. It is used where higher resilience is required. Even with double parity, we encounter failures that require professional intervention.
RAID 10 (1+0) combines mirroring and striping. It offers high performance and redundancy. Problems arise if both drives in one mirror pair fail or if the controller fails.
RAID 50 (5+0) and RAID 60 (6+0) are combinations used in larger enterprise environments with a higher number of drives. We also handle RAID 1E, RAID 3, RAID 4 and other less common variants. We have hands-on experience with every configuration.
Besides standard RAID levels, we also handle proprietary implementations: Synology SHR and SHR-2, Netgear X-RAID and X-RAID2, Drobo BeyondRAID, TerraMaster TRAID, RAID-Z1, Z2, Z3 (ZFS) and JBOD. Each of these implementations manages data and redundancy differently and requires a specific approach to data recovery.
The way RAID is implemented affects the data recovery procedure. We distinguish three main types:
Hardware RAID is managed by a dedicated controller with its own processor and memory (often with a battery to protect the cache). The array configuration and metadata are stored on the controller and on the drives. When the controller fails, the metadata must be read and the array reconstructed at the raw-data level—replacing it with an identical controller may not always work and in some cases can make things worse.
Software RAID is managed by the operating system. On Linux this is most often mdadm (md RAID), LVM or ZFS. On Windows it is dynamic disks (Dynamic Disks) and Storage Spaces. The metadata is stored directly on the drives, which usually makes reconstruction easier—the controller is not an obstacle. The file system and the integrity of the array metadata play a key role.
Pseudo-hardware RAID (so-called FakeRAID) is an implementation in the motherboard BIOS using the chipset (e.g. Intel RST/VROC, AMD RAIDXpert). The metadata is partially proprietary and differs between platforms. We have experience reconstructing these too.
Drives in servers and NAS devices usually operate continuously, 24/7. They are exposed to higher thermal and mechanical stress than drives in ordinary computers. Even quality drives designed for RAID operation (NAS and Enterprise series) have a limited lifespan, and after several years of operation the probability of failure increases.
In mechanical drives (HDD), the most common causes are damage to the platter surface, read-head failure, motor wear or an electronics fault. In SSDs in a RAID environment we encounter drive controller failures, wear of the NAND memory chips or firmware errors.
A common scenario is a situation where the RAID controller drops a drive from the array even though the drive is largely functional. The cause is usually exceeding the allowed response time limit. Enterprise and NAS drives have a TLER (Time-Limited Error Recovery) function or similar—if the drive hits a bad sector, it has a limited time (typically 7 seconds) to attempt to read it. If it does not succeed, the controller flags the drive as faulty and excludes it from the array. Ordinary desktop drives do not have this function and may try to read a bad sector for tens of seconds, paralyzing the entire array. This is why it is important to use purpose-built drives (NAS or Enterprise series) in a RAID environment.
The use of SSDs in RAID arrays brings specific risks. NAND flash memory chips have a limited number of write cycles, and drives from the same production batch installed at the same time may reach that limit at roughly the same time—risking the synchronous failure of several drives at once. Some SSDs switch to read-only mode after exhausting their write cycles or when the controller fails; others stop responding altogether. Another risk is the TRIM command (UNMAP on SAS drives)—once the operating system marks data as deleted, the SSD controller irreversibly erases it in the background as part of its internal garbage collection process. Recovering deleted data from an SSD in a RAID array is therefore significantly harder than from an array with mechanical drives and requires immediate action.
A particularly dangerous situation is when two or more drives in the array fail within a short time. The risk is higher with drives purchased at the same time—they tend to have a similar lifespan and may fail at roughly the same period. We therefore recommend combining drives from different production batches in RAID arrays and regularly monitoring their condition through S.M.A.R.T. diagnostics.
Free consultation, diagnostics, pickup
Pricing—drive failures in RAID
A hardware RAID controller (e.g. Dell PERC, HP SmartArray, LSI MegaRAID, Adaptec) stores the array configuration metadata both in its own memory and on the drives. When the controller fails, a seemingly simple solution presents itself—replacing it with an identical model. In practice, however, this carries risks.
If the firmware version of the new controller differs, the metadata on the drives may be interpreted incorrectly. In the worse case, the new controller may overwrite the metadata with new data, causing the original configuration to be lost. Another risk is a situation where the controller failure is not the real cause—that cause may also lie on the drives themselves.
When the controller fails, we bypass it in our laboratory and work directly with the drives. Based on the metadata and an analysis of the data structures, we reconstruct the array without relying on a specific controller. This approach is safer and eliminates the risk of overwriting data with a new controller.
Free consultation, diagnostics, pickup
Pricing—RAID controller failure
A rebuild (recalculation, reconstruction) of a RAID array is a process in which the data on a newly inserted drive is recalculated from the other drives in the array. For RAID 5 this is parity reconstruction; for RAID 1 it is mirror synchronization. This process is extremely demanding on the remaining drives—their entire capacity is read, which can take hours to tens of hours for large arrays.
It is precisely during a rebuild that the array is most vulnerable. The remaining drives operate at full load, and a drive that had so far shown only minor problems (incipient bad sectors) can fail for good under this load.
Statistically, ordinary desktop drives have an unrecoverable read error (URE—Unrecoverable Read Error) probability of approximately 1 in 1014 bits read, which corresponds to roughly 12.5 TB of data. Drives designed for RAID and enterprise operation (nearline SATA/SAS) are usually specified an order of magnitude better—typically 1 in 1015, or roughly 125 TB—so the risk is lower with them. With large arrays using high-capacity drives of 4 TB and more, however, it remains real. A single unreadable sector on a drive other than the originally faulty one is enough to collapse the rebuild. For RAID 5 this means complete loss of access to the data. For RAID 6, after a single URE the situation becomes equivalent to RAID 5—the array loses its second level of protection and another error is fatal.
A rebuild can also fail for other reasons—a power outage, a NAS or server firmware error, human factors (inserting a drive into the wrong slot, swapping drives). In some cases an administrator performs a rebuild on a device that operated without problems under normal conditions, but under the increased load hidden defects in other drives manifest themselves.
How to minimize the risk: Regular S.M.A.R.T. monitoring, the use of drives designed for RAID operation (NAS/Enterprise series with CMR recording), a backup power supply (UPS), and above all an independent backup of the data outside the RAID.
Free consultation, diagnostics, pickup
Pricing—failed RAID rebuild
A data partition (logical volume) in a RAID array is a technologically more sophisticated solution than what a user encounters on an ordinary drive in a computer. The data is distributed across several physical drives, and the volume may use a file system that ordinary desktop tools cannot even read (XFS, Btrfs, ZFS, VMFS).
If a volume becomes inaccessible and the cause is not immediately obvious, it may be file system corruption (for example after an unexpected power outage), a hidden failure of one of the drives, or a software error in the device itself. In some cases ransomware that has encrypted the data may be to blame.
Running file system repair tools (fsck, chkdsk, btrfs check) directly on the original drives is risky. These tools may make changes to the metadata that worsen the situation. In our laboratory we always start by creating binary copies of all drives and only then proceed to analysis and reconstruction.
Free consultation, diagnostics, pickup
Pricing—inaccessible partition on RAID
Recovering deleted data from RAID is in many respects similar to recovering deleted data from an ordinary drive, but with greater technological complexity. The data is stored across the drives in a distributed manner, and the logical RAID volume must first be reconstructed before individual files can be recovered.
With copy-on-write file systems (Btrfs, ZFS), the chance of recovery may be higher because data is not overwritten in place. By contrast, with classic file systems (NTFS, ext4, XFS) success depends on whether new data was written to the location of the deleted data.
For ransomware attacks on network storage (Deadbolt, Qlocker, eCh0raix and others), the recovery options depend on the specific malware variant, on whether the encryption was completed, and on the storage file system. In some cases data can be recovered from previous snapshots or from older versions of files, if the device supported them.
Key rule: after data is deleted, do not work with the device further and do not shut it down in the standard way (to avoid triggering internal cleanup processes); instead, disconnect the power and contact us.
Free consultation, diagnostics, pickup
Pricing—deleted data from RAID
In RAID data recovery we encounter a wide range of hardware. We are proficient in reconstructing arrays from controllers by all major manufacturers:
RAID controllers: Adaptec (Microchip), LSI / Broadcom (MegaRAID), Dell PERC, HP / HPE SmartArray, Intel RAID (RST, VROC), Areca, 3Ware, Promise, ATTO, HighPoint, ICP Vortex, QLogic and others.
Servers: Dell PowerEdge, HP / HPE ProLiant and Synergy, Lenovo ThinkSystem, IBM Power and xSeries, Supermicro, Fujitsu PRIMERGY, Cisco UCS and others. We also handle DAS and SAN storage from NetApp, Dell EMC, HP StoreEasy and other manufacturers.
If you do not find your controller or server in the list, do not hesitate to contact us—in all likelihood we have experience with your specific platform too.
We recover data from all file systems used in RAID environments:
Windows: NTFS, ReFS, FAT32, exFAT
Linux: ext2, ext3, ext4, XFS, Btrfs, ZFS (OpenZFS), JFS, ReiserFS
macOS: HFS+, APFS
Virtualization: VMFS (VMware vSphere)
Other: UFS, GPFS (IBM Spectrum Scale)
A RAID array is usually deployed in servers and storage that hold data critical to a company’s operations. These are exactly what we encounter most often in our laboratory:
Databases—Microsoft SQL Server (.mdf/.ldf files), MySQL and MariaDB (InnoDB, MyISAM), PostgreSQL, Oracle. We recover the database files themselves and, where necessary, check them for consistency.
Accounting and ERP software—in Czech companies, servers and RAID drives store the databases of programs such as POHODA (.mdb files in the basic edition, Microsoft SQL Server in the network edition), Money S3/S4/S5 (SQL Server databases .mdf/.ldf), Helios (SQL Server or Oracle), Abra and others. The loss of this data can directly threaten a company’s operations.
Virtual machines—VMware vSphere/ESXi (VMFS datastores, .vmdk virtual disks), Microsoft Hyper-V (.vhd/.vhdx), Proxmox. We reconstruct both the RAID array on which the datastore resides and the individual virtual machines.
File and mail servers—shared folders (NTFS, NFS, SMB), Microsoft Exchange (.edb databases), document archives and file repositories.
Backups—a RAID array often serves as the target for backup software (Veeam, Acronis, Bacula). If it is the backup server itself that fails, the backups can disappear too—which is why an independent copy outside the RAID is essential.
Block storage—iSCSI and Fibre Channel LUNs, volumes on DAS and SAN. We reconstruct both the array and the logical structure on top of it.
1. Consultation and intake
Contact us by phone, email or through the form. We will assess the situation together. We provide free pickup of the drives or the entire device throughout the Czech Republic.
2. Diagnostics
We perform thorough diagnostics on all drives from the array. We test their condition, read the RAID configuration metadata and evaluate the recovery options. Diagnostics are free and without obligation—you receive a report describing the condition, the price and an estimate of the turnaround time.
3. Data recovery
As the first step we create binary copies of all drives from the array (sector-by-sector images) using hardware write blockers that physically prevent any writing to the original drives. If a drive is mechanically damaged (faulty read heads, a damaged platter surface), we first bring it to a readable state in the cleanroom of our laboratory and only then create a binary copy of it. We reconstruct the RAID configuration and recover the data exclusively from these copies; the original drives remain safely stored throughout and are never exposed to further stress.
4. Handover of recovered data
After recovery is complete, you receive an overview of the recovered files. We hand over the data on a new medium (an external drive, encrypted transfer). You only pay for successfully recovered data.
Free consultation, diagnostics, pickup
After we receive the drives, we perform free diagnostics—we test the condition of the individual drives and read the RAID configuration metadata. We then create binary copies of all drives (sector by sector). Based on the copies we reconstruct the RAID array and recover the data. The original drives are not stressed further during recovery. The detailed procedure is described in the How RAID data recovery works section.
The price depends on the type of failure, the array configuration, and the number and condition of the drives. You can find indicative prices in the overview by failure type. We will tell you the exact price after free diagnostics. We offer several processing-speed options, from standard to express—the faster option costs more, the slower one less. You only pay for successfully recovered data.
The turnaround time depends on the number and condition of the drives, the array configuration and the chosen processing option. For less serious cases it is on the order of days; for more complex cases with mechanically damaged drives it can take several weeks. We also offer express service outside business hours. You receive a specific estimate as part of the free diagnostics.
Ideally yes—even drives that appear to be completely faulty. Each drive in the array carries part of the data and metadata about the configuration. With RAID 5 or 6 it is theoretically possible to reconstruct data even without one or two drives respectively, but having all the drives significantly increases the chance of complete recovery and reduces the processing time.
Only if you are completely sure that only one drive in the array failed and the other drives are fine. In practice it often happens that several drives show incipient problems, and the increased load during a rebuild can cause another drive to fail. If you have any doubts, we recommend contacting experts before you start the rebuild. A failed rebuild is one of the most common cases we handle in our laboratory.
There are tools for software reconstruction of RAID (R-Studio, UFS Explorer, ReclaiMe and others). These tools can help with purely logical failures where all the drives are physically fine. However, if the cause of failure is hardware-related, attempts at software recovery directly on the original drives can damage the data irreversibly. The safer path is to entrust cases with valuable data to a professional laboratory that first creates safe copies of the drives.
In some cases, replacing the controller with an identical one with the same firmware version may work. There is, however, a risk—a different firmware version or damaged metadata on the drives can lead to a state where the new controller does not initialize the array correctly or, in the worse case, overwrites the metadata with new data. We recommend consulting experts about this operation. More in the RAID controller failure section.
Yes, in most cases RAID 0 data recovery is possible, even though RAID 0 offers no redundancy. If one drive is non-functional, data recovery depends on whether the data from that drive can be read (at least partially). From the functional drives of the array, the stripe can be reconstructed and files for which all the necessary data is available can be recovered.
No. RAID protects against the failure of one or more drives (depending on the configuration), but it does not protect data against deletion, ransomware, controller failure, software error or natural disasters. RAID should always be complemented by an independent backup at a different physical location.
Regularly check the condition of the drives in the array (S.M.A.R.T. monitoring). Replace faulty drives immediately. Use drives designed for continuous RAID operation (NAS/Enterprise series, CMR recording). Consider a backup power supply (UPS) to protect against power outages during operation and rebuilds. And above all—back up your data independently of the RAID. The proven 3-2-1-1 backup strategy recommends keeping three copies of the data on two different media types, one copy off-site and one copy on offline or immutable (WORM) storage that not even an administrator can access. This last layer in particular is the key protection against ransomware attacks, which can encrypt all online-accessible storage, including network backups, within hours.
Pack the drives individually in antistatic bags and cushion them with soft material to prevent impacts. Mark the order of the drives in the slots (slot 0, 1, 2…). If possible, send the entire device (server, NAS) with the drives in their original positions. We provide free pickup throughout the Czech Republic by courier.
Hardware RAID is managed by a dedicated controller (a PCIe card) with its own processor and memory. Software RAID is managed by the operating system (Linux mdadm, ZFS, Windows Dynamic Disks). Hardware RAID usually offers higher performance and independence from the OS, but recovery can be more complicated when the controller fails. Software RAID is more flexible and the metadata is directly on the drives, which makes reconstruction easier. More in the Hardware RAID vs. software RAID section.
Discretion and treating data as confidential are a given for us. If the nature of the job requires it, do not hesitate to request a contractual non-disclosure agreement (NDA). RAID and server storage often contains corporate data, databases and accounting systems—we understand this and treat it with appropriate care.
Is your data insured? Before confirming the order, we will issue you an “incident certificate” that you can use to have your insurer approve the data recovery costs, and only then do you confirm the order.
Out of the hundreds of RAID jobs that have passed through our laboratory, we have selected a few cases that illustrate typical failure scenarios and recovery procedures. Every job has its specifics—from a single drive failure in a RAID 5, through failed rebuilds, to reconstructing an array after a controller failure or a ransomware attack.
Send us the drives from your array or the entire server for free diagnostics—within the Czech Republic we also provide free pickup. After diagnostics you receive a specific price quote, and only then do you decide whether to proceed with recovery. You only pay for successfully recovered data. EXALAB® has been recovering data from RAID arrays since 2006.
EXALAB Data Recovery
Microshop s.r.o.
Pod Marjánkou 4
169 00 Praha 6
Česká Republika
Opening hours:
Monday to Thursday
9.00 - 18.00
Friday 9.00 - 17.30
other opening hours are possible upon agreement
Hotline: +420 608 177 773
Office: +420 233 357 122
E-mail: [email protected]
Hotline: +420 608 177 773
Kancelář: +420 233 357 122
E-mail: [email protected]
Opening hours:
Monday to Thursday
9.00 - 18.00
Friday 9.00 - 17.30
other opening hours are possible upon agreement
EXALAB Data Recovery
Microshop s.r.o.
Pod Marjánkou 4
169 00 Praha 6
Česká Republika
