Recovering Lost Data

Ever put a floppy disk into a drive, and hear that dreaded grinding sound when a sector’s gone bad?

Years ago, when I was working for a PC manufacturer, I learned a ton about the disk structure of drives: partitions, boot sectors, FATs, directories, etc. Back in ’87 or so, my cohorts and I created an enhanced version of DOS 3.2 that would talk to hard drives larger than 32MB (unheard of at the time!) We actually applied for a patent on some of the technologies we created. Anyway, through that and other work involving intentional corruption of partition tables (for the purposes of drive locking), I became a self-proclaimed expert on disks and drives.

When I started teaching 6 years ago, I found that this long lost knowledge had a use in the classroom. Every other week or so a student would appear in the lab, pull a floppy out of either their back pocket or the bottom of their backpack, and announce that their PowerPoint project / English term paper / etc. that they finished at home couldn’t be read. I’d put the disk in a drive, pull out my decades-old tools (some of which I wrote!), perform some incantations and mystic spells, and usually recover most if not all the files in question. I think in six years I’ve recovered some 70-80 files, to the delight of the students (and the occasional school administrator, who also sometimes keep important data on floppies!)

Last week, I hit a new high on the ego-meter. A student came to me with a plastic bag containing his brother’s 80GB USB hard drive. It seems that this University of New Hampshire sophomore inadvertently left the drive attached to a computer that was getting its hard drive repartitioned. Need I tell you what happened?

My first step of recovery was, logically, to plug the drive into a computer. Because it was a USB drive, none of the tools that I owned could examine the individual sectors, but one tool did show that the drive no longer contained a Windows partition, but a UNIX partition. Because of the USB limitation, I asked the student’s permission to open the drive (and thus, of course, void the warranty). Within the plastic case was a standard internal hard drive, which I hooked up to one of the PCs here in the lab. At this point, I was able to use my old tools, and I could see the details of the damage done. The partition table did, in fact, show a UNIX partition that occupied most (but not all) of the drive. Fortunately, while the Partition Boot Sector of the partition was wiped clean, the drive hadn’t been formatted yet. This meant that the bulk of the data might have survived. Perusing sector by sector further, I saw what looked like a FAT.

Here’s where it started getting interesting (to me, anyway). All of my disk internals experience was on FAT16 drives (okay, FAT12 on floppies, they’re almost identical anyway). I know what a 16-bit FAT looks like, and can walk a FAT chain practically blindfolded. But here was something quite amazing: 32-bit FAT entries. While scary, having never seen the insides of a FAT32 drive, it was also encouraging, because I don’t think I would have the guts to try to repair an NTFS drive.

I started wandering through the FAT sectors. The first thing I realized is “Man, there’s a lot more of these than I expected!” But of course: a FAT16 drive has at most 32,000 fat entries, which can fit nicely in 128 sectors. A quick calculation of this drive shows that it could have thousands of sectors per copy of the FAT! (I should point out here that the aforementioned home made disk tools allow me to step through sectors, heads, and tracks. No, I didn’t single step through thousands of sectors; with 63 sectors per track and 255 heads, I could jump 16,000 at a shot!) In fact, I soon determined that there were 17,973 sectors per FAT, and that there were 2 copies of the FAT. Furthermore, they were immediately followed by what looked like a valid root directory, so recovery looked highly possible.

I hooked a spare hard drive to the same computer (40GB, all I had at the time), partitioned and formatted it to be similar to the damaged drive, and started doing a sector-by-sector comparison and transfer from the working drive. With the Partition Boot Sectors (there are three of them in a FAT32 drive, yet another thing to get used to) copied from another drive, I got Windows to at least recognize the drive, although not see any data or files. This meant that the individual fields of the PBS were not-quite-right, and needed some tweaking. A Google search for details of a “FAT32 Boot Record” gave me the detailed byte level knowledge of what needed to be changed, and about an hour of hexadecimal calculations later I was able to restore the Partition Boot Sector enough to see all the files and folders. (All 67GB of data!)

Next I borrowed and hooked up a blank 100GB hard drive, and transferred all of the data to the other drive. This was necessary in my mind, because while I was able to read the USB drive, I couldn’t be certain that I had made all of the changes to the PBS that were needed, or that I made them all correctly, to ensure prolonged access to the drive. Once the data was backed up, I blasted the formerly-broken drive clean, restored the single partition table entry, reformatted the drive, and restored all the data back to the original drive.

Okay, for journalistic integrity, however, I must point out that I was not 100% successful in recovering ALL the data. Once I could talk to the drive again, I did a ScanDisk, and three files (all music files!) had invalid starting clusters, and therefore I couldn’t back them up to the other drive. However, this type of error was not something that could have been caused by the repartitioning, it was a “pre-existing condition”, and therefore I could wash my hands of them.

Over all, it was an exciting 5-6 hours, and left me feeling rather proud of myself. It’s neat to think that things knew ages ago can still be useful, and that not everything I learned back then has become obsolete. Now, about those NTFS formats …

 

COMMENTS FROM theSpoke:

 WHo is the ubergeek? @ Friday, April 21, 2006 4:26 PM

Mr I is the ubergeek. His school and his students are really lucky to have him. Go read his tale of disk…

AlfredTwo

re: Recovering Lost Data @ Friday, April 21, 2006 5:04 PM

Thanks, Alfred, you’re too kind

Mr_I

re: Recovering Lost Data @ Friday, April 21, 2006 7:45 PM

wow that’s a tedious job but it’s well done!

jasin14

re: Recovering Lost Data @ Thursday, April 27, 2006 6:09 AM

Cool stuff. I recall happy times spend recovering deleted files by patching FAT entries (if the file had not been overwritten you just had to replace the first name of the filename and tweak a few cluster entries).

However, my favourite problem was when a student had prepared his thesis using a Commodore Amiga. He then brought in a disk which was MS-DOS formatted but created on an Amiga. The first file on the disk was the table of contents for the thesis. Which he had given the name "con". Ever tried copying a file called con using the PC command prompt? You might like to have a go some time. Very weird things happen….. Mainly because con is MS-DOS for the console device (keyboard and screen).

Eventually I figured this out and renamed the file to contents using wildcards and all was well. Happy trimes.

RobMiles

re: Recovering Lost Data @ Thursday, April 27, 2006 11:12 AM

Ah, I remember those days well …
What a great story.

Mr_I

 

Advertisements

About Mr. I

After 17 years as a PC Software Engineer I gave it all up in 2000 to become a High School Computer Teacher
This entry was posted in IntoSpaces. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s