This is a subject that comes up often on the various forums, so I figure I'll just create a tutorial about it and when the subject arises we can just point people here.
Introduction: When a hard drive is known, or assumed, to have bad sectors the first thing that you should ever do before attempting data recovery is getting a good clone of the good sectors which you can work from. Attempting to scan and recover data from such a drive directly without cloning first is very likely to result in the drive completely failing. In data recovery, it is best practice to always clone first because in many cases there are bad sector areas of supposed "healthy" hard drives that can cause them to fail during the process.
The best way to clone is using specialized hardware such as DeepSpar Disk Imager, Data Extractor (in PC-3000), Atola, etc. However, for the sake of this tutorial, we'll assume that you don't have access to such hardware and need to do this using software only.
Please Note: if your data is critical to your life and/or business it is always best to seek out professional data recovery services rather than attempt this yourself. Also if your hard drive is clicking, making other strange noise, showing the wrong capacity, or not appearing in BIOS you should immediately power it down and seek professional advice. Neither Data Medics LLC, the owner of this forum nor its author take any responsibility for the results of any DIY data recovery attempts.
Why you can't clone in Windows: There are a great number of Windows-based data recovery and backup programs out there that make claims of being able to clone hard drives with bad sectors. This may be partly true, as some employ bad sector skipping code to jump ahead a large number of sectors when a bad sector is hit and attempt to continue. However, none are well suited to the task simply because all Windows-based applications rely on the Windows host controller to interface with the drive. Currently, there is no known workaround for this in Windows. The Windows host controller, unfortunately, does not allow software running in Windows to directly control ATA commands issued to the drive (such as read timeouts) which are necessary to effectively clone as much data as possible from hard drives with bad sectors. Fortunately, there is another OS capable of running on your computer that does not suffer from these same constraints...
Linux: This open source free operating system gives applications far more control of the hardware they interface with and is well suited for handling this type of issue. Even better most builds of Linux include a copy of a free tool with some great features for cloning hard drives with bad sectors...GNU ddrescue. Not to be confused with dd or dd_rescue which are similar programs but not quite as good for this task.
For the purpose of this tutorial, we'll be using a Knoppix Live edition of Linux due to its ease of use, however many other builds of Linux can be used as well.
Step 1: Setting up a Linux Live CD, DVD, or USB
You can simply download and burn the ISO file of Knoppix to a CD or DVD: Available Here
Or for even better performance you can easily set up a Live USB stick using this program: LinuxLive USB Creator
After you've installed the program, simply run it, select your USB key, select download, and then find Knoppix in the drop-down box of available builds. The rest is pretty self-explanatory.
Step 2: Boot your system into Linux
Usually, this is a simple matter of rebooting your system and then either adjusting the boot order in BIOS or hitting a function button such as F8 to select an alternate boot device. On initial start-up Knoppix will need to go through some persistent memory configuration. You'll want to take care of this as the persistent memory will come in handy later. Generally, you should set it to as much as possible.
You'll also want to install ddrescue and hwinfo packages if they aren't already present. Just open a terminal and type the following commands one at a time and be sure to select 'y' when prompted in the terminal:
Step 3: Connect the Source and Target Hard Drives
This can be done before boot if you'd like and if it's IDE you'll have to do that, however, Linux supports hot connecting SATA devices quite well on most hardware, so I find it's generally best to connect afterward to avoid unnecessary accessing of the device during boot.
Note: It's imperative that you actually direct SATA connect the source drive (one your recovering data from) to the computer, and not use a USB adapter! The target or destination drive can be connected via USB if it's easier, however, this may slow the process down in some cases.
Also, you'll want to determine a location to store the log file (extremely important - this is more than just a log). You can use the persistent memory of the Linux USB if you'd like, or (if using a CD/DVD) you can connect another thumb drive to store the log file. In the example below I'll be using the persistent memory so I can store the log files on the desktop in Linux.
Step 4: Determining the device paths
The easiest way to do this is to simply open a terminal in Linux and type in the following command:
This will provide a basic list of all hardware connected to the system. If you scroll up just a bit, you'll see a list of the storage devices along with serial/model number, and their respective paths (E.G. "/dev/sda1"). At this point should double (or even triple) check which physical drive is which based on serial number, model number, etc. and then write down their paths on a piece of paper noting which is your source and destination drives. Be aware that if you disconnect and reconnect a drive the path is likely to change. If you accidentally clone the wrong direction there is no going back, period!
Step 5: Issuing the ddrescue command in terminal
The basic ddrescue syntax is: ddrescue [triggers] [source drive] [destination drive] [log file full path]
Some triggers you'll want to be familiar with for this process:
(all are case sensitive)
-f [Force] This is always necessary to use if you're cloning to an actual drive and not an image file.
-d [Direct Access] Gives the program direct access to the storage device (not always necessary, and may give errors if system doesn't support it)
-R [Reverse Clone] Very handy to clone both directions to and from a large area of bad sectors
-r [number of retries] Generally shouldn't be used on the initial clone, but perhaps on successive passes
-A [Try Again] Marks all failed blocks to unread in the log and attempts again (only use after first pass of cloning)
There are also a number of other triggers available on this website, but most you won't need for this process.
Why you must use a log file: This file is not just a log of the program's activity as you might suspect. Personally I think it should be renamed. It's actually a list of sector ranges which have been copied, skipped, marked as bad, etc. which the program will use on successive passes to get as much data as possible. When cloning a drive with bad sectors this feature must always be used.
So then assuming that your source drive is "/dev/sda" and the target drive is "/dev/sdb" your first pass attempt to clone the data will look something like this:
(I used the desktop to store the log so I can look at it & manually edit it if needed. Note that even the paths are case sensitive)
At this point you should see the program go to work "rescuing" data. You'll also notice a speed indicator which let's you know how fast it's cloning data onto the target drive. At times, it'll hit an area of bad sectors and slow down (this is perfectly normal). The program will then automatically jump ahead read backwards up to the area of bad sectors and then continue reading forward again (this is all automated if you used a log file). After it has completed reading the drive, it will also then automatically go back and "split" the bad sector areas in half and attempt reading the sectors in between.
If you want to pause the process press "Ctl + C" and it will stop. You can then adjust the triggers in the command and re-issue it if you want.
Generally this process will pick up just about as many sectors as you can expect to grab, however if you want to run another pass and try to get some more data you can then try using the -A trigger to retry all the bad areas.
Occasionally a drive will have one or more areas of severe bad sectors that the program struggles to get through, or even will cause the drive to become completely unresponsive. In such a case you'll want to use the -R (reverse) trigger. Then the drive will read backward up to the same area, hopefully getting the majority of the data. If the drive has become unresponsive you may need to power cycle the drive (unplug it & plug it back in), recheck its path (likely to change), and then reissue the command using the new drive path, but the same log file.
So a reverse clone command using the same above example will look like this:
When issuing subsequent commands in Linux terminal the Up Arrow can be used to cycle through past commands you've typed so you can quickly adjust the command and re-input it.
After you're confident that you've cloned as much data as possible using ddrescue, you're now ready to move the target drive over and begin scanning it with data recovery software such as R-Studio to begin the file recovery.
Hopefully, this helps someone.
Introduction: When a hard drive is known, or assumed, to have bad sectors the first thing that you should ever do before attempting data recovery is getting a good clone of the good sectors which you can work from. Attempting to scan and recover data from such a drive directly without cloning first is very likely to result in the drive completely failing. In data recovery, it is best practice to always clone first because in many cases there are bad sector areas of supposed "healthy" hard drives that can cause them to fail during the process.
The best way to clone is using specialized hardware such as DeepSpar Disk Imager, Data Extractor (in PC-3000), Atola, etc. However, for the sake of this tutorial, we'll assume that you don't have access to such hardware and need to do this using software only.
Please Note: if your data is critical to your life and/or business it is always best to seek out professional data recovery services rather than attempt this yourself. Also if your hard drive is clicking, making other strange noise, showing the wrong capacity, or not appearing in BIOS you should immediately power it down and seek professional advice. Neither Data Medics LLC, the owner of this forum nor its author take any responsibility for the results of any DIY data recovery attempts.
Why you can't clone in Windows: There are a great number of Windows-based data recovery and backup programs out there that make claims of being able to clone hard drives with bad sectors. This may be partly true, as some employ bad sector skipping code to jump ahead a large number of sectors when a bad sector is hit and attempt to continue. However, none are well suited to the task simply because all Windows-based applications rely on the Windows host controller to interface with the drive. Currently, there is no known workaround for this in Windows. The Windows host controller, unfortunately, does not allow software running in Windows to directly control ATA commands issued to the drive (such as read timeouts) which are necessary to effectively clone as much data as possible from hard drives with bad sectors. Fortunately, there is another OS capable of running on your computer that does not suffer from these same constraints...
Linux: This open source free operating system gives applications far more control of the hardware they interface with and is well suited for handling this type of issue. Even better most builds of Linux include a copy of a free tool with some great features for cloning hard drives with bad sectors...GNU ddrescue. Not to be confused with dd or dd_rescue which are similar programs but not quite as good for this task.
For the purpose of this tutorial, we'll be using a Knoppix Live edition of Linux due to its ease of use, however many other builds of Linux can be used as well.
Step 1: Setting up a Linux Live CD, DVD, or USB
You can simply download and burn the ISO file of Knoppix to a CD or DVD: Available Here
Or for even better performance you can easily set up a Live USB stick using this program: LinuxLive USB Creator
After you've installed the program, simply run it, select your USB key, select download, and then find Knoppix in the drop-down box of available builds. The rest is pretty self-explanatory.
Step 2: Boot your system into Linux
Usually, this is a simple matter of rebooting your system and then either adjusting the boot order in BIOS or hitting a function button such as F8 to select an alternate boot device. On initial start-up Knoppix will need to go through some persistent memory configuration. You'll want to take care of this as the persistent memory will come in handy later. Generally, you should set it to as much as possible.
You'll also want to install ddrescue and hwinfo packages if they aren't already present. Just open a terminal and type the following commands one at a time and be sure to select 'y' when prompted in the terminal:
Code:
sudo apt-get update
sudo apt-get install gddrescue
sudo apt-get install hwinfo
Step 3: Connect the Source and Target Hard Drives
This can be done before boot if you'd like and if it's IDE you'll have to do that, however, Linux supports hot connecting SATA devices quite well on most hardware, so I find it's generally best to connect afterward to avoid unnecessary accessing of the device during boot.
Note: It's imperative that you actually direct SATA connect the source drive (one your recovering data from) to the computer, and not use a USB adapter! The target or destination drive can be connected via USB if it's easier, however, this may slow the process down in some cases.
Also, you'll want to determine a location to store the log file (extremely important - this is more than just a log). You can use the persistent memory of the Linux USB if you'd like, or (if using a CD/DVD) you can connect another thumb drive to store the log file. In the example below I'll be using the persistent memory so I can store the log files on the desktop in Linux.
Step 4: Determining the device paths
The easiest way to do this is to simply open a terminal in Linux and type in the following command:
Code:
hwinfo --short
Step 5: Issuing the ddrescue command in terminal
The basic ddrescue syntax is: ddrescue [triggers] [source drive] [destination drive] [log file full path]
Some triggers you'll want to be familiar with for this process:
(all are case sensitive)
-f [Force] This is always necessary to use if you're cloning to an actual drive and not an image file.
-d [Direct Access] Gives the program direct access to the storage device (not always necessary, and may give errors if system doesn't support it)
-R [Reverse Clone] Very handy to clone both directions to and from a large area of bad sectors
-r [number of retries] Generally shouldn't be used on the initial clone, but perhaps on successive passes
-A [Try Again] Marks all failed blocks to unread in the log and attempts again (only use after first pass of cloning)
There are also a number of other triggers available on this website, but most you won't need for this process.
Why you must use a log file: This file is not just a log of the program's activity as you might suspect. Personally I think it should be renamed. It's actually a list of sector ranges which have been copied, skipped, marked as bad, etc. which the program will use on successive passes to get as much data as possible. When cloning a drive with bad sectors this feature must always be used.
So then assuming that your source drive is "/dev/sda" and the target drive is "/dev/sdb" your first pass attempt to clone the data will look something like this:
Code:
ddrescue -f /dev/sda /dev/sdb /home/users/knoppix/Desktop/log1.log
At this point you should see the program go to work "rescuing" data. You'll also notice a speed indicator which let's you know how fast it's cloning data onto the target drive. At times, it'll hit an area of bad sectors and slow down (this is perfectly normal). The program will then automatically jump ahead read backwards up to the area of bad sectors and then continue reading forward again (this is all automated if you used a log file). After it has completed reading the drive, it will also then automatically go back and "split" the bad sector areas in half and attempt reading the sectors in between.
If you want to pause the process press "Ctl + C" and it will stop. You can then adjust the triggers in the command and re-issue it if you want.
Generally this process will pick up just about as many sectors as you can expect to grab, however if you want to run another pass and try to get some more data you can then try using the -A trigger to retry all the bad areas.
Occasionally a drive will have one or more areas of severe bad sectors that the program struggles to get through, or even will cause the drive to become completely unresponsive. In such a case you'll want to use the -R (reverse) trigger. Then the drive will read backward up to the same area, hopefully getting the majority of the data. If the drive has become unresponsive you may need to power cycle the drive (unplug it & plug it back in), recheck its path (likely to change), and then reissue the command using the new drive path, but the same log file.
So a reverse clone command using the same above example will look like this:
Code:
ddrescue -f -R /dev/sda /dev/sdb /home/users/knoppix/Desktop/log1.log
When issuing subsequent commands in Linux terminal the Up Arrow can be used to cycle through past commands you've typed so you can quickly adjust the command and re-input it.
After you're confident that you've cloned as much data as possible using ddrescue, you're now ready to move the target drive over and begin scanning it with data recovery software such as R-Studio to begin the file recovery.
Hopefully, this helps someone.
Last edited: