ddrescue help

[Vicenarian]

Ok, so do I have this right:



Identify System Drives:

Run fdisk -l and identify disks (source, target, and logfile location)

fdisk -l

Mount Device to Store Logfile:

mkdir /media/storage
mount -t ntfs-3g /dev/zzz /media/storage

(where zzz is the disk name you want the logfile saved to)

Running ddrescue (First Pass):

ddrescue -B -v -n /dev/XXX /dev/YYY /media/storage/logfile.log

Where:
XXX = name of the complete source disk (NOT the partition.)
YYY = name of the complete target disk (NOT the partition.)
-B = use binary expressions
-v = verbose mode
-n = skip bad sectors

Running ddrescue (Second Pass):
ddrescue -d -r 3 /dev/XXX /dev/YYY /media/storage/logfile.log

-d = direct disk access mode
-r 3 = retry reading bad sectors 3 times

Edit: fixed typos

 

[SilverLeaf]

Looks OK. Just some quick thoughts.

Double and triple check your command to make sure you have the devices correct. Otherwise, you could easily have a big problem.

I usually store the logfile on my test bench, so I don't have to specifically mount a separate device on which to store it.

You will be required to use the -f switch if you destination is anything other than an image file (ie disk or partition)

I know it's a good idea to use two passes, but I frequently use just one

# ddrescue -f -d -r3 /dev/xxx /dev/yyy /path/to/logfile

 

[Vicenarian]

Looks OK. Just some quick thoughts.

Double and triple check your command to make sure you have the devices correct. Otherwise, you could easily have a big problem.

I usually store the logfile on my test bench, so I don't have to specifically mount a separate device on which to store it.

You will be required to use the -f switch if you destination is anything other than an image file (ie disk or partition)

I know it's a good idea to use two passes, but I frequently use just one

# ddrescue -f -d -r3 /dev/xxx /dev/yyy /path/to/logfile

Thanks for the tip on using the "-f" switch. If I decide to do a subsequent run of ddrescue (another pass), should I use the exact same command as the first time, including the -f switch?

Edit: I *might* have answered my own question by reading this from the ddrescue manual examples:

"Example 1: Rescue a whole disc with two ext2 partitions in /dev/hda to /dev/hdb.
Note: you do not need to partition /dev/hdb beforehand, but if the partition table on /dev/hda is damaged, you'll need to recreate it somehow on /dev/hdb.
ddrescue -f -n /dev/hda /dev/hdb logfile
ddrescue -d -f -r3 /dev/hda /dev/hdb logfile
fdisk /dev/hdb
e2fsck -v -f /dev/hdb1
e2fsck -v -f /dev/hdb2"

I'm guessing everything should be basically the same with a ntfs filesystem, except the last two lines using fsck to repair ext2 filesystems, right?

The first line is an initial disk-to-disk clone, trying to rescue the good sectors first, and using the -f switch as it's a disk-to-disk operation.
The second line uses direct disk access (-d), forces the overwriting of the output file (-f) and specifies 3 read retries before giving up (-r3)

One thing I've also noted is that, if you shut down the machine between passes, you need to make sure to mount the drive/filesystem that holds the log file, each time, before you invoke ddrescue. Obvious I guess, but just wanted to mention it.

 

[SilverLeaf]

The -f is sort of a safety check. If you are imaging directly to another drive or partition without using the -f switch, you will get an error. This protects you from doing something accidental
So, unless you are writing to an image file ( say ddrescue /dev/xxx /path/to/imagefile ) you will need the "force" switch.

Here's a good reference with examples: http://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html

 

[Vicenarian]

The -f is sort of a safety check. If you are imaging directly to another drive or partition without using the -f switch, you will get an error. This protects you from doing something accidental
So, unless you are writing to an image file ( say ddrescue /dev/xxx /path/to/imagefile ) you will need the "force" switch.

Here's a good reference with examples: http://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html

Gotcha; thanks again for your help , it's much appreciated as I'm not that great with the linux command line. The disk cloned successfully, and it's currently retrying one "error" which is only about 2000 B (two MB?), so I'm not too worried. I'll let you know the outcome. Thanks again!

 

[16k_zx81]

wish someone would write a front end for this

i have used it a few times but cant be bothered with all the command line rubbish these days

i must be getting old.....

 

[SilverLeaf]

Gotcha; thanks again for your help , it's much appreciated as I'm not that great with the linux command line. The disk cloned successfully, and it's currently retrying one "error" which is only about 2000 B (two MB?), so I'm not too worried. I'll let you know the outcome. Thanks again!

Sounds like you've got it

If I'm rescuing a windows disk, I use ddrescue first, run chkdsk on the new drive afterwards, and then sfc just in case.
Of course this is assuming that ddrescue was able to complete without a significant amount of un-recoverable data. Otherwise, it usually becomes a windows re-install with a transfer of the rescued data.

 

