We had a customer come to us with a crashed four-drive RAID 5 NAS. RAID had failed for some reason, but the disks themselves were fine. The customer had been attempting to recover data from the array using various recovery tools for six months. But none of them—including our tool—had worked.
Eventually, the customer came to us for help. Once we got permission for remote access, we started working on the case.
Although we always recommend connecting drives that are being recovered directly to the recovery computer via their native interfaces (in this case, SATA) the customer had connected the drives via USB. This resulted in the following side effects:
- It took RAID Recovery software several hours to scan the disks since the average combined read speed was about 15 MB per second for all drives.
- If the restart occurred, for example due to Windows update, the system enumerated disks in a different order and changed all the disk paths. In this case, RAID recovery had to be restarted because disk order was no longer valid.
However, these negative side effects didn’t bother the customer. The drives had already been sitting on the shelf for six months, so a few extra days didn’t matter.
We launched the scan and talked to the customer. We learned the disks contained many virtual machines, comprised of about a dozen small files and one really big one of about 1 TB.
Generally, volumes containing virtual machines are difficult to recover because each of the VMs has its own filesystem inside it. To make matters worse, VM disk image files usually are fragmented. So a dozen of them interspersed with each other formed, to put it mildly, a mess!
If the filesystem used in a VMware image files differs from the filesystem of the system hosting the virtual machines, usually it is possible to configure software to pursue only a particular filesystem and ignore others. But if all the filesystems are of the same type, that doesn’t work and the recovered data will contain clumps of all the filesystems.
Eventually, we were able to recover virtual disk image files, but then we faced another problem: we couldn’t mount them in VMWare. After some research, we found out that the files were created using an old version of VMware (at least a year old). In the meantime, VMWare had been upgraded several times. Theoretically, virtual disk image files should be compatible. But in practice, this didn’t work.
If you have a hammer, everything looks like a nail. So, instead of making VMware read the files, we applied data recovery once again, this time to VMware images, and extracted the files.
Limited success. The customer recovered a significant part of the data and we fixed a couple of bugs related to the files larger than a Terabyte on XFS.
Could the customer have solved the problem on their own? Probably not. Generally, data recovery cases fall into one of the following types:
- Physical damage – Not usually considered DIY. For example, a hard drive produces unusual noises. In this case, repair of the physical disk is required, which can be performed only in a data recovery lab, before recovery can be attempted.
- Formats and overwrites – Usually considered non-recoverable. For example, you formatted a device using low level mode or just overwrite the data.
- Simple logical damage – Usually recoverable using consumer data recovery tools. For example, Windows reporting a "RAW filesystem" or accidental deletion of some data.
- Complicated logical damage – Tough to call, but usually requires a professional service. In complicated cases like the one above, it is difficult to know in advance which tool will work. The more complicated the case, the lower the chance of finding the tool that works. In such cases, it makes sense to contact your data recovery tool vendor’s tech support. They might be able to adjust their recovery algorithms to cover your particular case.
In this particular case, no data recovery software was up to the task. Even a partially successful recovery required some tuning of our software.
Elena Pakhomova does both marketing and development for data recovery software company ReclaiMe.com.