ZFS Volume Partition Table Recovery
Accidentally deleting ZFS partitions from the GPT can make it difficult to restore them to their original state. This is because very few automated data recovery tools can detect a vdev through a standard scan and accurately determine the correct boundaries of the volume containing the pool or its fragment.
ZFS Volume Structure:
- vdev Label 0 (256 KB)
- vdev Label 1 (256 KB)
- Boot zone + pad (3.5 MB)
- Pool Data
- vdev Label 2 (256 KB)
- vdev Label 3 (256 KB)
The vdev itself is structured as follows:
- 8 KB - zeros
- 8 KB - boot
- 112 KB - nvlists (vdev_phys)
- 128 KB - Uberblock rings
The easiest way to find the start of a vdev in a hex editor is by searching for the string "Version", which is located right at the beginning. Note that this is 16 KB from the actual start of the volume, which must be accounted for when calculating the boundaries. This gives us the starting LBA required to populate the partition table.
The data within the vdev provides information about the pool type, the member disks, and the total pool size.
Once we have the pool size in bytes, we convert it to sectors by dividing by 512. Next, we calculate the ending boundary of the volume. We take the offset to the start of the volume (determined earlier) and add 8192 sectors (the size of the first two vdev copies + boot loader/pad), plus the pool size in sectors, plus 1024 sectors (the size of the two trailing vdev copies, which we must verify to ensure our calculation is correct). This gives us the final LBA for the ZFS volume.
Our next step is to write this into the GPT (the GPT structure is well-documented elsewhere). To do this, we take an empty partition entry and fill in the volume GUID, the starting LBA, and the ending LBA. After modifying the GPT, it is mandatory to recalculate the CRC at LBA 1.
Thus, with minimal modifications to the disk, the deleted partition can be fully restored.
Posted Sep 8, 2026, 11:40 AM UTC