Re: Recovering Trashed Filesystems
On Fri, Jul 31, 2009 at 12:00:46PM +0200, Polytropon wrote: On Thu, 30 Jul 2009 23:46:50 -0700, Crist J. Clark cristcl...@comcast.net wrote: [snip] 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: Err... Hmmm. Seems to be something missing here? Install the port ffs2recov and use its -s and -p options. Refer to the excellent manpage. I got ffs2recov(1) and it would seem to be exactly what I need, but it's not working so well for me. I ran it with -s and it found some superblocks, superblock: 116113408(byte), 226784(block), cg: 116129792(byte), 226816(block), 10(nth), fs begin: 18446744073706014720(block), primary sb at: 18446744073706014848(block) superblock: 147439616(byte), 287968(block), cg: 147456000(byte), 288000(block), 2(nth), fs begin: 18446744073709086720(block), primary sb at: 18446744073709086848(block) superblock: 308805632(byte), 603136(block), cg: 308822016(byte), 603168(block), 11(nth), fs begin: 18446744073706014720(block), primary sb at: 18446744073706014848(block) superblock: 340131840(byte), 664320(block), cg: 340148224(byte), 664352(block), 3(nth), fs begin: 18446744073709086720(block), primary sb at: 18446744073709086848(block) ... But if I try to access that superblock as specified in the documentation, net5501# ffs2recov -o 226784 -p /dev/ad0s1f get_sblock: Bad magic (0) It doesn't work, but if I try it with bytes rather than blocks, net5501# ffs2recov -o 116113408 -p /dev/ad0s1f magic 19540119 (UFS2) timeFri Jun 27 20:36:13 2008 superblock location 65536 id [ 4865b1ad c24cb822 ] ncg 21 size1970116 blocks 1907915 ... That makes me nervous. Anyway, I don't seem to be getting very far. ffs2recov(1) would seem to be exactly the thing I need, but it's not finding any files. [snip] Finally, may I ask if you have any ideas about what caused this problem? Oh, yeah. The file systems reside on flash memory. I've been having issues with it for some time. It was bad enough that I couldn't get good dump(8)s of the file system for quite a while and running stuff like that made it more unstable. I did manual backups periodically of files that were more important, but of course, it failed right before I was due to make backups but after I had made a few changes earlier in the week. Once I recover all I can, I'll go spend another whopping $20 on a few gig of flash at Fry's. Right now, I'm net booting the sick little box in question. -- Crist J. Clark | cjcl...@alum.mit.edu ___ 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
Re: Recovering Trashed Filesystems
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
Re: Recovering Trashed Filesystems
On Thu, Jul 30, 2009 at 11:46:50PM -0700, Crist J. Clark wrote: I have two file systems in very sad shape that I would like to retrieve some files from. I've net booted the sick box and can access the two bad UFSs. One file system, the root file system, isn't too bad off. However, the usr directory is messed up. snip 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). Try 'fsck_ffs -b 160 /dev/ad0s1a' assuming you're using a UFS2 filesystem. If that doesn't work, try adding the '-D' flag, but heed the warning in fsck_ffs(8). Only run fsck_ffs when the filesystem is not mounted! If you can, make a copy of the damaged fs and save it to another disk or another machine. Then try to repair the copy. If it fails, you haven't lost your original data. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpodPbEc2Xdo.pgp Description: PGP signature
