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

Tue Dec 16 13:06:20 EST 2008

On Tue, 2008-12-16 at 12:38 -0500, Michael H. Warfield wrote:
> 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.

	Seems that cp incorporates some heuristics in copying sparse files.
--sparce=auto should work in most circumstances but may be modified so
that cp will create a sparse file any time it encounters a long enough
stretch of zero blocks (what you get when you read a file in an area
where there is no assigned block).

> 	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
> 
> _______________________________________________
> 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/d670aeaf/attachment.bin