Repairing a defective UFS 2 partition with fsck_ffs (or other means)

[Polytropon]

On Sun, 02 Nov 2008 08:13:28 -0800, Frank Mayhar <frank at exit.com> wrote:
> ffs2recov is a very low-level tool to recover files and data from a
> corrupted file system.  Among other things, it can search for
> directories, print contents of inodes, recover files by name and recover
> directory hierarchies given an inode and a name. 

This is something I must have misunderstood from the manual.
As I mentioned before, English is not my native language.
So it's possible that this part of the examples section

     If you would like to recover inode 2385 named dir and all it's decendants
     the command:

           % ffs2recov -c 2385 -n dir ffs.image

     will create dir, populate it, setting modes, permissions, and times to
     the originals.

will not "recreate the inode", but will take this as a starting point
to recover the rest... I'll investigate this further.



> It's not for the faint
> of heart but it can recover data that nothing else can.

Up to this point, I agree that ffs2recov seems to be the most 
promising tool. But you're right, I have to learn more about this
topic. It isn't that easy as creating a FAT with a hex editor. :-)



> It sounds like your home directory inode has been trashed, in which case
> your only choice is to try to find the directory blocks themselves, dump
> them and use them to find the names of the files in that directory.
> Otherwise you'll be stuck with them named by their inode.

Thank you, this is a very good approach. I found ffs2recov very
handy for the different stages, such as dumping blocks, retrieving
inode informations and such things.



> Those errors mean that there is very serious corruption on disk. 

I do believe it's so. Allthough I'm not sure what particularly
caused the damage, according to fsck_ffs there seem to be many
corruptions within the soft update data and the inodes, which
form some kind of linked list, as far as I understood it.



> The
> program is ignoring those errors and forging on to try to find and
> recover everything it can.  It may be that you won't be able to recover
> much. 

Depends on the "magnitude of damage"... which I can't tell
exactly of.



> You should, however, be able to recover at least some of your
> data, especially the stuff that's further away (physically and
> logically) from the trashed area of the disk.

I need to try some more, and I think the ref_fs.txt from The
Sleuth Kit mentioned in my first posting will give some good
information about how files and directories, inodes, blocks
and the other termini technici build up the basic principles
of an UFS file system.

It's... I never had much interest in how it worked, as long as
it worked, but I found out that many knowledge is obtained when
trying to solve some strange problem. After some time, you can
explain how TCP/IP, routing or compilation processes work. :-)



> I really can't hold your hand, here, since I'm overloaded as it is,
> sorry.  Best of luck.

Thank you. You did really help me giving some advices. And after
all... all the data loss and damages... I find the topic quite
interesting. Allthough there's no high demand for this data, I'll
take the time to learn more, and maybe find a way to solve the
problem using ffs2recov. There's probably no need to reinvent
the wheel until you learn how to drive. :-)




/* PS. I'm not on the -fs mailing list. */


-- 
Polytropon
>From Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...