Today I ran through an exercise of restoring a ZFS pool. The beginning of one hard drive participating in the pool (no raidz) was incidentally overwritten.. by me. I’m glad I noticed the mixup and cancelled dd, but still 60MB was gone. I spent a few evenings analysing and fixing the MBR, partition table and ZFS labels manually using hexedit.
It was very helpful that both the GUID Partition Table (GPT) and ZFS vdevs store redundant information at the end of the drive.
I restored the drive to a state that fdisk -l started showing the correct partition info, but no matter what I did further, zdb -l /dev/sdb reported “failed to unpack label” for all 4 labels, and therefore zfs export/import only gave I/O errors.
Then I noticed, that even though fdisk found the partitions, after reboot there were partition devices like /dev/sdc1 for the healthy drives, but no such entry for the corrupt /dev/sdb. Even though fdisk did not give any warnings, I built and ran the latest gdisk. It found that the GPT is actually still corrupt and restored a good copy from the end of the drive. The problem was almost solved – I simply imported the pool (not sure I should have exported it at all, but there you go), run zpool scrub tank, zpool status -v tank showed unrecoverable errors in a few files, but they were successfully restored from a backup.
Hi Antanas
I have a similar problem and I was wondering if you could help me fix it. I’m running a RAIDZ configuration and I accidentally had windows “initialize” 3 of my ZFS disks. Now, when I start solaris, ZFS says that it “cannot open” those disks. I think that the initialization overwrote the partition table of the disks. Do you have any advice on how to correct the partition tables? I tried using testdisk but it does not support writing solaris partitions.
Inspired by your success I managed to repair the drives by copying the first 512 bytes from a good drive to my non-working drives.