[ale] Fwd: Hard Drive Death Spiral -- AKA Recovery Software?

Tue Dec 16 12:38:09 EST 2008

On Tue, 2008-12-16 at 11:43 -0500, H P Ladds wrote:
> Thanks to all that offered help with me disk drive problem.
> 
> I have recovered all (save the Mozilla Firefox cache) of the
> information of the suspect partition. Steps taken:

	Excellent.  Congrats!

> 1. dd the partition to another drive. Result, the newly created
> partition behaved exactly as the old -- unmountable
> 2. ddrescued the partition to another drive and ran error correction
> utility. The number of errors was reduced from 8 to 1. Yet the newly
> created drive behaved exactly as the old one -- unmountable.
> 3. Downloaded the RIP Recovery Disk and ran the TestDisk app. SUCCESS!
> I saw all the files on the bad partition.
> 4. Used TestDisk to copy the most recent data to a new drive, and then
> copied the really old stuff from some DVD backups I made previously.

> Bit of weirdness -- when copying the my .mozilla file (I believe this
> is a cache file) the resulting files were LARGE and burned through
> about 122 Gigs of space on the new drive. I suspect that the cache
> files are largely compressed and TestDisk uncompresses them as it
> recovered them, but is compression technology that good? Is it likely
> that a series of cache files would expand to 112+ Gigs? I'm dubious,
> but its the only explanations I can come up with.

	It may have also been a "sparse" file.

	This is always a bit of a problem.  The original file looks huge to ls,
but doesn't have blocks assigned to it from end to end.  These are
created by opening a file for updating / writing and then seeking past
the end of the file and writing to blocks out past the end.  The OS only
assigns blocks to the file where data has been written.  This is great
for database files and caches which typically incorporate databases and
hashing.  Unfortunately, when you do a straight copy which is not sparse
file aware or capable of reproducing that characteristic, the copy ends
up with blocks assigned to the entire length of the file.

	I believe (but always may be wrong) that "ls" will tell you the size of
the file from end to end (EOF offset) while "du" should actually tell
you the number of disk blocks assigned to the inode.  Ted Tso once told
me about some ext3 utilities for debugging and managing ext3 file
systems which included sparse copying that properly maintained the block
allocations.

> Thanks Again,
> H. Preston

	Regards,
	Mike

> On Fri, Dec 12, 2008 at 4:15 PM, Greg Freemyer <greg.freemyer at gmail.com> wrote:
> > Stephen,
> >
> > You can find it at http://ptk.dflabs.com/overview.html
> >
> > DFlabs in an Italian company that is writing PTK.  aiui, PTK is a web
> > interface that manages "The Sleuth Kit" (TSK).
> >
> > TSK has been around a while, so I hope it is fairly robust, even if
> > PTK is not.  (PTK may be as well, but as a new product, I'd expect
> > some hickups.)
> >
> > I believe all of the above is Linux only.
> >
> > Greg
> >
> > On Thu, Dec 11, 2008 at 4:29 PM, Stephen R. Blevins
> > <srblevi at worldnet.att.net> wrote:
> >> Greg, Kind Sir,
> >>    Where can I learn about PTK.  Google is *not* my friend on this one.
> >>
> >>    TIA
> >>
> >> Stephen R. Blevins
> >> srblevi at worldnet.att.net
> >>
> >>
> >>
> >> Greg Freemyer wrote:
> >>> The first thing you need / want to do is make a full copy (image) of the drive.
> >>>
> >>> So, buy a drive that is atleast 20% bigger.  (just to be sure).
> >>>
> >>> Format it ext2 or some other basic FS.  (Definitely not FAT).
> >>>
> >>> If the drive is more or less functional use dd to make the image.  If
> >>> not, look into dd_rescue (or ddrescue, I forget).
> >>>
> >>> If it is a data drive, then all you have to do is:
> >>>
> >>> boot normally.  dd if=/dev/sdX of=/image_file_on_big_drive bs=4k
> >>> conv=sync,noerror
> >>>
> >>> If it is a boot drive, then boot a linux boot disk and do the same.
> >>>
> >>> Once you have that working copy, you need to decide if you want to
> >>> make even another copy that you keep un-modified.
> >>>
> >>> You can use gpart to guess / rebuild your partition table.
> >>>
> >>> Once you know where your partitions are and you know what filesystem
> >>> type you have, you can use various recovery software to move forward.
> >>>
> >>> To do the recovery, we use a professional tool, so I'm not sure what
> >>> low-end / free software is available to do the recovery.  (We use
> >>> either Encase Forensics ($3,000) or X-Ways Forensics. ($1200))
> >>>
> >>> PTK is new opensource recovery tool that was released in the last few
> >>> months.  It may support linux filesystems.  Not sure.
> >>>
> >>> HTH
> >>> Greg
> >>>
> >>> On Thu, Dec 11, 2008 at 10:54 AM, H P Ladds <householdwords at gmail.com> wrote:
> >>>
> >>>> Hey All,
> >>>>
> >>>> I have a hard drive that appears to be dieing, and I need data
> >>>> recovery software. Any suggestions?
> >>>>
> >>>> History of problem:
> >>>>
> >>>> 1. Somehow the partitions on the drive got out of order -- sda6 used
> >>>> sectors (4376 - 4618) and sda5 had (4619 - 19457).
> >>>> 2. In an effort to correct this situation, I deleted the partitions
> >>>> and recreated them using the same sectors.
> >>>> 3. I was hoping to do a e2fsck to recreate the superblocks and such.
> >>>> This was a bad plan, and partition sda5 is not mountable.
> >>>> 4. I did not reformat the partition, so I believe the information is
> >>>> still there.
> >>>> 5. I guess what I need to do is reformat the drive without destroying
> >>>> the data on the disk, which is mostly impossible -- right?
> >>>>
> >>>> Yes, I do have the info backed up on DVDs, but this seems to be a good
> >>>> opportunity to develop some data recovery skills, and maybe I can see
> >>>> what's on that disk I've had in the freezer for about two years.
> >>>>
> >>>> H. Preston
> >>>> _______________________________________________
> >>>> Ale mailing list
> >>>> Ale at ale.org
> >>>> http://mail.ale.org/mailman/listinfo/ale
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >> _______________________________________________
> >> Ale mailing list
> >> Ale at ale.org
> >> http://mail.ale.org/mailman/listinfo/ale
> >>
> >
> >
> >
> > --
> > Greg Freemyer
> > Litigation Triage Solutions Specialist
> > http://www.linkedin.com/in/gregfreemyer
> > First 99 Days Litigation White Paper -
> > http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf
> >
> > The Norcross Group
> > The Intersection of Evidence & Technology
> > http://www.norcrossgroup.com
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://mail.ale.org/mailman/listinfo/ale
> >
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale

-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20081216/28c9de2a/attachment.bin