Suspend2 Filesystem disaster -or how much should I trust dd?

[otakuj462]

Hi all, I need some advice. I was trying to get Suspend 2 working today, and made the grave, newbish error of running a suspen-aware kernel, then running a non-suspend aware kernel, then running a suspend-aware kernel again. This inflicted damage on my filesystem, though I'm not certain how much, what the consequences of this will be, or what it even means to "damage" my filesystem. I found some information on this mistake here:http://suspend2.net/HOWTO-4.html.
Fortunately I used dd to backup my whole 37-gigabyte hda3 partition to an external hard drive. My question now is, how much can I trust dd?
This is the second time a backed up my whole hard drive to an external drive, and the last time, I noticed a strange error. Normally, after backing up, I can mount the external drive and explore it as a regular filesystem, but when I tried to explore inside of my backed up /etc directory, I received the error: Input/output error. This second time, I've run into the same problem. By running find * at the root of the filesystem and sending stderr into a file, I was able to see which specific files returned this I/O error. This created a substantial list (3.3 MB), which is too large to post. However, I can say that it referenced file in home, opt, usr, var, and root. Here's an example of what one looks like:

[troymc]

I can't help with the suspend issue, but after reading that page the filesystem corruption appears nasty.

But I think I can help with dd. dd is very trustworthy for what it does - copy blocks of data from one file to another. But it does no verification of the copied data, or integrity checking of the media, etc. As such, it is not really considered a backup tool. If you do use dd as a backup tool, always verify the integrity of the media first (ie, badblocks for a disk) and verify the backup afterwards (ie, md5sums for devices, fsck for filesystems).

I would recommend NOT attempting to restore from that backup - you'll just be swapping one corrupted filesystem for another.

Instead, if you need to recover from that backup, copy out individual files/directories that show no signs of corruption.



troymc