External USB Hard Drive Data Recovery

A customer brought this Western Digital external hard drive to us as it wasn’t being recognised by their PC.

The most likely cause of this- and indeed, the most common fault with external hard drives- is that the USB interface (rather than the drive itself) had stopped working. This used to be a simple repair because most external hard drives were little more than internal SATA drives- either 2.5″ laptop or 3.5″ desktop size- with a case and USB interface attached. Once the case was opened, the SATA drive could be unplugged from the USB interface and put in a new enclosure (essentially just a replacement interface and case) that could be bought for less than £10.

Unfortunately, this is no longer the case with most recent external hard drives, as these tend to have the USB controller/interface directly built on to the hard drive board itself (and no SATA connector). This is partly to help keep the size down, and partly because people were removing the internal hard drives and selling them separately. The end result, however, is that the repair is no longer just a simple controller swap.

When recovering data from a hard drive you should never do it over USB. We need to access the drive as directly as possible, and even plugging it into a conventional SATA interface on a PC isn’t ideal- the drive speaks to the SATA controller that in turn speaks to the BIOS and then the software. Adding a USB controller into the mix it makes these problems far worse, since there’s almost no way to get direct, low-level control of the drive via USB.

The best solution is to use a specialized hardware-based controller. This communicates with the drive at a much lower level- there’s no intermediate BIOS or SATA controller involved. It’s the most reliable solution as we can send manufacturer-specific commands to the drive. For instance, if it detects an unresponsive drive, it will kill the power instead of continuing to try and read. This allows for a more reliable recovery.

 


The faulty external hard drive.

The drive after being removed from the external case.

Note the USB connector (Micro USB 3.0) where a regular internal drive would feature a SATA connection.

Swapping the ROM from the current USB board to the SATA drive board.

The SATA board has now been fitted to the original hard drive.

Retrieving data via our hardware-based controller.

 

The first thing we want to do with this drive is to convert it from USB to SATA. To do this we found the equivalent SATA version of this drive and removed the board from it. It’s not as simple as swapping the board over- we also need to transfer the ROM as this contains a lot of information specific to our faulty drive. This involves desoldering the ROM from both controllers and swapping them round.

Once we have the drive converted we need to image this drive onto a good drive. The reason we do this is that you should never work on a failing drive more than necessary. The longer we continue to try and read from it the more damage we’re doing to the heads. We may only have one chance of recovering the data, so we want to keep an identical mirror of it to work with.

To do this we’re using our special hardware based imaging device. This is much better than using software for a number of reasons:-

  • Firstly, as we said earlier, it can communicate with the drive on a lower level using manufacturer specific commands.
  • It can kill power to the drive if it detects it struggling to read.
  • It can skip reading sectors that have a high response time meaning it can recover a lot of the data faster from the good sectors first. (This is important when the drive is possibly failing, as we want to get as much off as we can before it fails completely).
  • It can turn individual heads on and off so that it can read from only the heads that are working.

Usually, it would take us less than 24 hours to read most hard drives, but the heads were really weak on this drive so it took much longer. We started imaging on the 28th of July, and the process finally finished over two weeks later(!) on the 12th of August. While we could have speeded up the process by swapping the heads, this would have increased the cost of this recovery dramatically for the customer.

We now have a raw image of the faulty drive’s data transferred onto our new, working drive. However, because some parts of the filesystem will have been corrupted or missing (due to bad sectors or other problems reading the original drive), we still need to run this through recovery software to get back as many of the original files as possible.

Fortunately- and in significant part due to our technician’s skill- we had a very high success rate in this case. Most of the data was able to be saved and more importantly, the pictures the customer needed were recovered.

 

Imaged copy of the original drive containing raw data after it had been retrieved.
Running software on the raw data in order to recover files.

Thumbnails of recovered images. (Censored for reasons of customer privacy).

 

0 comments

Write a Comment

Fields with * are requierd