[BBLISA] Q on post-rm / fsys (dd,split,strings,whatever)

[Dean Anderson]

I had a client that deleted their source repository by mistake without
backups.  This has worked on sun ffs: (and its from ancient memory, so
there may be some "crc errors" in the recollection).

 1. Start with root directory file. You can figure this out from
   the super block, and it can't be deleted. 
 2. deleted directory file entries have a '~'(?) as the first character,
    followed by the inode number.  (there is a C struct for this).
 3. look at the inode, and check that its blocks are all actually 
    free and that additional blocks of blocks have sensible block 
    numbers--if the block numbers are past the filesystem, its 
    overwritten data and you can't recover this file)
 4. "undelete" the inode, adjust the free blocks, links, and adjust the 
   directory file	

Lather, rinse, repeat until end of directory, recursing on directory
inodes.

You'll get some garbage, lose some good files, but you'll get some of
them back with wrong first character. I got about 75%, which was deemed
worthwhile for the effort.  I thought there might be a way to maximize
the recovery somehow, maybe by looking for newer inodes so that old
deleted files didn't displace new deleted files...

I once had a program to do above, but I lost it (actually, it wasn't
really mine--I left it with employer).

I suggest keeping the broken fs offline and do the recovery onto another
disk reading the block device, so you can repeat it if necessary.
Mounting the disk or altering data just has the potential to destroy
more.

Dump of the broken system will be no help since, dump (usually--I
haven't looked at ext3 dump) just goes through the inodes and skips free
inodes, so the deleted inodes (the ones you want to recover) are missing
from the dump.

Good luck.

		--Dean

On Thu, 8 Apr 2010, Doug Mildram wrote:

> Hi! I'm helping recover someelse's torched /  fsys at work
>              (redhat9,ext3...have "dump" format of the BROKEN / also)
> 
> I had a USB external disk (ext3 fs, 200g) to dump onto, and I know this fsys
> needs reloading,
>    but some body parts might (or might not) be worth looking for.
> Seriously if you've tried any post-mortem (HEALTY ext3 filesystem, torched
> with "rm -rf /" (which is no prob for the fsys itself,
>   but leaves the data in free blocks, which are
> how-badly-scattered-i-wonder.
> 
> (background; the root perl script "system" rm -rf $variable/something
>          did a few dirs and stopped....I have the perl script stderr logfile
> for fun)
> 
> Would you guess the overall idea, or the rough steps below, might work well,
> or not?
> I would not dare to ask, but suspect a few of you may have tried something
> LIKE this.
> 
> Since /boot and /etc (at least; I believe it was rm -rf / )
>                 got wiped  a few hours ago, I have the RAW FILESYSTEM too.
> So the QUESTION is about recovering pieces of the REMOVED files perhaps e.g.
> 
> 
> # dd if=/dev/sda2 of=FILEname01   count=500mb       ( "bs=8k"  not needed
> these days right?)
> 
> #dd if=/dev/sda2  of=FILEname02 skip=500mb count=500mb   ( 2nd of roughly 60
> pieces )
> 
> =================
> thought the above might be smarter than "split --bytes=
> 
> So using plain tools like "split", "strings", "grep" I wonder if I could
> recreate parts of a few files.
> 
> dump of /    had 3-5 gb (I'm home now, I forgot: took 1 hour to "dump" it to
> usb2)
>            has the files WITHOUT  /etc
> 
> (dd of 31gb / filesystem :     31gb. Not a problem.
>         Maybe split it into ~ 500mb pieces with "split" ,,,,or "dd
> count=(whatever500mb)
> Then (havent really done this yet)  idea#  strings 500mbfile01 > strings01
> 
> Will be fun to see if "strings" is useful here.  Any tips?
> --
> (other ideas are fun topics too, since I'm holding the firehose, not the
> torch)
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 256 5494