In case of mechanical failures.

Introduction

If you have a mechanical failure (e.g. random crashes, just stops working one day, weird "screeching"/"beeping" type noises), EVERY time you plug it in and turn on, you are making it much worse. If it is very important data , I would recommend taking it to a lab / professional data recovery service: Many labs offer free diagnostics.

However, if you want to do it yourself, you can summarize mechanical failure into two categories:

Inside/Media problems or outside/controller problems.

First, Media/inside problems. This is the worst thing that can happen to a physical hard drive. If it is this, it really depends how bad.

If you have decided you want to do this yourself, first step is to clone or image the drive. Some tools allow for cloning/imaging from within Windows.

An example being (not free) is R-Studio. It allows you to create an image from the drive and performs many passes*, then perform the recovery from the image.

* The idea of multiple passes is to first read data that is easy to read while skipping over bad areas. We want to skip bad areas as reading those will put stress on the drive. Once we have all easy to read data we can concentrate on bad areas. Even if the drive completely fails at this point, we have the easy to read data (often the bulk). To recover bad areas we can then do even an additional pass in which we can be more aggressive, re-read sectors multiple times etc..

An even better idea can be to use tools like ddrescue or HDDSuperClone as they run on the Linux platform which is considered safer than Windows. Windows is more persistent where it concerns trying access unstable drives which results in more stress put on the drive.

If it is a controller board problem then the most common symptom is that a drive will not spin up (use ears to determine this).

We can replace the board with an identical PCB, however on modern drives this involves 'transplanting' the 'ROM'. Some specialized websites allow you to send in original PCB and swap the ROM for you.

If drive does not spin it's worth checking out the 'TVS' which acts as a power-surge protection. This is DIY-able, if TVS failed we can remove it and run the drive without it. The drive now runs without protection so it should be imaged/cloned ASAP and then no longer be used. For more information: https://web.archive.org/web/20230729145753/http://www.users.on.net/~fzabkar/HDD/TVS_diode_FAQ.html

Flash Drives

For flash drives, again, if the data is important, go to a lab. If you want to do it yourself, the same general strategy applies: clone/image the device if possible. As a rule of thumb, if the drive is detected in Disk management with correct capacity you can potentially recover the data yourself.

If correctly detected:

• Image/clone the flash drive (or memory card), example.
• Recover files from the image file

If the flash drive is detected but capacity is incorrectly displayed then controller works but it is in 'safe mode'. The most common causes for that being corrupt firmware or the inability to communicate with the NAND chip(s).

If the flash drive is not detected at all then the issue is of physical nature or a controller issue.

The latter two issues I do not consider 'DIY-able'.

In case of corruption or bad sectors.

Pray, it will help as it calms you down. :-)

Get direct access to the data.

When recovering files from an external drive it's important to have the shortest connection possible.

This means that you want to get rid of any extra USB cables, USB hubs or equipment you don't need.

If you are recovering from an external hard drive, try to get it out and connect it using a SATA cable...
If you are recovering from an USB stick, try to connect it to the back of your computer, try different ports.

Downloading and burn an Ultimate Boot CD needed for further steps.

Most tools used in this post are all available on the Ultimate Boot CD.

1. Download the Ultimate Boot CD at the bottom of this page: Click on the icon next to a mirror.

2. Optionally, to ensure quality, run a checksum with this program against the checksum listed here.

3. Burn the ISO to a CD using ImgBurn on Windows, LiquidCD on Mac OSX or Brasero on Linux.

4. Optionally, to ensure quality, make sure it verifies the CD.

Take a backup (EASEUS Disk Copy).

As we'll try to recover the file system and/or recover the data we are going to tamper with the disk, for this reason you might want to take a preliminary back-up to ensure that if things go wrong you still have a back-up available. If you suspect disk failure you might even want to consider to exercise the back-up instead so you can still send your hard drive to forensics companies if you really need the data...

1. Start the Ultimate Boot CD.

