LVM/RAID recovery question

[Rich Braun]

OK so right after I offered help with the BLU server recovery, I had a
mini-disaster of my own.  I haven't lost any data but I've lost a lot of
*time* trying to recovery from this scenario, and short of a full-blown
backup/restore of the volume containing root and a bunch of other filesystems,
I haven't figured out how to finish the recovery.

Issue:  the RAID1 superblock for /dev/md1 is blown away on /dev/sda2

Observation:  the /dev/md1 device was coming up on /dev/sdg2 but the LVM was
(silently until I started scrutinizing this bizarreness more closely) running
the live system on /dev/sda2 instead of /dev/md1.

How this happened:  I was trying unsuccessfully to re-jigger the partition
table to increase the size of sda2 to match that of sdg2 (a RAID1 pair), and
at some point I did a mdadm --zero-superblock to try to force the system to
come up on /dev/sdg2 (and then later I would do an mdadm --add to reconstruct
the /dev/sda2 partition).  Well that did not work so ...here I am with the
hard drives in a strange state.

It surprised me that the LVM would come up at all on a partition that had been
zapped this way, but my question now that I've run the system for several days
like this is:  short of installing a whole new hard drive in parallel with the
existing, creating the /dev/md1 device there, copying everything over to that,
then doing an mdadm --add of /dev/sda2, then booting off the "sda" drive, then
doing an mdadm --add of /dev/sdg2, is there a way to simply regenerate the
/dev/md1 superblock (with the UUID that I've still got saved in mdadm.conf,
perhaps copied over from /dev/sdg2) in place on /dev/sda2 without risking
blowing away the system?  Or perhaps some alternative method of telling the
LVM to shuffle disk blocks around to a spare drive without having to resort to
backup/restore?

I think I'm suffering from fuzzy thinking after working at the office too many
hours over the past week--trying to avoid a tedious 5- or 10-hour procedure
that is error-prone and likely to require more than one attempt.

-rich