Ran sgdisk -R the wrong way on a single-disk ZFS pool. How do I recover?

Operating Systems & Open Source Linux
, ,
1

In my attempt to attach a second disk to my proxmox install for redundancy (ironic) I accidentally ran sgdisk -R the wrong way. The disk I accidentally used as a source had previously had a different installation of Proxmox. Before running the command, I had wiped it through the GUI.

In my SSH history I can see me doing the sgdisk -R in the wrong direction. No zpool commands were run.

I rebooted after running sgdisk, it couldn’t find any bootable disks, and here we are.

I have the following information:

running gdisk -l gives me:

user@debian:~$ sudo gdisk -l /dev/nvme0n1
Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/nvme0n1: 1953525168 sectors, 931.5 GiB
Model: KINGSTON SNV2S1000G
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): FCEE0C3F-3CBC-42E9-A50C-EC3F898DAF30
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 1953525101 sectors (931.5 GiB)

Number  Start (sector)    End (sector)    Size       Code  Name

It doesnt list any partitions.

zdb -l gives me:

user@debian:~$ sudo zdb -l /dev/nvme0n1
failed to unpack label 0
failed to unpack label 1
failed to unpack label 2
failed to unpack label 3

What, if anything, can I do to recover from this? From my understanding I might be able to recreate the partition table/information but am unsure how to proceed.

Any help appreciated

2

Welcome, sorry to hear you’re having trouble :frowning:

If you haven’t touched the disk since then, you’ve got a pretty good chance of recovering it.

The first step is to take an image of the entire disk so you have a restore point in case you goof up.

dd if=/dev/nvme0n1 of=/path/to/the/backup IMPORTANT: the if flag means input file!

Once that’s done, you’re going to want to grab testdisk to try and recover the partition. Run it as root sudo testdisk and choose “no log” then select /dev/nvme0n1. If you were using MBR, you’ll want to choose Intel for the partition table type, then EFI GPT for a GPT table.

From there ,you choose “Analyze” and then “quick search”.

It’ll take a while to run this, but then once that’s done, you should be able to see a list of partitions. If it’s ZFS, you’ll usually have one large partition that takes up all but ~8MiB of disk space. Sometimes there will be a tiny partition at the end, sometimes not.

If everything looks good, go ahead and hit write. From there, you can try to re-import the pool.

2 Likes
3

I tried running testdisk at some point, but I didn’t know how to interpret the result. I’ve done it again now for both EFI and MBR since the EFI result looks strange to me.

MBR returns one large chunk with no content if i try to list files, so I don’t believe that’s of any use - I would assume I’m running GPT anyway, so this makes sense.

EFI gives me a list of lots of partitions, which I don’t understand. But it does have an EFI System partition at the very beginning. If i list files for this, i can navigate through the directory with the different proxmox kernels. So that part looks correct. What I don’t understand is the rest. Here is the output I get:

The hard disk (1000 GB / 931 GiB) seems too small! (< 7596816 TB / 6909264 TiB)
Check the hard disk size: HD jumper settings, BIOS detection...

The following partition can't be recovered:
     Partition               Start        End    Size in sectors
>  Linux filesys. data   1651084714 14837533111861815 14837531460777101





[ Continue ]
btrfs blocksize=4354918 Backup superblock, 7596816 TB / 6909264 TiB

It wants my disk to be a couple million terabytes larger than it is.

If I continue to the list of partitions, I get:

     Partition               Start        End    Size in sectors
>P EFI System                  2048    2099199    2097152 [EFI System Partition] [NO NAME]
 P Linux filesys. data     18878464  220205055  201326592
 P Mac HFS                234875609  236186349    1310741 [^X^A%^O^\^E^S^P^X^A"M-&X^X]
 P Mac HFS                324748537  326059277    1310741 [^X^A%^O^\^E^S^P^X^A"M-&X^X]
 P Mac HFS                326335857  327646597    1310741 [^X^A%^O^\^E^S^P^X^A"M-&X^X]
 P Mac HFS                328334217  329644957    1310741 [^X^A%^O^\^E^S^P^X^A"M-&X^X]
 P Mac HFS                516361441  517672196    1310756
 P Mac HFS                519279713  520590468    1310756
 P MS Data                663183395  663186274       2880 [NO NAME]
 P Mac HFS                690290585  691601340    1310756
 P Mac HFS                696307033  697617788    1310756
 P Mac HFS                738083113  739393853    1310741 [^X^A%1604C]
 P Linux filesys. data    787544847  788249142     704296 [^\S]
 D MS Data                788264680  789593831    1329152
 D MS Data                789593831  790922982    1329152
 P Mac HFS                817933657  819244397    1310741 [^X^A%1604C]
 P Mac HFS                821673441  822984181    1310741 [^X^A%1604C]
 P Mac HFS                834732033  836042773    1310741 [^X^A%1604C]
 P Mac HFS                965662447  966973187    1310741 [^X^A&^O^[^D^S.^X^A"9-^X]
 P MS Data               1004552371 1004555250       2880 [NO NAME]
 D MS Data               1507878064 1573414063   65536000
 D MS Data               1573414063 1638950062   65536000
 D MS Data               1631444640 1696980639   65536000
 D MS Data               1696980639 1762516638   65536000
 P Linux filesys. data   1902098971 1902166427      67457 [ ]







Structure: Ok.  Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
                P=Primary  D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
     Enter: to continue
FAT32, blocksize=4096, 1073 MB / 1024 MiB

The EFI partition looks right, and I’m able to navigate into it like I mentioned, but the rest is of course not. Is it junk as a result of it not knowing how to interpret the ZFS partition?

What do I do from here? Do I just leave the rest as it is in the output and write it to disk or will that break things?
Sorry if this is a bit handhold-y, I just don’t want to risk breaking anything else if possible

4

If this disk only had efi partition and the zfs partition, you should be able to get away with recreating them manually with fdisk or gdisk (a GPT partition table most likely, as that’s the default for proxmox installed in EFI mode). Since they are just editing the partition table (that was hosed by the sgdisk command) this should be safe to the actual data still on disk.

You have the start and end offsets of the efi partition as detected by testdisk. Then the zfs partition starts after it and ends at the end of the disk. Testdisk is clearly confused af about the zfs partition and I would not let it do anything, it already did its part by identifying where the efi partition is.

5

That’s another option, for sure.

Given that it’s from a proxmox system, you can trust that it’s going to have an EFI partition on the ZFS disk. Proxmox is cool like that.

6

Alright, it seems I’m pretty much back up and running. I got the partitions created in the table again as suggest and now I’m able to see my rpool and boot. I did get some LLM assistance but i very much appreciate the help

For posterity’s sake, the commands to recreate them were

sgdisk -n1:2048:2099199 -t1:EF00 -c1:"EFI System Partition" /dev/nvme1n1
sgdisk -n2:2099200:0 -t2:BF01 -c2:"rpool" /dev/nvme1n1

1 Like