Files with I/O Errors preventing access to full folders?

[varunendra]

2. You're image you have of 278GB is not complete, dd does not work well with bad sectors/faulty drives. You're missing about 40GB of data.
3. See post#10 again wrt GNU ddrescue....

Although I wouldn't consider an incomplete image necessarily a big problem IF the missing part was only bad blocks (they won't add any value anyway) or the end of the partition/drive (of course costing some files though), I would certainly +1 to GNU ddrescue after what I read about its imaging capabilities recently. In ubuntu repository, it is available as package gddrescue (sudo apt-get install gddrescue). I can't comment on the role or necessity of Lzip though, but it doesn't seem necessary (guessing by the fact that it would have been a dependency of the package otherwise).

However -

That's disappointing news considering that when i woke up, Photorec had worked its way past the weird sector. It's completed now with about 219,219 files. There's no harm in continuing to try, having the time.

That's sounds like a very good news to me, IF it doesn't encounter another problem block like that.

As far as I could gather, gddrescue seems to be only meant for imaging a disk/partition. You'll have to run data-recovery tools like photorec anyway to recover lost files. So, given that it has made progress now, I'd suggest to let it finish its current task or at least allow it to run as long as you can. You can do the file-check on the files it has recovered so far in the parallel while it is working. So that should help deciding whether they are worth letting it continue or not (some files may be incomplete/corrupt, some should be intact).

[SineSpe]

I would certainly +1 to GNU ddrescue after what I read about its imaging capabilities recently. In ubuntu repository, it is available as package gddrescue (sudo apt-get install gddrescue). I can't comment on the role or necessity of Lzip though, but it doesn't seem necessary (guessing by the fact that it would have been a dependency of the package otherwise).

As far as I could gather, gddrescue seems to be only meant for imaging a disk/partition. You'll have to run data-recovery tools like photorec anyway to recover lost files. So, given that it has made progress now, I'd suggest to let it finish its current task or at least allow it to run as long as you can.

It finished this morning with 219,219 files. I've have anti-virus software running and it caught a few viruses that Photorec resurrected.

In the meantime, I'll just do the sudo apt-get install gddrescue on my old computer that's booting from CD. After i install it, i'm guessing the command i'll have to use is..

 sudo ddrescue  /dev/sda3 /dev/hdb logfile

But i'm also worried about the warnings:
1. "IMPORTANT! Never try to rescue a r/w mounted partition. The resulting copy may be useless."
2. "IMPORTANT! If you use a device or a partition as destination, any data stored there will be overwritten."
3. "IMPORTANT! Never try to repair a file system on a drive with I/O errors; you will probably lose even more data."


1. How do i know if my partition is r/w or not?
2. Since i'll be using my external as my destination, i'll have to back up all the files Photorec recovered so that's not much of a problem.
3. I/O errors seem to be one of the most evident issues with my harddrive. Will i be okay with ddrescue as long as i don't attempt to "repair"? Is this why people may advise against repairing with chkdsk?

[mips]

1. The partition should not be mounted from what I recall.
2. Why are you specifying a partition instead of an image file?
3. Yes that makes sense.

As to how I know your drive is shot I looked at the Reallocated_Sector_Ct, Current_Pending_Sector, Offline_Uncorrectable values and that's more than enough to see that the drive is on it's way out.

[mips]

Although I wouldn't consider an incomplete image necessarily a big problem IF the missing part was only bad blocks (they won't add any value anyway) or the end of the partition/drive (of course costing some files though)...

I would agree but we are only speculating as to whether there is important data there or not. Thing is with dd it usually crpas out out when encountering bad sectors so if that's at the beginning of the 'bad' area and you have data there then you are going to lose out. Also 600 odd bad sectors does not equate to 40GB of data so there is definitely something amiss here.

[varunendra]

I would agree but we are only speculating as to whether there is important data there or not.
....Also 600 odd bad sectors does not equate to 40GB of data so there is definitely something amiss here.

I totally agree.

One thing I was wondering about (not that it makes it any less important), aren't you miscalculating the size? 320 GB declared by vendors is actually 298GB in binary (GiB) that computer sees. Since the image size is about 278 GiB as per OP (or 283 GiB as reported by PhotoRec in the screenshot in post #13), the difference is about 20 GiB, not 40.

Although it still is a lot of data, and a lot of room for possible further problems.


@ SineSpe,
To elaborate what mips said regarding point #2, your command be something like -

sudo ddrescue  /dev/sda3 /media/<backup path>/image2 logfile

where -

* /dev/sda3 is the partition you want to create image of (it should not be mounted)

