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