Reviews:
 ·Speakeasy
 ·Comcast Workplace
| Copy Files Ignoring Errors At work we have an old Red Hat computer with a dying SCSI drive. I have a new drive and will need to copy all the files off of the old one.
Since the old drive is dying and I might only get one chance at this. What is the best command to use to do the file copy?
I figure that I need something that will ignore errors and maybe list out what files were ignored.
Anyone have any tips?  |
|
| fsarchiver?
»www.fsarchiver.org/Main_Page
Why are you copying from the dying drive, instead of restoring from backups   |
|
Reviews:
·Speakeasy
·Comcast Workplace
1 edit | Backups? What backups? 
I was told it was the only place in the world that the files existed.
I'll try to get fsarchiver on the machine, but I'm also looking for ways to do it with standard commands like tar/rsync/cp, etc..
Thanks.
EDIT: Missed the part that fsarchiver is on a bootable CD. I will try that out if I can boot it. |
|
|
|
 No_StringsTSA fanPremium,Mod
join:2001-11-22
The OC
kudos:6
Wireless Networking
All Things Unix
Cox HSI
Efficient
Southwest Chat
| reply to steve1515
I use the tar command described in the following post. I've upgraded to larger drives several times using this method and always ended up with a fully functioning system when I was done.
»norton ghost in linux? |
|
| Tar is quite easy to use, it's how I create my disaster recovery images,
tar -X excludes -cvp . \
| xz -9 | nc -q 0 host
However, doesn't tar fail at unrecoverable read errors like the OP is anticipating? |
|
 SteveI know your IP addressConsultant
join:2001-03-10
Yorba Linda, CA
kudos:5 | reply to steve1515
I've done this a lot, and I'd never do it while the OS was running - that's just going to make it worse.
Instead, boot a Knoppix or other rescue CD, attach another drive (perhaps a USB-based one), and use dd to do a full copy from the bad one to a good one, asking it to ignore errors.
This is a long, painful process because the bad spots cause retries, and it could take days to get to the end of the drive.
I actually wrote a tool, badcopy, that does what dd does, but it keeps a small database of what it's already copied, and when it hits a bad spot it jumps ahead, hoping to skip a run of them. Rerunning the tool over and over it can keep trying those bad spots, occasionally getting more and more of them.
If you are comfortable booting a rescue CD and have another drive that's at least that large, I can help you with it - I've recovered really badly damaged drives that way.
Steve
--
Stephen J. Friedl | Unix Wizard | Microsoft Security MVP | Orange County, California USA | my web site |
|
No_StringsTSA fanPremium,Mod
join:2001-11-22
The OC
kudos:6 Host:
Wireless Networking
All Things Unix
Cox HSI
Efficient
Southwest Chat
| reply to disturbed1
said by disturbed1:However, doesn't tar fail at unrecoverable read errors like the OP is anticipating? Sorry, I missed that part. I'll go get some more coffee now. |
|
| Just ground some fresh Eight O'Clock myself |
|
Reviews:
·Speakeasy
·Comcast Workplace
| reply to Steve
said by Steve:I've done this a lot, and I'd never do it while the OS was running - that's just going to make it worse. Instead, boot a Knoppix or other rescue CD, attach another drive (perhaps a USB-based one), and use dd to do a full copy from the bad one to a good one, asking it to ignore errors. This is a long, painful process because the bad spots cause retries, and it could take days to get to the end of the drive. I actually wrote a tool, badcopy, that does what dd does, but it keeps a small database of what it's already copied, and when it hits a bad spot it jumps ahead, hoping to skip a run of them. Rerunning the tool over and over it can keep trying those bad spots, occasionally getting more and more of them. If you are comfortable booting a rescue CD and have another drive that's at least that large, I can help you with it - I've recovered really badly damaged drives that way. Steve I do have a new drive that I can copy to, and I think I'm ok with using Knoppix. The only think I'm not sure about is if I need to mount drives that are LVM.
Also, I'm not sure if I can have the machine down for days. I figured a file copy would only take a few hours. |
|
SteveI know your IP addressConsultant
join:2001-03-10
Yorba Linda, CA
kudos:5 | A copy of a good drive takes a few hours, but when you start counting bad-spot retries, it can take a very long time to get everything. At some point you have to make a tradeoff of how much data you get versus how long you're willing to wait for it.
The copy that I'm thinking about doesn't know anything about filesystems or Linux or ext3 or NTFS or anything like that - it's a raw drive copy.
But regarding "down for days", this may be decided for you by the hardware, not the boss.
--
Stephen J. Friedl | Unix Wizard | Microsoft Security MVP | Orange County, California USA | my web site |
|
Reviews:
·Speakeasy
·Comcast Workplace
| said by Steve:A copy of a good drive takes a few hours, but when you start counting bad-spot retries, it can take a very long time to get everything. At some point you have to make a tradeoff of how much data you get versus how long you're willing to wait for it. The copy that I'm thinking about doesn't know anything about filesystems or Linux or ext3 or NTFS or anything like that - it's a raw drive copy. But regarding "down for days", this may be decided for you by the hardware, not the boss. I did let them know that the drive could die while I make copy. That would definitely take them down for days. I'll let them know that the copy time could take a very long time before I start.
What are your thoughts on using ddrescue (»www.gnu.org/software/ddrescue/ddrescue.html) for cloning the drive?
That tool sounds similar to your tool you described. |
|
SteveI know your IP addressConsultant
join:2001-03-10
Yorba Linda, CA
kudos:5 | 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 |
|
Reviews:
·Speakeasy
·Comcast Workplace
| 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 |
|
Reviews:
·Speakeasy
·Comcast Workplace
| 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
 ·Cox VOIP
·Cox HSI
| 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 |
|
