Restore a LUKS partition that was overwritten by pvcreate

Question

I accidentally created a new physical volume over my LUKS partition; nothing else happened. The LUKS partition contains a LVM setup and the root partition (this setup was initially created by the debian installer).

I can see that the LUKS partition is mostly intact:

00000200: 4c41 4245 4c4f 4e45 0100 0000 0000 0000  LABELONE........
00000210: 0ccb b873 2000 0000 4c56 4d32 2030 3031  ...s ...LVM2 001
00000220: 4b48 5047 5667 6465 477a 7831 306a 6649  KHPGVgdeGzx10jfI
00000230: 7635 4432 4637 6966 446a 7172 3339 4863  v5D2F7ifDjqr39Hc
00000240: 0000 40a2 e800 0000 0000 1000 0000 0000  ..@.............
....
00005000: 7b22 6b65 7973 6c6f 7473 223a 7b22 3022  {"keyslots":{"0"
00005010: 3a7b 2274 7970 6522 3a22 6c75 6b73 3222  :{"type":"luks2"
00005020: 2c22 6b65 795f 7369 7a65 223a 3634 2c22  ,"key_size":64,"
00005030: 6166 223a 7b22 7479 7065 223a 226c 756b  af":{"type":"luk
00005040: 7331 222c 2273 7472 6970 6573 223a 3430  s1","stripes":40
00005050: 3030 2c22 6861 7368 223a 2273 6861 3235  00,"hash":"sha25
00005060: 3622 7d2c 2261 7265 6122 3a7b 2274 7970  6"},"area":{"typ
00005070: 6522 3a22 7261 7722 2c22 6f66 6673 6574  e":"raw","offset
00005080: 223a 2233 3237 3638 222c 2273 697a 6522  ":"32768","size"
00005090: 3a22 3235 3830 3438 222c 2265 6e63 7279  :"258048","encry
000050a0: 7074 696f 6e22 3a22 6165 732d 7874 732d  ption":"aes-xts-
000050b0: 706c 6169 6e36 3422 2c22 6b65 795f 7369  plain64","key_si
000050c0: 7a65 223a 3634 7d2c 226b 6466 223a 7b22  ze":64},"kdf":{"
000050d0: 7479 7065 223a 2261 7267 6f6e 3269 222c  type":"argon2i",

However, the characteristic "LUKS" is missing.

Is there any way to access the LUKS partition to retrieve the data? I tried testdisk, but without success.

---

Update, since I did not include this originally: Here is the LUKS header backup @ 0x4000:

00004000: 0000 0000 0000 0002 0000 0000 0000 4000  ..............@.
00004010: 0000 0000 0000 0005 0000 0000 0000 0000  ................
00004020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00004030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00004040: 0000 0000 0000 0000 7368 6132 3536 0000  ........sha256..
00004050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00004060: 0000 0000 0000 0000 735b 6f53 2466 e2bb  ........s[oS$f..
00004070: abcf fb4a d5ea d395 70ab f4e8 1f99 a173  ...J....p......s
00004080: 2303 93a0 7582 eb4a 77fe 28f8 3e01 b246  #...u..Jw.(.>..F
00004090: e9eb cd58 8a7a afd5 4e45 319a c007 906b  ...X.z..NE1....k
000040a0: b22a c393 1918 981c 6636 6333 6461 3534  .*......f6c3da54
000040b0: 2d63 6435 362d 3433 3036 2d38 6330 312d  -cd56-4306-8c01-
000040c0: 3534 3334 3366 6265 6564 3236 0000 0000  54343fbeed26....
000040d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000040e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000040f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00004100: 0000 0000 0000 4000 0000 0000 0000 0000  ......@.........
00004110: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00004120: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00004130: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00004140: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00004150: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00004160: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00004170: 0000 0000 0000 0000 0000 0000 0000 0000  ................

Answer 1

cryptsetup repair, Part One — Magic Bytes Recovery

• See also: cryptsetup repair, Part Two — Full Header Recovery

This looks like a LUKS 2 header that was directly overwritten with LVM metadata. So the LUKS device became a LVM Physical Volume. So this is a damaged LUKS header recovery problem. Depending on the damage, it might be irrecoverable.

For LUKS1, it's usually game over, but LUKS2 has a secondary header at offset 0x4000. You inconveniently did not include that offset range in your output, but the LUKS2 JSON data at offset 0x5000 is still there.

So you can try the following experiment:

Copy the first 16 MiB of the device (the LUKS 2 header):

# head -c 16M /dev/yourdevice > luksheaderdamage.img

Restore LUKS 2 header magic byte signatures (wiped by LVM):

---  Primary:    0x0000 » LUKS\xba\xbe\x00\x02  ---
# printf 'LUKS\272\276\0\2' | 
  dd bs=1 count=8 conv=notrunc of=luksheaderdamage.img

---  Secondary:  0x4000 » SKUL\xba\xbe\x00\x02  ---
# printf 'SKUL\272\276\0\2' | 
  dd bs=1 count=8 seek="$((0x4000))" conv=notrunc of=luksheaderdamage.img

Try to repair the LUKS 2 header:

# cryptsetup repair luksheaderdamage.img
WARNING: Device luksheaderdamage.img already contains a 'LVM2_member' superblock signature.

WARNING!
========
Really try to repair LUKS device header?

Are you sure? (Type 'yes' in capital letters): YES

Check the result:

# cryptsetup luksDump luksheaderdamage.img

If successful, open the device:

# cryptsetup open --readonly --header=luksheaderdamage.img /dev/yourdevice cryptyourdevice

Then see what can be found...

# file -s /dev/mapper/cryptyourdevice

If any of these steps fail, you might not have much hope left...

(The hoop jumping with all these commands is only necessary because cryptsetup repair is not flexible and refuses to repair LUKS 2 headers even if the damage is limited to the magic bytes. Hence the restoring of the magic byte signature is a manual process.)