Recovering Trashed Filesystems

[Polytropon]

On Thu, 30 Jul 2009 23:46:50 -0700, "Crist J. Clark" <cristclark at comcast.net> wrote:
> But if I try look at the files (directories),
> 
>   # ls -l
>   ls: lib: Bad file descriptor
>   ls: usr: Bad file descriptor
>   ls: var: Bad file descriptor

Same here - allthough on a much more important place - my former
home directory.



> We see "usr" is messed up. And what I'd like to recover are
> files up in usr/local/etc.
> 
> Now I can "mount -r /dev/ad0s1a /mnt" to get the above results,
> but "fsck /dev/ad0s1a" returns,
> 
>   # fsck /dev/ad0s1a
>   ** /dev/ad0s1a
>   BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE
> 
>   LOOK FOR ALTERNATE SUPERBLOCKS? [yn] y
> 
>   32 is not a file system superblock
>   SEARCH FOR ALTERNATE SUPER-BLOCK FAILED. YOU MUST USE THE
>   -b OPTION TO FSCK TO SPECIFY THE LOCATION OF AN ALTERNATE
>   SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; SEE fsck(8).

You could try do locate superblocks using this command:



> Some help on recovering the files?

Yes, use your backup. :-)

Don't mind, I (still) am in a similar situation, so I won't poke
any more fun at you.

Before you do anything else: Make a 1:1 copy using dd of your
file systems. Boot from a live CD and have access to another
hard disk. Then do:

	# dd if=/dev/ad0s1a of=/rescuedisk/ad0s1a.dd bs=1m
	# dd if=/dev/ad0s1d of=/rescuedisk/ad0s1d.dd bs=1m
	# dd if=/dev/ad0s1e of=/rescuedisk/ad0s1e.dd bs=1m
	# dd if=/dev/ad0s1f of=/rescuedisk/ad0s1f.dd bs=1m
	# dd if=/dev/ad0s1g of=/rescuedisk/ad0s1g.dd bs=1m

This is to make sure that any further fsck run won't mess up
the file system. Use the dd images for retrieval. Change the
device names to the correct names. Maybe when you're running
fsck -yf on a device, it can do more damage...

Install the port ffs2recov and use its -s and -p options. Refer
to the excellent manpage.



> I don't need the whole
> disk intact. As I said, I just want to track down some local
> stuff in usr/local/etc.

There is always the option of doing a low-level recovery. Install
The Sleuth Kit from ports and try. In most cases, you will lose
the file names, but with a quick search, you could easily identify
the files from /usr/local/etc that you want to have back. But that
would be my last choice.



> As for the second file system, the "var" file system, it is
> more messed up. Looks like big chucks are zeroed out. But
> again, there are a few files I would like to recover. I
> have managed to recover one important one by running,
> 
>   # dd if=/dev/ad0s1f | hexdump -C | more
> 
> And manually finding the file and then using,
> 
>   # dd if=/dev/ad0s1f skip=<m> count=<n> > /tmp/recovered.txt
> 
> Then manually editing. But that is too labor intensive to try
> to grab everything.

You should really try ffs2recov, allthough your "manual approach" is
already a good means.



> Again, when I fsck(1) I get the same message as above. Anyone
> have tools for recovering files from these broken file systems?

Here's a short list I made up, maybe something gives you another
point where to start:

System:
	dd
	fsck_ffs
	clri
	fsdb (!!!)
	fetch -rR <device>
	recoverdisk (!)

Ports:
	ddrescue
	dd_rescue
	ffs2recov
	magicrescue
	testdisk
	The Sleuth Kit:
		fls
		dls
		ils
		autopsy
	scan_ffs
	recoverjpeg
	foremost
	photorec

Finally, may I ask if you have any ideas about what caused this problem?


Good luck!



-- 
Polytropon
>From Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...