Date: Fri, 31 Jul 2009 12:00:46 +0200 From: Polytropon <freebsd@edvax.de> To: cjclark@alum.mit.edu Cc: questions@freebsd.org, "Crist J. Clark" <cristclark@comcast.net> Subject: Re: Recovering Trashed Filesystems Message-ID: <20090731120046.82c135ca.freebsd@edvax.de> In-Reply-To: <20090731064650.GB93341@goku.i.pumpky.net> References: <20090731064650.GB93341@goku.i.pumpky.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 30 Jul 2009 23:46:50 -0700, "Crist J. Clark" <cristclark@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, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090731120046.82c135ca.freebsd>