Data Recovery Weekly

Now ReclaiMe Pro supports EnCase E01 images which you can load at start and then recover data from the virtual disk created over the loaded E01 segments.

We now have what I think is the words-first commercial (for sale) Drobo recovery capability, included in our ReclaiMe Pro software. This comes in two parts, 1. read Drobo metadata is readable 2. partially rebuild Drobo metadata if there is not enough of it to be readable and we have it in a for-sale software there was recent announcement on HddGuru forum by some fellows doing the remote recovery, but they are not selling their software; we sell software.  What it works with, well, Drobo 5D/5N/FS (NAS and DAS variants). Not tested yet with B800i iSCSI variant of the Drobo.

This is a short list compiled based on the tech support experience,without much explanation Avoid USB-to-SATA converters (for bad reliability); Marvell chipsets (for bad handling of bad sectors); Silicon Image controllers or any RAID cards based on these (after SIL_QUIRK_MOD15WRITE; even if SIL_QUIRK_MOD15WRITE does not apply to your controller, this is not an excuse to use Sil); nVidia chipsets (for bad reliability of disk controllers under load)

Been answering a support query recently, and mentioned to client that USB is outright bad in all respects [for data recovery use]. Well, pretty much so, if one of the drives has a bad block, quite likely the USB converter will lock up on hitting that block; with USB 2.0, speed is 15 MB/sec maximum, for all drives combined, even if you have what appears to be different ports, they will be routed through a same root port or hub anyway; devices advertised as USB 3.0 often work at 2.0 speeds, with no warning whatsoever; power supply issues and limitations are difficult to control,  especially so if hubs are involved; any setup with daisy-chained hubs is unstable, especially so with USB 3.0; So, think twice before starting a recovery with a laptop-based all-USB setup.

Once in a while people demand that we provide technical support not only by e-mails, but by phone as well. Despite the apparent reasonableness of the request, it is not that simple in practice. A typical case of technical data recovery support via email looks like the following:   A client contacts our technical support and describes his or her problem for the first time.   We send a reply where we ask the questions to clarify obscure points. Usually we have three to five questions (although there may be more) which are organized as a numbered list. In the following email a client answers the questions. There are cases when client needs time to think or do some simple checks to answer the questions. In response to the message from a client, we send a list of recommended actions or step-by-step instructions as to what he or she should do next. There are cases when boilerplate instructions fit just right; however, almost half of all cases require pondering on o...

In average, ReclaiMe File Recovery brings data in less than 48 hours - with NTFS you typically see the files within a couple of hours, with HFS or ReFS you should wait till the end of the scan which takes about 12 hours for a 2 TB disk (SATA connection). ReclaiMe RAID Recovery scans drives in parallel so you are limited by the slowest and largest drive - with a 4 TB drive in the set you expect something like 24 hours. So, in 48 hours you definitely get data with ReclaiMe software. If recovery takes more than 48 hours, it is possible that there is a failed drive (with bad sectors) and you should consider imaging the drive in question first. If the PC running data recovery cannot work for 48 hours non-stop, you should repair hardware first and only then proceed with data recovery. Anyway, with such a PC there is a great chance that data recovery will produce either incorrect data or, even worse, something that seems to be normal files with just "slightly" damaged content...

When one deals with data recovery, sometimes he worries about the confidentially of the recovered data. Look at the example below: ...a Western Digital HD that makes clicking noises. .... The HD has many customer credit card numbers and legal documents on it, so confidentiality is very important to us. If the automatic data recovery software works well enough, there is no problem. In this case one recovers data himself and data always stays on his own computer. In all the other cases, for example, when a mechanical repair of disk is required, a technician has full access to a disk and that data which he is able to recover. Any respectable data recovery company usually doesn't reject to sign either a non-disclosure agreement (NDA) or an agreement that data cannot be viewed at all during a disk repair. The prohibition of reading data makes data recovering harder because of two reasons: Quality control becomes more difficult, and often impossible at all. Some data recovery programs p...

Probably as soon as tomorrow. The only thing still missing is a comparison test against typical failure modes: file deletion, format, and bad blocks.

We've been working for a couple of weeks now to implement an XFS recovery capability for our ReclaiMe data recovery software . The single most significant impression is that XFS is unnecessarily and exceedingly complex. Having... how many that would be, five? types of directories is actually OK, as long as these types utilize the same basic structures and design. Taking design commonalities into account, the number of distinct directory types is reduced to just two. Data storage comes in three forms (NTFS and ext4 are both OK having just two). The most interesting discovery of all to date was that each allocation group has two different sizes.

Some do actually like non-standard hardware and software setups. If we build a 16 TB RAID 5 (9x 2TB), can we then install Windows on it? Probably yes, with some U/EFI trickery, but then troubleshooting this contraption if hardware ever dies would be a nightmare with 9 drives. Now another try We have a leftover of drives, like all sorts of 160GB to 2TB Parallel ATA, all sorts of Serial ATA, five RAID/HBA controllers, and a motherboard. We thought of putting it all together and deploying ZFS over it. Do you think it is a good idea? Actually, no. The complexity of the failure modes for the proposed design is just mind-boggling. First of all, when ZFS crashes, there is no reliable data recovery for it. Then, multiple HBA/RAID cards from different vendors in the same system are not going to work stable. More then, with a different size drives, no common RAID scheme can be applied. Should the RAID fail, the system is not recoverable. OK you can go with ZFS hybrid filesystem-RAID capability, ...