* /media/<backup path>/image2 is the path and name of the 'image file' that you will be creating from the partition. All the mounted partitions (internal or an external hdd) are mounted in /media/ in Ubuntu, hence the /media/ part.

* logfile is what it says - the file that will keep log of the progress. Back it up before repeating operations, just in case..

[mips]

I totally agree.

One thing I was wondering about (not that it makes it any less important), aren't you miscalculating the size? 320 GB declared by vendors is actually 298GB in binary (GiB) that computer sees. Since the image size is about 278 GiB as per OP (or 283 GiB as reported by PhotoRec in the screenshot in post #13), the difference is about 20 GiB, not 40.

Yes that would be correct, I never converted the claimed size to actual size. 20GB is still a lot and way more than 600 bad sectors.

[SineSpe]

@ SineSpe,
To elaborate what mips said regarding point #2, your command be something like -

sudo ddrescue  /dev/sda3 /media/<backup path>/image2 logfile

where -

* /dev/sda3 is the partition you want to create image of (it should not be mounted)

* /media/<backup path>/image2 is the path and name of the 'image file' that you will be creating from the partition. All the mounted partitions (internal or an external hdd) are mounted in /media/ in Ubuntu, hence the /media/ part.

* logfile is what it says - the file that will keep log of the progress. Back it up before repeating operations, just in case..

Okay, so the backup path would just be the path to my external hard drive, correct? If i specify /media/<backup path>/image2 rather than /media/<backup path>, is it safe to say that the data on my external won't be overwritten? And how can i tell if my internal hard drive is unmounted?

[varunendra]

Okay, so the backup path would just be the path to my external hard drive, correct? If i specify /media/<backup path>/image2 rather than /media/<backup path>, is it safe to say that the data on my external won't be overwritten?

Yes, the backup image will be a file (image2) on the backup partition. For example, if the external drive is "/dev/sdb1" and is mounted as "/media/FreeAgentGo/", then the backup path can be - "/media/FreeAgentGo/image2". Or, if you want it in some folder named "BackupImage" (already existing, or you must create it beforehand) on the backup partition, then "/media/FreeAgentGo/BackupImage/Image2".

And how can i tell if my internal hard drive is unmounted?

Run the "mount" command.
It will show all the mounted filesystems. Make sure your source partition is not one of them. If it is, un-mount it from within nautilus (or whatever file manager you have), or with the command -

sudo umount /dev/sda3

..assuming that /dev/sda3 is the source partition which you have to create image of.

Being based on the "dd" command itself, I think ddrescue can be equally dangerous if used incorrectly. So feel free to ask here before executing it if you have any confusions.

[SineSpe]

Yes, the backup image will be a file (image2) on the backup partition. For example, if the external drive is "/dev/sdb1" and is mounted as "/media/FreeAgentGo/", then the backup path can be - "/media/FreeAgentGo/image2". Or, if you want it in some folder named "BackupImage" (already existing, or you must create it beforehand) on the backup partition, then "/media/FreeAgentGo/BackupImage/Image2".


Run the "mount" command.
It will show all the mounted filesystems. Make sure your source partition is not one of them. If it is, un-mount it from within nautilus (or whatever file manager you have), or with the command -

sudo umount /dev/sda3

..assuming that /dev/sda3 is the source partition which you have to create image of.

Being based on the "dd" command itself, I think ddrescue can be equally dangerous if used incorrectly. So feel free to ask here before executing it if you have any confusions.

So i suppose my full process will be to run mount; if dev/sda3 is listed, i'll run sudo umount /dev/sda3
I'll then install GNU ddrescue with sudo apt-get install gddrescue
I'll then run the program with sudo ddrescue /dev/sda3 /media/<backup path>/image2 logfile

I'll just have to determine the path of my external. What are the things ddrescue have done if used improperly?

[varunendra]

So i suppose my full process will be to run mount; if dev/sda3 is listed, i'll run sudo umount /dev/sda3
I'll then install GNU ddrescue with sudo apt-get install gddrescue
I'll then run the program with sudo ddrescue /dev/sda3 /media/<backup path>/image2 logfile

Looks perfect to me.

What are the things ddrescue have done if used improperly?

If you reverse the source and destination, and if the source (after reversing) is an existing image file or partition, the destination (your problem partition) will get overwritten without warning.

If the source is okay, but the destination is an existing file, it will get overwritten (not in the second or subsequent runs when the logfile has been created).

These are the only risks I can think of in the above mentioned process. But I have never used ddrescue myself so am just guessing.