one of my sysadmins managed to write data, a tar file, starting at block 0 of the boot disk. This FC3 system has been running smoothly for over 2 years. I used dd command to read the first 512 bytes of data. This is where I expected the Master Boot Record to be written. What I found was data related to the tar file being written.
What I have done:
1, used dd to systematically copy 10GB chunks from the corrupt disk to another system.
2, tried mkpart on the corrupt disk in efforts to mount the disk.
3, also tried mk2fs -S, e2fsck.ext3, cautiously used parted without the guts to save changes.
3, dd_rescue and dd_rhelp did not seem to help me.

What I want is recory of specific files. Our backup procedure was inadequate and some significant files were changed and not backed up.
OK, what I really want is full recovery of all files but will take what I can get.
I am confident that all my data and file are still available, I can see them in the files created from dd.
At some point I must rebuild and start over but I figured a recovery effort was worth the time and effort. So far I have not been sucessful.
I may resort to using file type pointers to help identify specific files like MySQL DB's, tar, gz, etc.
Any help, pointers, tools, advice will be greatly appreciated.

It sounds to me like not only did your partition table get nuked, but possibly one or more block groups, and god knows what else.

Page 29 of the Filesystems-HOWTO will show you what the physical layout of the e2fs looks like. Alot of critical filesystem control info should still be there, but first...

If you have an image of the original partition table (output from fdisk -I or better..) in your documentation somewhere then you will be able to rebuild the partition table "by hand" as it were. See Partition-Rescue HOWTO, but beware; last update was 2003. It might still be helpful though.

I don't know how to cope with the 'front end' of your filesystem getting tar'ed all to fsck. I have only recovered partitions by rebuilding their partition tables. After that, everything reappeared for me. You may have missing magic numbers or other fs type meta-data that needs POKED in by hand. Eeekk!

I'm hoping that someone more up to date than I am will direct us both to a utility or tool that works better than my crusty old hacks.

Unfortunately once a sector has been physically overwritten, recovery is unlikely without hiring a professional data recovery service (and even then, the results aren't guaranteed)

If you had (for example) a 2G file that you wrote to (say) a 40G drive, then whatever occupied the front 2G would be lost, but the other 38G (that wasn't overwritten) would still be there (although all directory pointers to it would be lost). Out of curiosity, how big was the tar that was inadvertently copied, and what's the size of your drive?

As for tools, you might want to try foremost. Good luck with it

the drive in complete disarray is /dev/hda, 80GB
the tar file used in corruption is about 45MB.
So that leaves me with highly important filesytem data gone. However, I surmise the rest of the 45M is going to be a lot of generic data from the initial install. I beleive all the *real* files I want to recover have not been destroyed.
As for foremost I have it and used it. The conf file supports a lot of file types I am not interested. Although, it seems possible to add patterns I have not spent enough time to fully understand it well enough. If you have some pointers, please share them.

Any progress here?

I have made a copy of the disk using dd. I cut the dd ouptut files into 10GB files. At some point I may be smart enough to figure out how to extract the files I need/want. I tried 'foremost' but did not get the results needed. In the interest of time, need for the server and the risk of not being able to recover anything I rebuilt using FC6.
Any advice on extracting MySQL DBs, gzips, tarballs, etc from the dd files would be greatly appreciated.
Thanks for the follow up.

If I understand you correctly you have copied the whole disk in 10GB chunks, right? Working on the chunks obviously won't work since it cuts off files. Do you have enough storage capacity to resurrect that disk image from the chunks and enough spare storage to extract stuff (1.5 to 2 times the total disk size) (but most of all: time)?