Okay, so finally we have something consistent. The current partition table and the windows boot loader were written by some unexpected gremlin. The 3% extended partition doesn't exist. The uberblocks are precisely where I expected them to be (@fpmurphy: this offset is not due to an fdisk partition but to the hidden slices 8 and 9 being located before slice 0) so if you are lucky and nothing else beyond a mbr overwriting happened to your disk, your zpool is safe. Your disk has a single Solaris2 partition spanning the whole space available.

You need first to reconstruct your partition table. The correct data to be placed in it should be:

Code:

191   128  0      1      1       254    63     1023    16065     156280320

Unfortunately, Solaris fdisk command is zeroing the vtoc (slice table) should a new Solaris2 partition is created. As we want to preserve the existing vtoc, the trick is to create a partition with another type like this:

Code:

echo "6 128 0 1 1 254 63 1023 16065 156280320" > /tmp/fdisk.txt
fdisk -F /tmp/fdisk.txt /dev/rdsk/c0d0p0

Then, you need to reboot on a CD/DVD and immediately leave the grub menu to the GRUB CLI (press 'c' when the boot menu appears).

From here, you can change the partition type to the correct one with this command:

Code:

parttype (hd0,0) 0xbf

Your pool should then be importable and your data recoverable. By reinstalling grub, you should even have your OS fully recovered and bootable.

Of course, as all these steps involve writing to your disk. You should first make a full copy of your source disk and run the commands I suggested on that copy, not the original. The destination disk needs not to be exactly the same model as the source one, just of equal size or larger.
To perform the copy, either use the command suggested by ilikecow if you are more confortable with Gnu/Linux than Solaris, or run the equivalent Solaris command:

Code:

dd if=/dev/dsk/c0d0p0 of=/dev/dsk/c1d0p0 bs=512k

Adjust c1d0p0 to the correct device should it be different.