How do I recover a lost filesystem that has been partially overwritten?

April 26, 2007 2:00 PM

I accidentally formatted my NTFS drive with HFS and wrote some data on it. Now how do I recover whatever is left? >>>Any filesystem experts around here?

I was installing Mac OS 9 on an old iMac and accidentally chose the installation volume as my big external USB disk with all my important data. I had 250GB of files in NTFS on it, and the Mac OS 9 install was only a few hundred MB, so there should still be a large amount of data untouched. I want to recover anything I can (including partial/corrupted files) that still remain in NTFS.

I'd appreciate some app/method recommendations, as well as some help understanding how filesystems work and what exactly has happened.

posted by oneous to computers & internet (6 comments total)

As you have probably guessed from the lack of responses, this is a hard question. Your assumption that MacOS only overwrote the part of the partition used by the installed files is probably wrong if you made the MacOS partition the size of the whole disk. The act of creating the empty filesystem typically writes to the whole partition. You don't say whether your new MacOS partition spans the whole old partition, but if it does that's bad news indeed.

If it does, in my opinion, your only chance might be a professional data recovery center, and those chances aren't very good. There certainly isn't likely to be a program you can run that automatically recovers stuff.

I know you don't want to hear a lecture about backups now that it's too late, but having important data in only one place means you will occasionally lose important data due to hardware failures, software screwups, or unfortunate mistakes.
posted by putril at 4:37 PM on April 26, 2007

I have used Stellar Phoenix with good success, and it is reasonably priced. It might be the direction to try.
posted by trinity8-director at 5:04 PM on April 26, 2007

Putril is possibly not right. My brother-in-law recently used something automatic to recover a bunch of files from an NTFS partition that Dell tech support had persuaded a newbie to reformat. I've emailed him to ask what that was. Don't touch the drive, and hang in there.

As for what's happened: at the level of commands issued across the cable to your hard drive, the HD presents itself as a bunch of 512-byte blocks. With single commands, your computer can read or write a short sequential range of these, starting from any block number. There is no notion of files, or filenames - the HD looks like a uniform array of 512-byte blocks with some performance constraints: it's much faster to read or write blocks in sequence than in some random order.

The next layer of organization is partitioning. This is a convention for dividing up the hard disk to allow the concurrent use of multiple filesystems. In the most common scheme, the very first block (block 0) holds a Master Boot Record containing a partition table. The partition table has four entries, each defining the starting block number, length and intended use for one partition; one of those intended uses can be "extended partition", where a partition will be treated like a whole disk including another partition table, allowing the disk to be cut up into more than four partitions. There's another partitioning scheme called GPT, used by later Macs and 64-bit Windows.

External drives formatted for Windows XP will have MBR partitioning defining a single partition that covers the rest of the drive. Depending on exactly what the installer did to your drive, you may or may not have overwritten the existing MBR.

A filesystem is simply a convention for turning an array of blocks, most commonly a single disk partition, into a collection of files, keeping track of which files currently occupy what blocks and which blocks are still available to write new files into. Different filesystems take different approaches to placement of all the housekeeping information required to do this, though there is a general tendency to use up lower block numbers before going higher.

When you formatted your external HD with HFS, no attention at all was paid to the existing NTFS filesystem on the drive. If you're lucky, the formatting process confined itself to writing out the few hundred blocks of HFS housekeeping required to set up an empty HFS filesystem. If you're not, it's also written zeroes to every single unused block in the partition. This would have taken about half an hour; if the HFS formatting process was quicker than that, you're probably lucky.

Writing a couple hundred megabytes of files to your new HFS partition will have overwritten a few hundred megabytes of data blocks formerly belonging to NTFS files; in general there will be no relationship between the NTFS files destroyed in this way and the HFS files that destroyed them. Writing a single HFS file could potentially corrupt as many old NTFS files as the HFS file has blocks.

You will also have overwritten substantial numbers of NTFS housekeeping blocks, destroying the records of which disk blocks belong to which NTFS files, and what many of those files were named. Once again, there will be no correspondence between the number of HFS files written out and the amount of NTFS housekeeping lost; you may well find that a single HFS file has neatly written itself over the top of what used to be the NTFS Master File Table, effectively destroying all knowledge about what files used to exist.

That means that recovering the old NTFS files from your drive will involve attempting to identify which blocks correspond to files, and which are simply leftover bits and pieces from once-were files that got deleted but didn't have their blocks re-used. There will probably be a certain amount of housekeeping info still intact, but finding it will require scanning the whole drive and trying to recognize it based on characteristic patterns inside it. There will also be characteristic patterns in the headers of some of your files (jpegs, mpegs and so forth) allowing a sufficiently good scanner to find at least their first blocks; if your NTFS disk was reasonably free from fragmentation, you might even recover whole files based on that info. But it's all as iffy as hell.

There do exist utilities to do this kind of thing automatically, and some of them do work surprisingly well, so all is probably not lost. If I were you, though, I'd steel myself for "most".
posted by flabdablet at 5:56 PM on April 26, 2007

Thanks flabdablet, I'd happily be wrong. I hope OP reports back.

(I know I'm right about the backup part though.)
posted by putril at 8:18 PM on April 26, 2007

OK, my brother-in-law emailed me back: the program he's used, with much success, is Active@ Undelete.

Get yourself another external drive to recover your files onto (DO NOT attempt to recover them in-place on the b0rked one - just don't; you've done enough damage to that filesystem already), and give it a shot.

At best, you'll get some data back.

At worst, you'll end up owning a backup drive so this doesn't happen to you again.
posted by flabdablet at 6:38 AM on April 27, 2007

Just to labor that point a little: it's very very important not to write ANYTHING to the b0rked drive. That means, don't let the Mac use it and don't let Windows scan it for errors.

You may well benefit from running several different data recovery utilities against this drive, and you DO NOT want any of them to be making changes on it. Get a second drive before you do anything at all with the busted one.
posted by flabdablet at 6:44 AM on April 27, 2007