2. Go to HDD --> Cloning Tools --> EASEUS Disk Copy.

3. Do a disk copy to another device that has enough space free.

This will copy the data exactly at a sector-by-sector level.

Check if a hard drive is still in a fine state (SMARTUDM).

Before we tamper with the drive we want to be sure we aren't making its state worse, so let's first check the state:

1. Start the Ultimate Boot CD.

2. Go to HDD --> Device Management Tools --> SMARTUDM.

3. Check if any of the S.M.A.R.T. attributes has a ***** that is in yellow or red, this denotes a bad state.

If the state isn't fine, try to recover in case of mechanical issues.

If the state is fine, then we'll do an error scan to be aware and get rid of issues:

1. Start the Ultimate Boot CD.

2. Go to HDD --> Diagnostic Tools --> ViVARD.

3. Let it perform an error scan, note how much errors are found and how many remaps are done.

Identify the file system.

Covered by How do I identify the file system used on a partition?.

Try to repair (TestDisk).

Prior to doing the actual recovery, you might sometimes have the need to repair the partition(s) and file system(s) first. This is where TestDisk comes into play, I would recommend to take a look at what it does.

This is how to get to it:

1. Start the Ultimate Boot CD.

2. Go to HDD --> Data Recovery Tools --> TestDisk.

3. Read the documentation at the bottom of this page and try to repair your data.

Use recovery software (PhotoRec).

Now that the preliminary stuff has been done, this is how you can start recovering:

1. Start the Ultimate Boot CD.

2. Go to HDD --> Data Recovery Tools --> PhotoRec.

3. Read the documentation at the bottom of this page (example: step by step) and recover your data.

TestDisk is a free open source partition scanner and data recovery tool. It is very useful in recovering lost partitions. PhotoRec is another free commonly used data recovery tool. TestDisk and PhotoRec in addition to being included in the Ultimate Boot CD, as Tom Wijsman mentioned in his answer, are also included in the software repositories of many Linux distributions and on the System Rescue CD. System Rescue CD is similar to Ultimate Boot CD, but it is more lightweight, which is an advantage because it is normally run from a CD or a USB flash drive where performance is important.

TestDisk is a lot more efficient than PhotoRec. The problem with Testdisk is that it doesn't always recover all deleted files. If you accidentally reformat a partition, TestDisk can recover thousands of files without missing a single file, but if you deleted a file by sending it to the Trash and then emptying the Trash, TestDisk can't always recover it.

So use TestDisk first, and if you recovered all of the deleted files with TestDisk, then you're done. If you recovered most of the deleted files with TestDisk, you can decide whether you're done or not. If you're not done after running TestDisk, you can try recovering the deleted files using PhotoRec.

PhotoRec can't recover deleted files that have been completely overwritten (for example, with the dd program). In some cases, the filename is stored in the file itself. PhotoRec tries to recover the filename in this case, but most of the time PhotoRec can't recover the filenames.

Recover files based on filetype using PhotoRec

It is preferable to boot from a Linux live DVD/USB before following these steps, in order to avoid using the operating system in which the deleted file is located.

1. Install TestDisk if it is not already installed in your OS. In Linux distributions, installing TestDisk will also install PhotoRec along with it.

2. Open a terminal and launch PhotoRec (launch from a terminal in a live CD/USB or launch as root).

3. Select hard disk.

4. Select partition type.

   If your hard disk has Linux partitions, then select [Intel].

5. Select filetype option.

   Move to [File Opt] and press Enter. Here you can disable all file types by pressing s. Use space to toggle the check button. Select filetype(s) to recover.

6. Select options.

   PhotoRec also has a list of different options. Under normal circumstances you don't need to modify them.

7. Select partition.

   Move the selector to the partition from which you have removed the file. Then press Enter on [Search].

8. Select filesystem type.

   If you are using Linux, it's going to be ext2/ext3/ext4, so the default selection is ext2/ext3. Otherwise if you are recovering files from a partition formatted as FAT or NTFS select Other.

