On Tue, 10 May 2011, Ashley M. Kirchner wrote: > On 5/10/2011 2:00 PM, Ljubomir Ljubojevic wrote: > >> I will byte and actually say it: Use Backups for important data you can >> not afford to lose. rsync or similar tool can be used via cron to make >> sure important files are saved. > > And this is normally done, except I was in the middle of working on > something when I needed to reboot for non-related reasons. So for the > most part I have a backup, but it's about 24 hours behind where I was. > That's 24 hours I don't necessarily want to lose. If you finished your dd_rescue/ddrescue copy, you may want to look into the testdisk utility to see if somehow the partition-table was not tampered with. testdisk can provide you with different layouts based on filesystem patterns. And it also saves the original layout so you can restore that as well. Also beware that a complete image includes the partition table, and loop-back mounting by default expects the filesystem image. So you may have to provide also an offset= option to tell mount where to look for the actual filesystem on the image ! If the files on the disk are a common format and the filesystem for some reason is nuked, photorec might help recover data from the disk. But beware, it may be very time-consuming to restore whatever photorec thinks it can identify. For simple digital camera media this works much better than a full disk with eg. operating system. Before trying an fsck on a backup copy, first try an fsck -n and see if the output is only minimal or not. Possibly try with different superblocks as well. You don't want to have to make another copy just because the filesystem is so broken, it can never be restored using fsck. Good luck, and provide feedback, we might learn a trick or two :) -- -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- dagit linux solutions, info at dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]