Data recovery

[M. Hornung]

If all else fails....  For ext2, there's a neat little toolkit called "The
Coroner's Toolkit" (http://www.porcupine.org/forensics/tct.html) that's
mostly used by people dealing with security incidents.  BUT the tools can
be helpful at other times too.  Within the toolkit is an application
called "lazarus" that can read through the 'dd' image and try to piece 
files together.  Again, this is a last resort type thing, but it might get 
you where you want to be.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  -=<(| mike at boobaz.net |)>=-          http://www.boobaz.net/key.html
           81CE 668E BC9D EDFE 08ED  D8D7 84A7 4F32 54C2 68F8


On Mon, 13 Jan 2003 at 11:50, Brandon Maust wrote:

|We did manage to get an image of the drive using dd and loopback-mount it
|under OpenBSD.  The superblock and file structure seem to be ok (autodetect fs
|type works), but any attempt to read the actual files fails (eg: I can ls, but
|even ls -l fails).  So, I think there was some physical corruption.
|Unfortunately, this seems to be specifically in Jen's home directory.
|
|I tried fsck'ing the loopback device, but it was quite unhappy and essentially
|said "you call this ext2? I don't want to deal with it."  I would provide
|actual error messages, but it looks like ATTBI assigned us a new IP.
|
|So, at this point I think we'd have to rebuild the filesystem on the loopback
|device around the bad blocks (which may actually be involved in it).
|fsck.ext2 doesn't seem to be able to do it.  Maybe e2image can do this,
|although it looks like it's more for dumping information from healthy
|filesystems in preparation for messes like this.
|
|I was really hoping *not* to have to use debugfs.
|
|-- 
|Brandon Maust
|
|On Mon, 13 Jan 2003, Cere M. Davis wrote:
|
|>
|>
|> How about using the e2image program to dump your stuff to a image file and
|> then mount that image file as a loopback device?  This way you don't have
|> to mount your drive - which you may be having trouble with - and
|> you will be able to see your archived your data in spite of the bad blocks,
|> - unlike dd - once you fsck the mounted loopback device.
|>
|> >
|> > So a month or two ago, the primary hard drive on my Unix machine went
|> > poof.  Like hard-drive-now-makes-clicky-noises sort of poof.  It had been
|> > running RedHat 7.2, with several different partitions scattered around on
|> > the drive.  There wasn't any dreadfully important data on the drive, with
|> > the exception of all of my backed up email since 1997 sitting like a duck
|> > in my home directory... which happened to be on the partition that went
|> > poo.  I'd really really like that information back. :/
|> >
|> > My long suffering roommate helped me try to get a disk image of that
|> > partition off the drive onto our OpenBSD router box, using dd, but then we
|> > ran into errors (he can chime in with what exaectly they were if he
|> > remembers...  Brandon?  It's been a little while and I've forgotten).  I
|> > feel kind of bad about continuing to bug him about it, so I'm thinking I
|> > might appeal to you all and get suggestions on how to proceed.
|> >
|> > It's been so long since we tried the image-over-to-BSD thing that I'm
|> > thinking I want to just start from the top.  So, anyone have suggestions
|> > on how to recover data from an IDE drive, formatted ext2 and running RH
|> > 7.2, that only works without bad noises if it's very very cool and then
|> > for only about 10 minutes? :/
|> >
|> > -Jen
|> >
|> >
|> >
|>
|> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
|> 		        Cere Davis
|> 		Unix Systems Administrator - CSDE
|>             cere at u.washington.edu   ph: 206.685.5346
|>          https://staff.washington.edu/cere
|>
|> GnuPG Key   http://staff.washington.edu/cere/gpgkey.txt
|> Key fingerprint = B63C 2361 3B9B 8599 ECC9  D061 3E48 A832 F455 9E7FA
|>
|>
|>
|>
|
|