DDRescue - Dead Drive Saver

Started by Melbosa, May 14, 2012, 08:36:23 AM

Previous topic - Next topic

Melbosa

So with Thorin's success with this one a while back, thought I would post a sticky so we can all remember it: http://forums.righteouswrath.com/index.php/topic,7744.0.html

LiveCD Distros:

Instructional Uses:

Legend:
XXX = name of the complete source disk (NOT the partition.)
YYY = name of the complete target disk (NOT the partition.)
ZZZ = name of the mount point of a disk or a USB key to contain the file 'log' activities ddrescue (not required for dd).

AAAA = 4-digit year.
MM = month on two day.
JJ = 2 digit day.
HH = Hour.
MM = Minutes.

The option -B is to force the expression of numbers using powers binary (1024 instead of 1000 for Kbytes, etc ...)
The -v option is to force ddrescue to be "wordy"(we know about what happens) - verbose
The -n parameter does not stress when encountering a bad sector - log and skip bad sector

1 - To recover quickly:
ddrescue -B -v -n /dev/XXX /dev/YYY /ZZZ/ddrescue_logfile_AAAA-MM-JJ-HHMM.log

2 - Do another pass to try to recover the non-read the first pass. Needless course in the absence of bad sectors:
ddrescue -B -v -c 16 -r 2  /dev/XXX /dev/YYY /ZZZ/ddrescue_logfile_AAAA-MM-JJ-HHMM.log
Be careful to indicate the same .log file, since it is from there that will identify areas to recover. 16 sectors are treated at once (c-16) and retries is 2 (-r 2).

3 - If needed redo a third passage:
ddrescue -B -v -c 1 -r 5 /dev/XXX /dev/YYY /ZZZ/ddrescue_logfile_AAAA-MM-JJ-HHMM.log
This time, it does only one sector at a time (-c 1) and the emphasis is heavily (5 retries: r-5).


If you used any other combinations of the above, post them here.
Sometimes I Think Before I Type... Sometimes!

Thorin

I hope this doesn't mean that you have a sick computer?

Also, LEAVE IT RUNNING, even if it doesn't seem to be doing anything.  My disk recovery took three weeks with a bad controller board, but _eventually_ every single sector was spared (yay!).  Also, you can go from a smaller to a larger disk but not the other way around.
Prayin' for a 20!

gcc thorin.c -pedantic -o Thorin
compile successful

Melbosa

Quote from: Thorin on May 14, 2012, 08:52:01 AM
Also, you can go from a smaller to a larger disk but not the other way around.

Hmmm cause it does a complete sector by sector, block by block move?  Or are you talking just data size?
Sometimes I Think Before I Type... Sometimes!

Lazybones

Quote from: Melbosa on May 14, 2012, 08:58:19 AM
Quote from: Thorin on May 14, 2012, 08:52:01 AM
Also, you can go from a smaller to a larger disk but not the other way around.

Hmmm cause it does a complete sector by sector, block by block move?  Or are you talking just data size?

Correct, when you are doing sector copies everything has to line up or the filesystem will not make any sense... Some commercial packages have an extra step that allows shrinking partitions on SOME file systems by remapping everything but it isn't a common feature. Small to large is the general rule.

Melbosa

Yeah I figured as much.  Well I'm hoping the one I have to run this on has the spare space at the end of the drive, and I don't have a larger or equivalent drive handy.  Good news is that this was freshly imaged from an HP restore, so I hope it really is only all at the beginning of the drive.
Sometimes I Think Before I Type... Sometimes!

Tom

ddrescue/dd_rescue is quite nice. I also like using Clonezilla, in particular partclone and partimage (ntfsclone is good too). The nice thing about part* is that it'll make a compressed clone of your filesystem (not a block by block image) over the network as well as to local disks.
<Zapata Prime> I smell Stanley... And he smells good!!!

Thorin

Quote from: Melbosa on May 14, 2012, 09:09:01 AM
Yeah I figured as much.  Well I'm hoping the one I have to run this on has the spare space at the end of the drive, and I don't have a larger or equivalent drive handy.  Good news is that this was freshly imaged from an HP restore, so I hope it really is only all at the beginning of the drive.

I suggest you go buy an equivalent or larger drive.  I have no idea what ddrescue will do with less space, but I doubt that it will selectively remove blocks or sectors, as those _might_ contain data.
Prayin' for a 20!

gcc thorin.c -pedantic -o Thorin
compile successful

Melbosa

Yeah the data is already safe... so I can play.
Sometimes I Think Before I Type... Sometimes!

Lazybones

Quote from: Thorin on May 14, 2012, 10:03:54 AM
Quote from: Melbosa on May 14, 2012, 09:09:01 AM
Yeah I figured as much.  Well I'm hoping the one I have to run this on has the spare space at the end of the drive, and I don't have a larger or equivalent drive handy.  Good news is that this was freshly imaged from an HP restore, so I hope it really is only all at the beginning of the drive.

I suggest you go buy an equivalent or larger drive.  I have no idea what ddrescue will do with less space, but I doubt that it will selectively remove blocks or sectors, as those _might_ contain data.

The point is you CAN'T selectively remove stuff without knowledge of the filesystem, removing even blank space at the end wrecks the consistency of the volume.. That is the catch with block level copy, it basically works with ANY filesystem but it has to be an exact copy or your volume will not boot or will be corrupt.

Melbosa

Ahh yes, unless you remap the volume partitions ;), and fix up the MBR.  I will try and let you guys know how it goes. I really don't have another drive to try this with and the client won't spend any more money on the system.  Again I don't need this thing to boot into a working OS... just need that damn HP Image partition to come across, which will be at the beginning of the drive (accroding to my HP tech reps through work anyway).
Sometimes I Think Before I Type... Sometimes!

