Shell Programming and Scripting

As already explained, dd_rescue doesn't care at all about filesystems, it makes a raw bit-for-bit copy. This is the entire point of using it, because it will not seize up and start foaming at the mouth when the filesystem isn't completely valid. You can copy filesystems from any OS. So if there's actual bad sectors onthe drive, you can use dd_rescue to copy it from the bad driveto the good then commence data recovery on the new drive.

Code:

ddrescue inputdevice outputdevice

Try fdisk -l to see which device is which.

Alright thanks, I will try in a few minutes. I assume I want a log file.

What kinds of things should I do to check the new disk after I make the data dump?

LMHmedchem

No point keeping one unless you have something to save it on. You can't save it on the old disk, you can't save it on the new disk, what exactly would you save it on?

Look at the value of errxfer during/after transfer. If it's ANYTHING but zero, there were bad sectors on the source disk during transfer. Depends what it is and what's on it. My expertise is with UNIX systems, not Windows ones. chkdsk may be able to successfully run on the new drive if it couldn't on the old one. Of course, my advice would be to hook it to a system which can mount the parittion and then just recover your data before you get too carried away...

I wrote the logfile to /home/ubuntu/desktop/logfile. Since I am running ubuntu off of a flash drive, I presume that is a writeable location, otherwise it is in memory, but the file does appear on the desktop.

So far it has recorded 24 errors. I guess it is unclear to me what the data on the new disk will look like when there were errors and how I would find files that are now unreadable, etc.

Once the ddrescue is finished, I can hook up an external drive and copy the data from inside ubuntu. Will it be ok to just use cp, or should I use some other method to move the data to the external drive? What will cp do if it runs into corrupt files.

Once I have made a backup of the new drive, I will boot windows on the new computer and see what it makes of the drive. If it is fine, or if checkdisk runs and completes, I will put the drive back into the original computer and see if there are still issues or if the problems have resolved.

LMHmedchem

The ddrescue run is finished, I have attached the log file if anyone is interested.

This is the summary,

Code:

Summary for /dev/sda -> /dev/sdc:
dd_rescue: (info): ipos: 976762560.0k, opos: 976762560.0k, xferd: 976762560.0k
                   errs:     24, errxfer:        12.0k, succxfer: 976762560.0k
             +curr.rate:     3064kB/s, avg.rate:    37374kB/s, avg.load: 10.9%

I'm going to copy the data from the new drive to an external backup drive now and see how that goes. Is there anything I can do to check the new drive to look for files that are incomplete or damaged?

LMHmedchem

I'm running cp -Rfp (in Ubuntu) to copy the data from the new drive to an external backup drive.

There is one error,
cp: cannot access `Data_Old/Data_Applications/seamonkey2_profiles/yahoo/newstuf/Cache.Trash/Trash/Cache': Input/output error

I presume this means that the file in that path is corrupted. What can I do to get rid of that bad file entry? That is not a file that I need, if it was, I would go to my third backup and get a good copy of it.

LMHmedchem

Good. The drive had bad sectors and needed replacing, then -- and extremely few sectors were actually bad. That's fairly decent odds that next to none of them landed on anything important -- though that's just down to luck. Well, copy them and see.

It's possible a block of zeroes might have landed right in the middle of a file of course. How to check for that depends on how you'd normally verify your data.

Also possible is the filesystem structure itself being disrupted.

---------- Post updated at 12:13 PM ---------- Previous update was at 12:10 PM ----------

No, it means the filesystem is corrupted. A bad file would just have chunks of zeroes inside it. There's no magic combination of zeroes and ones inside a file which causes it to be unable to be read.

Probably something in the filesystem metadata got filled with a chunk of zeroes when it couldn't be read. But now, instead of retrying and retrying for minutes at a time until it gives up on a bad sector, it's actually a good sector filled with nulls where the filesystem was expecting directory entries or inodes or something. So it gives up instantly. Depending on what the partition is and how badly its damaged, fsck, chkdsk, or reformat. Same as any other partition.