[rjframe]

wish someone would write a front end for this

i have used it a few times but cant be bothered with all the command line rubbish these days

i must be getting old.....

http://sourceforge.net/projects/kdiskrescue/

 

[16k_zx81]

http://sourceforge.net/projects/kdiskrescue/

Thanks

I have used google in the past, but this puts me off using it:

Alpha

Last Update: 2009-07-17

 

[Vicenarian]

Update:

RAGE QUIT!!!! ARGH!!!! AAAAAAAH!!!!!!!! UGGGHH!!!!


Ok...so, after spending probably what, 6 hours working on this machine, I can't get it to work! LOL

As mentioned, ddrescue was able to copy the disk to another (new) disk with only one error, around 2 MB. It retried copying that bad sector(s) for about 25 minutes, unsuccessfully, and just gave up after that. I then tried to boot the computer with the new drive, which would begin to load the Desktop, and then BSOD with a 0x22 FILE SYSTEM error. Ok, ran CHKDSK (/f, /r, /b, tried all of them) which fixed a few filesystem problems, and the issue persists!!? I did an offline SFC as well, which didn't find any system files corrupted.

So I pop the old drive back in and everything works...I give up

 

[SilverLeaf]

Update:

RAGE QUIT!!!! ARGH!!!! AAAAAAAH!!!!!!!! UGGGHH!!!!


Ok...so, after spending probably what, 6 hours working on this machine, I can't get it to work! LOL

As mentioned, ddrescue was able to copy the disk to another (new) disk with only one error, around 2 MB. It retried copying that bad sector(s) for about 25 minutes, unsuccessfully, and just gave up after that. I then tried to boot the computer with the new drive, which would begin to load the Desktop, and then BSOD with a 0x22 FILE SYSTEM error. Ok, ran CHKDSK (/f, /r, /b, tried all of them) which fixed a few filesystem problems, and the issue persists!!? I did an offline SFC as well, which didn't find any system files corrupted.

So I pop the old drive back in and everything works...I give up

I wonder what size drive you are trying to rescue, and how long the ddrescue process took? Ddrescue generally takes a long time to run, especially if it finds bad sectors. You mentioned 6hrs. My sessions with ddrescue can sometimes take 20+ hours to complete on a damaged drive of any size. When you examine the contents of the new drive, does it appear that the appropriate amount of data is present?

 

[Vicenarian]

I wonder what size drive you are trying to rescue, and how long the ddrescue process took? Ddrescue generally takes a long time to run, especially if it finds bad sectors. You mentioned 6hrs. My sessions with ddrescue can sometimes take 20+ hours to complete on a damaged drive of any size. When you examine the contents of the new drive, does it appear that the appropriate amount of data is present?

The old drive is about 160 GB, but only has maybe 30GB of actual data. ddrescue took maybe 2 hours (6 hours was referring to my hands-on time, but the actual cloning/imaging/etc. I did with the various programs took a lot longer). I tried cloning to 2 different drives, a 1TB Western Digital, and a 250GB Hitachi (new). Same result on both. I didn't really do a thorough examination of the drives after cloning data onto them, but they were in the same range as far as size of data being stored.

What really sucks is that I had another customer needing a hard drive clone as well, but when I checked the mobo it had bulging caps, so I had to advise against it No money in that, but at least I was honest.

 

[smashedbotatos]

Boot up PartedMagic and give Clonezilla a shot at it.

 

[Vicenarian]

Boot up PartedMagic and give Clonezilla a shot at it.

I actually tried Clonezilla earlier, but got tons of IO errors

 

[smashedbotatos]

Oh no, that bad? Have you tried anything else like paragon or acronis?

The only I can think of you didn do was rebuild the has sectors from the log file. ddrescue is usually really good about this kind of stuff, but can be finicky and a pita to use.

 

[Karlin High]

I use ddrescue whenever a hard drive has any indication of impending failure, or if I'm doing a file un-delete job. Otherwise, Clonezilla goes first because it's faster and doesn't take up as much external drive space.

My most-common ddrescue backup commands:

fdisk -l /dev/sda > fdisk-l_sda.txt
ddrescue -R /dev/sda ./sda.dd ./logfile-sda.txt

I use the -R for "reverse," supposedly that's better. And it makes the byte count go down instead of up, which I like better for progress indication.

Only if the first pass doesn't work do I try additional passes. By default it already retries bad sectors multiple times on the first pass, while doing its split and trim operations. If you use the same log file for additional passes, it will skip everything that's been recovered already and focus only on the failing sectors

Another thing I've found is it's better to have an EXT file system on your backup drive than NTFS. For some reason (sparse writes or something, I have no idea what that is) with NTFS on the external drive, ddrescue sometimes-but-not-always will keep going slower and slower as the backup progresses, while keeping 1 CPU core maxed out.

