help please

BrianK · 07-03-2006, 06:03 PM

lesson learned: don't do system admin when you're really tired. :P

I fsck'd a disk that was mounted & seriously fouled it up by doing so. (I suppose it could have gone bad on it's own... there was a reason I was fsck'ing).

In any event, I've since booted the machine off CD & run fsck, but now I get:

# fsck.ext3 /dev/hda3
e2fsck 1.38 (30-Jun-2005)
Couldn't find ext2 superblock, trying backup blocks...
Superblock has an invalid ext3 journal (inode 8).
Clear<y>?

If at all possible, I need to get some data (lots of data, actually) off of this disk. If I "Clear" like it's asking me, is there any chance of recovering any data? This machine is pretty critical - it's the system drive on my NIS/queue manager/software license server. It *was* running an old copy of RH9 - pretty much out of the box - no updates, 2.4 kernel, etc.

Any ideas?

unSpawn · 07-03-2006, 08:42 PM

AFAIK deleting the journal only means the system won't have been updated since the last journal commit. The first thing I would do is make sure to never mount the drive in write mode but read-only and make a dd copy just in case.

If you think you can get away with copying off data just try it I'd say. If it bombs out then you could run fsck with the "check only" option which should give you a clue how large the damage is. If it spits out a list of inodes then you can query what file is attached using "debugfs -c /dev/hda3; ncheck inode_number" to determine if repair is worth it or necessary. If you have a lot of inodes to check, get them in a list and run like
for inode in $list; do /sbin/debugfs -R "ncheck ${i}" -c /dev/hda3; done

BrianK · 07-11-2006, 08:20 PM

Quote:

Originally Posted by unSpawn

AFAIK deleting the journal only means the system won't have been updated since the last journal commit. The first thing I would do is make sure to never mount the drive in write mode but read-only and make a dd copy just in case.

If you think you can get away with copying off data just try it I'd say. If it bombs out then you could run fsck with the "check only" option which should give you a clue how large the damage is. If it spits out a list of inodes then you can query what file is attached using "debugfs -c /dev/hda3; ncheck inode_number" to determine if repair is worth it or necessary. If you have a lot of inodes to check, get them in a list and run like
for inode in $list; do /sbin/debugfs -R "ncheck ${i}" -c /dev/hda3; done

very good info.

for future reference, if anyone comes across this thread...

I dd'd the whole disk over to a larger disk (just because I had one lying around). Then ran fsck & answered yes to *everything* - took quite a while.

The root of the driectory structure was lost, so nothing was where it was supposed to be, but whole chunks of data were able to be recovered once found in the newly created "lost+found" directory... things like /var were in lost+found, but had been renamed to something like #163487... but inside there was a completly intact www/html - which is really what I was after. Have to learn to put php code into cvs. :P