[zfs-discuss] recovering zfs partition tables/data

cmc iucounu at gmail.com
Mon Dec 5 09:18:15 EST 2016

Hi Gregor,

Thanks for the reply. Just to clarify: I haven't attempted to add the
drives to the pool (as the pool is currently non-existent due to the drives
missing their signatures). However, I'm assuming it would still be feasible
to copy the partition table to the drives that are missing it from a good
disk, then change the GUID as you've shown above, correct?

Kind regards,


On Mon, Dec 5, 2016 at 12:00 AM, Gregor Kopka (@zfs-discuss) <
zfs-discuss at kopka.net> wrote:

> Am 04.12.2016 um 19:51 schrieb cmc via zfs-discuss:
> In the process of replacing a failed drive for a raidz2 set, and while the
> machine was powered off, a cable was unplugged which connected 3 drives to
> the sata HBA, and when the machine booted up, it of course reported the
> pool as unavailable. I powered the machine down again, plugged the cable
> back in, but the HBA no longer recognised the drives. I added them back as
> RAID 0 single volumes, as other RAID controllers I use for ZFS use this
> configuration for single drives. However, I forgot that this particular
> controller has 'pass-through' mode, and when the machine booted up, it
> could not find the partition tables created by ZFS. So I rebooted and set
> it back to pass-through in the HBA BIOS, but the tables were gone, I assume
> the HBA overwrote it with a RAID signature. I am hoping that the controller
> does not overwrite the entire disk (it showed no signs of overwriting large
> numbers of sectors when I created the raid0 config), and thus that most of
> the data will still be there. My hope is then that I can then perhaps
> re-create the ZFS partition table without killing the data.
> Ouch.
> I'm trying TestDisk as a recovery tool, but it does not support ZFS and
> reports HFS partitions and 'MS Data' on the drive. I thought I could dd the
> contents of each of the drives to another set of drives (1:1), and then try
> to create a partition table somehow manually, though I'm not sure how to do
> this.
> First of all: have, or work, on copies (which is your plan anyway)
> In case you had GPT partition tables you could check with sgdisk if the
> backup partition table still exists and use it to repair the overwritten
> one (depending on what the controller overwrote).
> Should that not work and you have let ZFS create the partitions on the
> affected drives (by adding them to the pool without prior partitions on
> them) *and *the drives are *identical* to another still working drive in
> the pool (*including* using the same controller and controller mode as
> the damaged ones, so you see the same maximum LBA on them) you *should*,
> as partition creation of ZFS is deterministic, be able to transfer the
> partition layout from the still intact one:
> *sgdisk -R <defect drive copy> <intact drive>*
> to clone the partition information 1:1, followed by:
> *sgdisk -G <defect drive copy> *
> to make the partition guids unique on the cloned partition table.
> Gregor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.zfsonlinux.org/pipermail/zfs-discuss/attachments/20161205/7544b801/attachment.html>

More information about the zfs-discuss mailing list