attempting fs recovery from image

B

blah44

I have a number of old disks that I made images off with dd before throwing out. Some of them were dying, but this proved to be a good strategy along with the freezer trick, and I have been able to recover nearly all of the data.

However I have one last straggler that I have not been able to read. With the other images, when I mdconfig(8) them, I get md1e etc alongside md1 in /dev. This one does not give me any additional device when mdconfig(8)'d, only the md1. Mount(8) and fsck(8) claim bad super blocks, which is not surprising as I am clearly not going thru through the partition/disklabel/whatever. I still have some images from physically identical drives that I thought I might be able to combine to make the image readable - I bet I partitioned them all the same way when setting up years ago. Also this last image is only half the size as I imagine the hardware crapped out midway thru through reading. So I tried "layering in" the corrupt image, using dd conv=notrunc, and I got an image of the right size but starting with the corrupt one, but that did not work. So I also tried copying the first 512 B, 1024 B, and 1024 KB from a known working image to the front of the corrupt one - still no luck. If I hexdump(1) the image I can clearly see plaintext data that I want, I just cannot seem to get the file system into shape enough to read any of it correctly.

Anyone have any other ideas or tricks I could try? Where exactly does the partition/disklabel information sit? Because I bet if I pull that from a working image, I would at least get a little farther. Also, and tools like fsck that I could use to say "try your best to make this into a file system again"? I am not looking for perfection, if it loses some data no big deal, I just want to mount and read what I can.
 
Anyone have any ideas? I still think I could pull partitioning information from another drive or image, lay it in to this one, and see what I get but I cannot figure out how.
 
What is on them, specifically? Did you back up the entire disk? Does it have MBR slices, FreeBSD partitions, Linux partitions? What kind of filesystems?

Part of the problem is that dd(1) is not a backup tool.

What does file -s /dev/md1e say?

To overlay partition tables from one disk onto another, use gpart(8)'s backup and restore to read one and overwrite the other. The restore will probably need -F to overwrite any existing partition information, and on an old-style disk with BSD slices inside an MBR, will have to be done for both the drive (ada0, say), and the slices on it (ada0s1, s2, and so on).
 
I realize that dd is not a backup tool, that was done to extract what I could from the physically failing disks after sticking them in a freezer. These are all UFS volumes, apparently some with disklabels and some splat down onto the raw device (if you know you will only ever want the one partition, is there any downside or problem with newfs right on the whole disk raw?)

So, progress! I dug around ports and found sleuthkit, and that seems to be exactly what I need. I have dug out a number of files of value and really like these tools.

Two current questions - 1. For most images I get mdXA entries after mdconfig, which is what I would expect. However for one I only get mdX, no lettered partitions, BUT if I write the image back to another physical disk the adaXA DO show up. Is that a bug or is something strange afoot?

2. When viewing my image or the resulting device, I can fairly easily hexdump / strings through it and find remnants of files I would like to extract. Is there any way to “work backwards” from the image/device location to find which file name or inode I am looking at?

Thanks!
 
1. It would depend on what the image contains. If you don't erase old bsdlabel(8) information on a disk, it will reappear when a new MBR is written. The old label information is right where expected according to the MBR.

2. Probably. It would depend on knowing the UFS structure.
 
You must log in or register to reply here.
Back
Top