 SteveI know your IP addressConsultant
join:2001-03-10
Yorba Linda, CA
kudos:5 | reply to steve1515
Re: Copy Files Ignoring Errors I haven't used ddrescue, but it sure looks promising (and is likely to be way more full-featured than my hack). |
|
 bgrundy
join:2002-01-25
Sykesville, MD
1 edit | As already mentioned, I would strongly suggest something like ddrescue, although as with any bad drive, YMMV. It can take a looong time depending on the types and causes of the errors.
FWIW, I cover ddrescue usage and related issues on page 113 of the LinuxLEO forensic guide.
--
"If you continue to use Windows, your system may become unstable" --BSOD |
|
 jdongEat A Beaver, Save A Tree.Premium
join:2002-07-09
Rochester, MI
kudos:1 | reply to Steve
said by Steve:I haven't used ddrescue, but it sure looks promising (and is likely to be way more full-featured than my hack). Another vote for GNU ddrescue and/or its competing and similar dd_rescue friend... I've successfully used them to salvage failing hard disk contents, and even once for pulling some data off a scratched CD-R.
Also, in a case like this, I recommend doing a ddrescue ASAP and not screwing around with the drive with any other toys -- there's a chance the drive might die completely at any moment 
--
Ubuntu MOTU Developer and Forums Council |
|
|
|
| said by jdong:said by Steve:I haven't used ddrescue, but it sure looks promising (and is likely to be way more full-featured than my hack). Another vote for GNU ddrescue and/or its competing and similar dd_rescue friend... I've successfully used them to salvage failing hard disk contents, and even once for pulling some data off a scratched CD-R. Also, in a case like this, I recommend doing a ddrescue ASAP and not screwing around with the drive with any other toys -- there's a chance the drive might die completely at any moment I'm scheduled to make my rescue attempt tomorrow at 10am. I'll let everyone know how it goes.
One thing though...how does ddrescue handle drive geometries? Is that stuff handled automatically? |
|
bgrundy
join:2002-01-25
Sykesville, MD | said by steve1515:One thing though...how does ddrescue handle drive geometries? Is that stuff handled automatically? I would suggest you use ddrescue to write an image (logical file) rather than to a physical device. Geometry should not be an issue.
Unless I'm misunderstanding your question...
--
"If you continue to use Windows, your system may become unstable" --BSOD |
|
| said by bgrundy:said by steve1515:One thing though...how does ddrescue handle drive geometries? Is that stuff handled automatically? I would suggest you use ddrescue to write an image (logical file) rather than to a physical device. Geometry should not be an issue. Unless I'm misunderstanding your question... Why not just go from /dev/sda to /dev/sdb? Why go though the file? |
|
 KakalakyPremium
join:2003-04-04
Broken Arrow, OK
kudos:1 | reply to steve1515
said by steve1515:One thing though...how does ddrescue handle drive geometries? Is that stuff handled automatically? You shouldn't have to worry about geometry unless you use --direct or read from a raw device. If you do use either of those methods all you need to do is use --block-size . |
|
bgrundy
join:2002-01-25
Sykesville, MD | reply to steve1515
said by steve1515:Why not just go from /dev/sda to /dev/sdb? Why go though the file? Good question...My perspective on data recovery is from a forensic standpoint. Preservation of the original is of the utmost importance. Unless you are booting to a virtual environment with something like liveview, you make an image file, back it up, and work from that.
From YOUR perspective, I would say that it's best to use an image file rather than a physical disk because
a) a logical image can be more easily compressed, allowing you to keep an original copy AND work on a "working copy"...mess it up and you have the compressed image to fall back on. If you try this with a physical disk you are more likely to waste space, especially if your physical disk is larger than the original.
2) a number of recovery tools out there will expect to be used on a raw image. They will work on a physical device, but may not be able to recover to the same volume in many cases. If you are using a drive larger than the image, then you can write the logical file to that drive AND recover files to the same volume. (photorec comes to mind, if you find you will need to carve).
iii) if you use volume based recovery tools, you have to worry about residual data on a physical disk (at the end of the device, if it is larger). Using an image file sets specific boundrys. Of course this can be limited on a physical drive by setting the correct geometry (sector count, specifically), or by zeroing the drive beforehand, but why bother?
In short, there is no "real" reason for using an image. It's just more convenient and less wasteful.
--
"If you continue to use Windows, your system may become unstable" --BSOD |
|
SteveI know your IP addressConsultant
join:2001-03-10
Yorba Linda, CA
kudos:5 | said by bgrundy: My perspective on data recovery is from a forensic standpoint. My perspective on data recovery is on a get-as-much-data-as-you-can standpoint, so going from one drive to another is likely to be far faster, which effectively lets you scrape more data from the source drive because you're not waiting on the destination drive.
If the source drive is quite small, this matters less, but when dealing with errors, the ability to keep retrying while copying to target media, is a big win.
If you really need a copy, you can do another highspeed copy to yet another physical drive, but I've rarely needed this.
Just another perspective.
Steve
--
Stephen J. Friedl | Unix Wizard | Microsoft Security MVP | Orange County, California USA | my web site |
|
| Here's the plan...
Boot into a live CD like Parted Magic and use ddrescue to go from old drive to new drive.
They told me that the old drive has about 4GB of data. The new drive I have is 18GB in size.
After that's done they want a clone of the new drive to another new drive. I figure that I can just use the same method...like Steve said...it should be fast.
Hope it all works out!  |
|
bgrundy
join:2002-01-25
Sykesville, MD | reply to Steve
said by Steve:...so going from one drive to another is likely to be far faster How so? If you are dealing with bad media on the source drive, and using proper recovery tools, then the bottleneck is not going to be your destination at all. At what point would you have to "wait on the destination drive" if writing to a file vs. a physical disk? Are you talking about OS level block caching?
said by Steve:If the source drive is quite small, this matters less, but when dealing with errors, the ability to keep retrying while copying to target media, is a big win. How does that change by writing to a destination file rather than a physical drive? "Retrying" occurs at the source, not the destination.
(Hopefully my tone does not come across as argumentative. I'd like to get a grip on what you're talking about here. I've read some of your tech tips in the past, and they're very useful. I'm just not getting your point here.)
--
"If you continue to use Windows, your system may become unstable" --BSOD |
|
bgrundy
join:2002-01-25
Sykesville, MD | reply to steve1515
Good luck! Let us know how it goes...Recoveries can be a great learning experience. It will be interesting to see how many skipped blocks you end up with, and what your actual file recovery rate is afterwards.
Good Hunting!
--
"If you continue to use Windows, your system may become unstable" --BSOD |
|
