Undeleting (possible?)

Robert Watson rwatson at FreeBSD.org
Tue Nov 13 16:47:15 PST 2007


On Tue, 13 Nov 2007, Fernando Schapachnik wrote:

> Data recovery scenario (on 6.2): mistake while messing with Mail 
> directory...
>
> cd ~ mv Mail/xMail .. rm -r xMail (should have rm'ed Mail) No extra writes 
> to the filesystem. Plenty of extra space.
>
> Now I want to recover xMail (contains mbox files). sleuthkit only finds 
> Mail/xMail with no content. It also doesn't find any of the contained 
> mboxes.
>
> Is there still hope? My (limited) understanding is the content should be 
> more or less intact. Problem is: how do I find it?
>
> Thanks for any pointer!

The data is indeed there.  There are probably companies you can go to who will 
do this for a non-trivial fee, but if you want to do it by hand, I've found 
that reasonable progress can be made, especially if the files are text-only 
and small.

The first thing you want to do is make sure that you don't mount the file 
system writable -- you don't want to create any situation where the storage 
might be written to.  One example might be if you crash the box with it 
writable, and bgfsck creates a snapshot of the disk during the check. 
Usually at this point I'd take a snapshot of the file system, especially if 
small, by dd'ing the entire partition to a file on another storage device.

There are a number of ways you can proceed from here, but to be honest, the 
first thing I'd try, especially if there wasn't a lot of other random data on 
the file system, is to run strings on the image.  strings takes a byte stream 
and pulls out contiguous sequences of textish ascii characters--because of how 
we encode e-mail, e-mail qualifies as a very long sequence of such characters. 
Unfortunately, they will turn up in the order the data appears on the disk, 
and will also include non-delete files.  A reasonable next refinement would be 
to try to run strings on only the free blocks, rather than all blocks, which 
while also non-perfect, will carefully exclude real data on the file system. 
I'm not sure if we have an easy way to select down to those blocks, 
unfortunately, but writing a tool to identify free blocks and dump them 
sequentially to a file probably isn't all that hard.  Programs like fsck will 
already have the routines necessary to identify all reachable blocks, as a 
starting point.  Perhaps someone on the list has such a tool already, or an 
idea about how to use existing tools?

Robert N M Watson
Computer Laboratory
University of Cambridge


More information about the freebsd-fs mailing list