Restoring a ddrescue image can be tricky. I would use something like this:

ddrescue -f ./sda.dd /dev/sda ./logfile-sda-restore.txt

After it restores, Windows may or may not boot if you're not restoring to an identical hard drive. There could be issues with IDE vs AHCI SATA settings. And sometimes I have to put in a Windows install CD (preferable Win 7) and run the Startup Repair tool.

 

[Mindfulness]

you can always combine 2 passes into a single command using the && operator

ddrescue -f -n /dev/hda /dev/hdb logfile && ddrescue -d -f -r3 /dev/hda /dev/hdb logfile

This has the advantage of using a preferred 2 pass method with the benefit of it working non stop with less intervention.

 

[HFultzjr]

Ok, I'm finally starting to get a grasp on ddrescue and how it and Linux in general works.

I've been using Bootmed Plus for a few times and it worked, except I now realize it uses dd_rescue not ddrescue which is more powerful and more options.

I've been following this tutorial on using UBCD, (Parted Magic) on a live cd.

Here is a brief tutorial in laymen's terms that finally broke the bubble and allowed me (a Linux Newbie), to understand a few things. Great reading for a newbie to get started.

http://www.myfixlog.com/fix.php?fid=21

Now, my question is this....how do I get the log file to save to the USB drive I'm recovering to?

Here is what I'm using.

ddrescue /dev/sda3 /media/sdb1/myimagename.img log.txt

The /dev/sda3/ being the C drive of the booted machine I'm recovering from.
The /media/sdb1/ being the mounted USB device I'm writing to.

The log.txt seems to be "storing" in Ram, probably because I'm using a Live CD.

I'm presuming I'm missing some parameters to get the log file saved to the USB drive.

Everything else is working great. I'm getting an image I can mount. I'm starting to use some other commands such as -n and -r....more to come.
I just want to get the log.txt saved to the USB drive where the image is stored.

For some reason, the above tutorial made my simple mind "click". Now that I look at it, it says the same things that have been stated in other threads.....only now it makes sense.

Maybe it was the pictures (LOL).

Anyhow, any help getting the log file stored to the USB drive using the scenario above would be appreciated.

I know......using a dedicated Linux machine would be the way to go...it's on my todo list.

Thanks,

 

[lcoughey]

Anyhow, any help getting the log file stored to the USB drive using the scenario above would be appreciated.

You cannot save the log file to the destination drive, unless you are making an image file and the destination drive has a formatted file system. You might be better off making a live linux USB thumb drive where you can save your log files there.

I know......using a dedicated Linux machine would be the way to go...it's on my todo list.

A full system seems to be overkill, unless you are running linux all the time. You could install it to a separate hard drive and simply switch boot drives when you need to boot from Linux. I have 4 or 5 drives with various linux flavours, just for that very purpose.

That being said, it is very rare that we use ddrescue around here.

 

[SilverLeaf]

Ok, I'm finally starting to get a grasp on ddrescue and how it and Linux in general works.

I've been using Bootmed Plus for a few times and it worked, except I now realize it uses dd_rescue not ddrescue which is more powerful and more options.

I've been following this tutorial on using UBCD, (Parted Magic) on a live cd.

Here is a brief tutorial in laymen's terms that finally broke the bubble and allowed me (a Linux Newbie), to understand a few things. Great reading for a newbie to get started.

http://www.myfixlog.com/fix.php?fid=21

Now, my question is this....how do I get the log file to save to the USB drive I'm recovering to?

Here is what I'm using.

ddrescue /dev/sda3 /media/sdb1/myimagename.img log.txt

The /dev/sda3/ being the C drive of the booted machine I'm recovering from.
The /media/sdb1/ being the mounted USB device I'm writing to.

The log.txt seems to be "storing" in Ram, probably because I'm using a Live CD.

I'm presuming I'm missing some parameters to get the log file saved to the USB drive.

Everything else is working great. I'm getting an image I can mount. I'm starting to use some other commands such as -n and -r....more to come.
I just want to get the log.txt saved to the USB drive where the image is stored.

For some reason, the above tutorial made my simple mind "click". Now that I look at it, it says the same things that have been stated in other threads.....only now it makes sense.

Maybe it was the pictures (LOL).

Anyhow, any help getting the log file stored to the USB drive using the scenario above would be appreciated.

I know......using a dedicated Linux machine would be the way to go...it's on my todo list.

Thanks,

You need to explicitly identify the full path to where you want to store the logfile. The command you used will store the logfile in the present working directory (RAM if using a live CD). Try this instead:

ddrescue /dev/sda3 /media/sdb1/myimagename.img /media/sdb1/log.txt

Edit: This works if saving as an image file. If doing a device to device clone, you would need a third drive (such as a USB stick) to save the logfile to.