On Thu, 30 Jul 2009 23:46:50 -0700, "Crist J. Clark" <cristcl...@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, ...
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