Thorin

Prayin' for a 20!

gcc thorin.c -pedantic -o Thorin
compile successful

Melbosa

Going from a 500GB to a 300GB, with only 35GBs of data *including the HP Image stuff at 13GB.
Sometimes I Think Before I Type... Sometimes!

Tom

Better hope NTFS didn't decide to store anything important near the middle-end or end of the disk. I've seen NTFS put parts of the MTF and other housekeeping stuff near the end or middle-end of the disk.
<Zapata Prime> I smell Stanley... And he smells good!!!

Mr. Analog

For 35 GB of data I'm pretty sure aberrance will be small, if any.
By Grabthar's Hammer

Melbosa

True but those things are rebuildable with the tools out there.  Again I'll let you guys know how I make out.  I have little choice at this point.
Sometimes I Think Before I Type... Sometimes!

Lazybones

Quote from: Tom on May 14, 2012, 11:51:15 AM
Better hope NTFS didn't decide to store anything important near the middle-end or end of the disk. I've seen NTFS put parts of the MTF and other housekeeping stuff near the end or middle-end of the disk.

NTFS stores a backup of the MTF and some meta data in the middle for redundancy and recovery reasons.. to my knowledge it is not possible to shrink a NTFS volume smaller than the location of this data.

Melbosa

Quote from: Lazybones on May 14, 2012, 12:12:08 PM
Quote from: Tom on May 14, 2012, 11:51:15 AM
Better hope NTFS didn't decide to store anything important near the middle-end or end of the disk. I've seen NTFS put parts of the MTF and other housekeeping stuff near the end or middle-end of the disk.

NTFS stores a backup of the MTF and some meta data in the middle for redundancy and recovery reasons.. to my knowledge it is not possible to shrink a NTFS volume smaller than the location of this data.

While to this process that may be correct, but in doing just a simply image over from one disk to another, I have successfully shrunk the partition size down to 10% of the data size.  The particular one I can think of was from a 1TB to a 160GB HD, and the resulting partition was able to shrink to 86GB, where the original was 680GB.  This was using Symantec Ghost 11.5.
Sometimes I Think Before I Type... Sometimes!

Tom

Quote from: Melbosa on May 14, 2012, 01:23:49 PM
Quote from: Lazybones on May 14, 2012, 12:12:08 PM
Quote from: Tom on May 14, 2012, 11:51:15 AM
Better hope NTFS didn't decide to store anything important near the middle-end or end of the disk. I've seen NTFS put parts of the MTF and other housekeeping stuff near the end or middle-end of the disk.

NTFS stores a backup of the MTF and some meta data in the middle for redundancy and recovery reasons.. to my knowledge it is not possible to shrink a NTFS volume smaller than the location of this data.

While to this process that may be correct, but in doing just a simply image over from one disk to another, I have successfully shrunk the partition size down to 10% of the data size.  The particular one I can think of was from a 1TB to a 160GB HD, and the resulting partition was able to shrink to 86GB, where the original was 680GB.  This was using Symantec Ghost 11.5.
If the tool is able to move all that, it should work fine. But ddrescue isn't that tool ;)
<Zapata Prime> I smell Stanley... And he smells good!!!

Lazybones

Quote from: Tom on May 14, 2012, 01:25:26 PM
Quote from: Melbosa on May 14, 2012, 01:23:49 PM
NTFS stores a backup of the MTF and some meta data in the middle for redundancy and recovery reasons.. to my knowledge it is not possible to shrink a NTFS volume smaller than the location of this data.

While to this process that may be correct, but in doing just a simply image over from one disk to another, I have successfully shrunk the partition size down to 10% of the data size.  The particular one I can think of was from a 1TB to a 160GB HD, and the resulting partition was able to shrink to 86GB, where the original was 680GB.  This was using Symantec Ghost 11.5.
If the tool is able to move all that, it should work fine. But ddrescue isn't that tool ;)
[/quote]

Ghost is filesystem aware, it can do that trick with SOME filesystems but it is limited by how new the version of Ghost is...

Tom

#19
Quote
Quote from: Lazybones on May 14, 2012, 01:32:21 PM
Quote from: Tom on May 14, 2012, 01:25:26 PM
Quote from: Melbosa on May 14, 2012, 01:23:49 PM
NTFS stores a backup of the MTF and some meta data in the middle for redundancy and recovery reasons.. to my knowledge it is not possible to shrink a NTFS volume smaller than the location of this data.

While to this process that may be correct, but in doing just a simply image over from one disk to another, I have successfully shrunk the partition size down to 10% of the data size.  The particular one I can think of was from a 1TB to a 160GB HD, and the resulting partition was able to shrink to 86GB, where the original was 680GB.  This was using Symantec Ghost 11.5.
If the tool is able to move all that, it should work fine. But ddrescue isn't that tool ;)

Ghost is filesystem aware, it can do that trick with SOME filesystems but it is limited by how new the version of Ghost is...
Yeah, just like partimage and parted.
<Zapata Prime> I smell Stanley... And he smells good!!!

Thorin

Gah!  Broke Quotes!  Bro'Quotes!

Good luck, Mel :)
Prayin' for a 20!

gcc thorin.c -pedantic -o Thorin
compile successful

Thorin

Just gonna say, there's dd, and then there's dd_rescue which is the ddrescue package in Ubuntu, and then there's ddrescue which is the gddrescue package in Ubuntu.  Like so: https://askubuntu.com/a/211579
Prayin' for a 20!

gcc thorin.c -pedantic -o Thorin
compile successful