Your first comment is not entirely true, but everything was well written in that url. I have stages 1, 1,5 and 2. Let me explain story, about my latest harddrive crash.
I have Debian Linux system, which is actually my moms computer and I haven't backed it up since there is nothing important to loose. Few weeks ago, I updated the deb-packages with normal aptitude update && aptitude safe-upgrade.
Suddenly I noticed that there was some strange language xml which run fast and soon I got errors with some of the debs and I found out that fs (ext3) was corrupted. I took md5sum of the deb's in cache, and found out that there are about 10 different md5sum compared to my stable computer. I redownloaded the broken packages, and installed those again. Everything was fine. After that I restarted computer to single user mode and marked badblocks with "fsck -c" For me it is still mystery, why installer installed those packages, even their md5sum did not match.
a) 40 GB original
b) 40 GB
c) 20 GB
d) 6 GB
e) 6 GB
Now after couple of weeks I took 4 old + (original 40GB) harddisks, from size 6GB to 40GB. First I put 40GB (b) harddisk to my computer and noticed with smartctl that it also had bad blocks.
I saved data from original broken 40GB harddisk to 6GB harddisk, and tried to restore it to 20GB harddisk. When I was restoring, fsarchiver complained about broken file (checksums works!) and I noticed that third (6GB) (d) harddisk was also broken. This time I didn't get any hardware errors.
Then I took the original harddisk and 6GB (e) harddisk again and saved the data there. Restarted the computer with new harddisk. Everything worked fine, but just to make sure I restarted it again to singleuser mode and run "e2fsck -c". Again I found bad blocks. Harddisk (c) 20GB was also broken, even it was booting.
Since I had correct data in working disk (e), I made new image from original hd to empty space of broken 20GB hd (c). After this I checked md5sums and everything was matching. Good enough! I restored data successfully from broken 20GB hd, where images were correctly written to 6Gb (e).
After I restarted, I noticed that cfdisk didn't liked my partitiontable. Original partitiontable was probably corrupted since hdx2 partition was ending after end of disk. There might be also some problems with CHS, because my target disk was actually a lot smaller than original.
First I used dd to copy 63 first blocks from original disk to set grub stage2. Then I used sfdisk to dump partitiontable and edited the sfdisk dump-file by hand just to copy first partition (/boot). I added the other partitions with cfdisk, restored the dumps with fsarchiver and after that it booted fine and cfdisk was also happy about partitiontable.
a) 40 GB, boots to os but has bad blocks (which are marked as badblocks in fs)
b) 40 GB, broken
c) 20 GB, boots to os, but has bad blocks ( all are not marked as badblocks in fs)
d) 6 GB, broken
e) 6 GB working and in use now!
System works and boots because
1) I copied 63 sectors which contains the grub stages 1 and 1,5
2) my /boot is in same partition but physical place on disk of stage 2 might be in different place
3) my / is still in hda6/sda6, where it was before. No need to modify menu.lst.
There was no need to reinstall grub!
1) deb-packages have some checksums, but they were still installed even if they were broken, why? (not actually fsarchiver -question)
2) after final restoring I did run e2fsck -c again in singleuser and e2fsck did some modifications to disk. However I am not able to see any badblocks anymore. Does this mean that fsarchiver also saves the badblock-information with filesystem and by running e2fsck -c I "released" those blocks again?