9. Select space for analysis.

   Select Free if you didn't write to that partition after removing the particular file, otherwise select Whole.

10. Select a directory to recover files.

    Now select the path where the recovered files will be stored. Then press Y.

PhotoRec will show how many files it has recovered.

_{Source: revised from How To Recover Deleted Files in Linux Using PhotoRec}

This answer addresses situations where a drive and/or file system were partially overwritten. Reasons could be:

• Partial/interrupted format
• Partial overwrite of start partition
• Partial wipe or zero-fill using a 'secure wiping tool'
• Wrong drive selected by Windows Media Creation Tool

The tool used in some examples is purely to demonstrate certain points, and is not an endorsement for this particular software.

Assumption is that many file system organize meta file system structures towards the start of a volume. This is particularly true for Microsoft file system like NTFS and the various flavors of FAT.

If any specific file recovery software can partially reconstruct the file system depends on the tool's intelligence with regards to working with partial file systems. It may come as a surprise, but many file recovery tools are not particularly good at this and will quickly fall back to raw or file signature based recovery. In this case filenames, folder structure will not be recovered and also non contiguous files will be corrupt. Signature based scans are also prone to 'false positives'. For example, tool claims to have detected a JPEG file while in reality it did not.

No matter the tool you settle for, you will need to configure it for a full scan. If for example file system was (partially) formatted with a different file system than the original, a full scan may be needed to detect the previous file system. If the tool permits configure it to scan for the previous file system. So, assume a exFAT volume was accidentally (partially) formatted with NTFS file system, set the tool to scan for ex(FAT) file system or vice versa depending on your exact scenario.

Assuming approximately 1 TB FAT32 partition, start of volume overwritten, biggest determining factor is whether FATs (file allocation tables) ,or at least one copy survived. No one can tell this in advance as multiple variables are at play; how much was overwritten and size of FATs.

IF FAT survived file system based recovery is possible. This means we can reconstruct (virtually) a folder structure, recover file names, and recover fragmented files.

Without the FAT we can (partially) reconstruct folder structure and filenames but we'd have to assume all files are contiguous. So result of recovery is dictated by amount of data that was overwritten:

Ideally when dealing with data-loss scenarios you clone or image the patient drive first. So for that you'd need a destination drive with sufficient capacity.

I suggest then you scan the clone/disk image (or patient drive if you decide not to clone) using a tool like DMDE. After scan select most promising file system.

Then click 'All found / Virtual file system > Default reconstruction > Parameters to determine state of file allocation tables.

Select 2nd FAT if 1st is partially damaged.

DMDE demo allows you to test recovery by actually saving some files. You can also preview for example JPEG files. Check some larger JPEGs and see if the look okay. If not the tool may have come up with incorrect file system parameters, start of file system and clustersize being most important:

As directory entries point to start cluster, file allocation table refers to cluster, two factors that need to be 'guessed' correctly is offset from which we start counting clusters + sectors per cluster.

Tools > Reopen Volume Parameters allows you to modify these parameters but modifying these requires understanding of FAT32 file system internals (and a bit of luck?).

Assuming NTFS a similar story applies, this time however it's the MFT that is important: How much of MFT did survive?

MFT usually is towards the start of the volume, it however common the MFT is fragmented and those additional fragments have a better chance of surviving.

The more of the MFT survives, the better and more complete file system reconstruction will be. You can only find out by trying. If part of the $MFT survived, partial reconstruction of folder structure may be possible which IMO is preferred over a purely raw recovery.

However more likely is that your recovery will largely consist of files detected by their magic bytes or signature, so without original filenames and folder structure.

A very common scenario is that Windows Media Creation tool was run and wrong drive selected. If the victim/target drive contains a single NTFS partition, it's likely the bulk of MFT data gets overwritten by the media creation tool and recovery software will not detect filenames or original folder structure.