Recovering UFS2 content via Sleuthkit

Bill Vermillion bv at
Tue May 24 18:43:01 GMT 2005

While humming that old rock song Yackety Yacc - Dont Awk Back 
Paul Mather sang or SED something like this:

> Has anyone managed successfully to recover deleted file content
> using, say, Sleuthkit, or is deleted UFS2 content recovery
> not feasible (aside from sifting manually with a disk sector
> editor)?

I've not used Sleuthkit but I've managed to recover files
using TCT - The Coroners Tookkit and the program 'lasarus' in
conjunction with 'unrm'.   

> I tried Sleuthkit from the ports collection, and although I can
> find deleted content using it, it's not possible to recover
> that content because too much important information has been
> lost from the inode: specifically, although information like
> the owner and timestamp information appears to be preserved,
> vital data such as the size, direct blocks, etc. are all zeroed,
> rendering the deleted content unreachable (or, rather, reducing
> the problem back to a manual search).

> So, am I right in thinking that even if the inodes and blocks
> belonging to a deleted file have not yet been reallocated or
> used again, it's still not feasible to recover the deleted
> content easily because of the data loss inflicted upon the
> deleted file's inode(s)? In other words, that the only data
> recovery possible is via manual means (searching for signatures
> and trying to piece together fragments)?

'lazarus' has options to build files or build an html structure.
'unrm' is preferable to use over 'dd' because you use it to
search the disk only for unallocated blocks.

What you will often find in the recovered files are parts of
two files at times, or only part of one large file. This is because
the 'unrm' goes block by block through the drive, and files are not
neccesarily contiguous.

When I ran 'unrm' and 'lazarus' after stupidly not checking a
command line [I accidentally remove files like this about every 6
or 8 years :-( ] I saved the output of the unrm to another
partition, then ran lazarus to parse those pieces found by 'unrm'.
Then when I got the whole segment done, I just moved that entire
tree into my XP machine and used the 'search' utility to look for

My problem was that I didn't notice the missing files for about a
week and I do run a news machine so I dinged a lot of files.

Nothing is easy when it comes to recovering lost files.  But you
learn more about the system, and more importantly it reinforces
your checking to keep from doing this again - hopefully.

> Also, I wonder why some, but not all, information is scrubbed when a
> file becomes deleted (especially information in the inode).

Probably for performance problems.  There has been talk about
buildding an FS that will zero blocks when you remove the indoes,
and in that case you will never recover anything.   An 'rm' just
essentially frees up the inodes, and doesn't do a thing with the
on-disk blocks.

> PS: Please Cc: me on replies, as I'm not subscribed to this list.


Best of luck on your attempts.  'tis painful and I've done it.
If you run lazarus to output html you may be surprised to find what
else lurrks on your disk that you thought you had gotten rid of.


> "Without music to decorate it, time is just a bunch of boring production
>  deadlines or dates by which bills must be paid."
>         --- Frank Vincent Zappa

I'll go along with those sediments too.

Bill Vermillion - bv @ wjv . com

More information about the freebsd-fs mailing list