Every once in a while we do a remote recovery session via TeamViewer. The most annoying thing in remote recoveries actually is not knowing who is in control . TeamViewer does not provide any feedback when the other party is going to take over by pulling a mouse cursor away. The fact that someone is standing on the remote side watching what you doing, and you cannot even tell if they are there or not, is not very comforting but acceptable. With remote recoveries, it is a part of a job, actually. Someone may choose to ride the shotgun with you. The real problem starts when they interfere with what you are doing and there is no way to stop it. This is not really because people on the remote side are specifically evil, just because there is no convenient way to establish who is in control, and how to request or how to relinquish it. Damn annoying still.

A full, start-to-end RAID recovery is generally a three part process. Determine status of the member disks and make clones when required. Detect RAID parameters and perform destriping If the destriped volume is not readily mountable, perform filesystem recovery on it to pump out the data Now, if the above three steps fail to produce correct data, the question is how do we tell if it is RAID recovery part, or filesystem analysis part that failed ? We tell if the RAID recovery is OK by looking at the sizes of the recovered files. If there are multiple good files recovered which are larger than twice the full row size (i.e. larger than 2 * block_size * num_disks), then the RAID recovery is almost certainly OK. However, if all good files are of the small size, the RAID parameters should be investigated. This also applies to the files found by raw scan; however, keep in mind that file sizes produced by raw scan are not reliable.

Linux filenames are case-sensitive, and hence ext filesystems allow files which are only different by upper vs. lower case. Okay, this is to be expected. More interestingly, it is possible to have a directory Test and a file test within the sampe parent directory. Does not look like we can resolve it gracefully, because under Windows we have to rename one of those. Obviously, it seems better to rename a file. However, this still breaks the program which used a file named test to contain some catalog of the folder named Test .

... people still believe you can get an electron microscope and recover overwritten data . It is not an electron microscope, it should be an MFM, Magnetic Force Microscope. Electron beams are no good against the hard drive platter. Probably no harm either, just useless. Even with MFM, no recovery of overwritten data on a modern hard drive is possible, because of various aspects of applied physics.

... but less than 100% reliable, though. See this - http://www.technibble.com/forums/showthread.php?t=24345 . Given that you can literally burn the laptop in fire, and still recover all the significant data, why would anyone bother with backups at all? Disclaimer: just kidding

Reading the article on NTCompatible as they test data recovery software and fail to recover data from TRIM-enabled SSD (which is pretty much the expected behavior), I see they're a little bit puzzled because some data would still remain even on a TRIM-enabled SSD. Interestingly, some traces to specific data remained, and that's one oddity I don't quite understand. The answer is actually pertty simple - these were NTFS resident files. On NTFS, when the file is deleted, its MFT record is marked "free, available for reuse", but never actually relinquished back to the free space. Because NTFS uses MFT entry numbers internally to address a parent-child relationships. Removing one entry would require an entire volume to be reunmbered, which is cost-prohibitve. So, the data outside MFT is zero-filled immediately once TRIM command is issued. The MFT entires however remain unchanged. This explains they were able to get file names and correct file sizes, but the dat...

Some new technologies have side effects which decrease data redundancy. Such technologies are: NTFS compression Windows Vista/7 vs. Windows NT/2000/XP complete format TRIM on SSDs ZFS deduplication Initially, the effect of decreasing redundancy is unnoticeable, but once the technology becomes popular, the unintended consequences appear. Volume-level NTFS compression never became widespread among home users. As Windows Vista and then Windows 7 become widespread, the number of cases when data is lost irreversibly due to reinstallation increased. You can recover some data after XP reinstallation, but not after Vista/7 reinstallation with a complete format. SSDs with TRIM are not widespread enough (yet) to notice that data recovery software does not properly work with them. As for ZFS-based NASes, then on the one hand they are not widespread among the home users, on the other hand - even the first installations did not yet reach the end of their service life.

Data recovery software is based on the filesystem and user data redundancy. In case of significant filesystem damage user data redundancy is often required for data recovery software . Elimination of user data redundancy using a compression (as in NTFS) or a deduplication (as in ZFS) complicates automatic data recovery.

Data recovery after reinstalling Windows yields better results than it can be expected. During the reinstall, the drive is formatted and the new copy of Windows is installed. If the format was "Complete" and it was Windows Vista/7 that was installing then nothing can be recovered. During the format, Windows Vista and Windows 7 overwrite the drive content with zeros. If you use the "Quick" format, then Windows will be installed on the clean drive, in the same way as it was installed the first time. Since a computer always produces the same result for the same task, the new copy will be written over the previous copy (except for possible different selection of the components to be installed). Thus the previous Windows files will be overwritten, but not the user files which were written later. Certainly some files will be lost (e.g. data saved in a registry like settings and passwords), but the documents have a good chance to survive a reinstallation. This approach do...

When recovering data from a USB external hard drive, you should keep an eye on a data read speed. If the speed is less than 2 MB (megabyte) per second, it would be better to abort the recovery and figure out in what mode the devices are working. The speed is of less concern with smaller devices, that is if you need to recover pen drive , you just sit, watch, and wait it out. There are two different versions of the USB protocol, USB 1.1 and USB 2.0 . From the user point of view, these protocols differ from each other only by a data transfer speed. USB 1.1 transfers maximum ~ 1.5 MB/sec, while USB 2.0 can achieve ~ 50 MB/sec. If several USB devices involved in a data transfer use different USB protocols, the lowest data transfer speed is used. Although USB 2.0 was developed in 2000, USB 1.1-only hard drive enclosures and card readers are still produced. If you are going to buy a USB enclosure for external hard drive recovery , check that it supports the USB 2.0 protocol. Data recovery f...