Lost geli metadata

[Nathan Wehr]

I have FreeBSD 8.0 installed on a machine with geli encrypting one of the hard drives. Most of what's on the drive I can live without, but there are a few important items that, unfortunately, don't exist elsewhere. When I try to attach the drive, I get the following message:

[root at baxter ~/]# geli attach -k /root/ad4.key /dev/ad4
[root at baxter ~/]# Enter Passphrase: (I enter passphrase no problem, geli seems to attach)

[root at baxter ~/]# mount /dev/ad4.eli /private
mount: /dev/ad4.eli : No such file or directory <-- This is the problem

The rest of this sad story is really just a long list of me making stupid mistakes. Here's a bit of history that might be helpful:

Mistake #1: Store non-backedup data on a backup drive that's encrypted. 

If I hadn't of made Mistake #1, losing all of my data would be far less heart-wrenching. However - and unfortunately - my mistakes do not end there. To start out with, I took out the CD/DVD drive from the machine to install it in a different one. After I did that, the drive label for the encrypted drive changed from ad4 to ad2. And of course geli wouldn't attach the drive and so I tried to use glabel. Needless to say, glabel didn't work. After that, I backed up the meta data (more like overwrote meta data that was already backed up when I originally encrypted the drive) that geli puts on the drive and then try to restore it after I insert the CD/DVD drive. 

This didn't work, and with a little bit of research, I found out that both geli and glabel both write data to the same place on the hard drive (the last sector). Which means that the backed up meta data which is at /var/backups/ad4.eli now contains data for glabel instead of geli. I read somewhere that the meta data for geli contains key information which doesn't make sense to me because I have the key stored at /root/ad4.key. So, my question... Is there any hope at recovering the information on the drive? If so, how? And, if not, why?

I would appreciate any help that you could offer, especially regarding the failed mount command listed above.