I'm very glad to hear you were able to recover at least some of your data. I have no idea why the image was so badly corrupted. Someone may chime in and say, "Oh, you shouldn't be backing up a mounted filesystem with dd
", but even if that was
what you did it doesn't come close to accounting for the partition table, superblocks, LVM structure, etc. that were missing from your backup. Have you ever let memtest86
run overnight on that machine? I really looks like some sort of hardware problem bit you, but there are a lot of pieces in that chain.
As for avoiding this sort of problem in the future, all that comes to mind is, "Test your backup
." For a dd
image you might just do an md5sum
of the drive (assuming it was inactive) and checking that against the image, but if the error was in reading the source the sums might match, plus there is no way to distinguish a single bad bit from gross corruption. Mounting both the original drive and the image and doing a file-by-file comparison is the only sure way. Personally, I'd just be sure to keep the original drive around until I had successfully restored to the new one.
The calculations of where things were located is just basic CHS to LBA translation with a known geometry. The only hitch there is that you have to know that sector numbers start from 1, not 0, so the formula is just
(((cyl * heads_per_cyl) + head) * sectors_per_track) + (sector - 1)
Multiply the result by the sector size (512 in your case) to convert from LBA to byte offset.
As for cleaning up the superblock problems, that was just a matter of letting fsck
do its thing and paying attention to the messages. In that last case, it was apparent that fsck
was giving up when it was told not to clear the bad journal, and the solution to that was obvious. Remember, though, that using the "-y" option with fsck
is basically applying a BFH (Big F... Hammer) to beat the filesystem back into shape, often at the expense of some of the file content, and doing that prematurely can cause a lot more damage than it fixes.