[SOLVED] Lost all data on encrypted BTRFS by trying as cache? (did not format or mount)

[golli53]

I tried to see if I could move my 1TB Samsung NVME SSD from an unassigned device to cache seamlessly. It was formatted as LUKS-encrypted BTRFS (single partition). When it turned out to be unmountable, I immediately stopped the array. I did NOT hit format, so I didn't think any changes would be made. However, this device is now unmountable (with no filesystem being shown). Is there any way I can recover my data?

 

I have all my critical data on this device (all my VM drives) and was foolish and did not make backups.

 

[edit] Before assigning it to cache, I had the cache as a RAID 1 LUKS-encrypted BTRFS pool. So, I assigned it as 1 of the 2 cache devices and left the other slot empty before hitting "start."

 

Here is the relevant result from "blkid"

/dev/nvme1n1: PTUUID="xxxxxx" PTTYPE="dos"
/dev/nvme1n1p1: PARTUUID="xxxxxx-01"

Edited December 25, 2020 by golli53
additional info; solved

[JorgeB]

See if any of these help:

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=543490

 

[golli53]

6 hours ago, johnnie.black said:

See if any of these help:

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=543490

 

Thanks - those did not work because it was not even being recognized as LUKS.

 

Thankfully I ended up fixing the issue. For whatever reason, when unRAID failed to mount the drive as cache, it overwrote the first 6 bytes of the LUKS header with zeroes. Thankfully, these bytes of the LUKS header are standard, so I used a hex editor and dd to correct them.  Hopefully, these commands might help someone else encountering the same situation in the future:

 

dd if=/dev/nvme1n1p1 of=/mnt/user/share/broken_header.bin bs=512 count=1


root@Tower:~# dd if=/dev/nvme1n1p1 bs=48 count=1 | hexdump -C
1+0 records in
1+0 records out
48 bytes copied, 0.0134741 s, 38.0 kB/s
00000000  00 00 00 00 00 00 00 01  61 65 73 00 00 00 00 00  |........aes.....|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  78 74 73 2d 70 6c 61 69  |........xts-plai|


root@Tower:~# dd if=/dev/sdl1 bs=48 count=1 | hexdump -C
1+0 records in
1+0 records out
48 bytes copied, 0.00186538 s, 25.7 kB/s
00000000  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  78 74 73 2d 70 6c 61 69  |........xts-plai|

After fixing with a hex editor, using the bytes from sdl1 above:

dd if=/mnt/user/share/fixed_header.bin of=/dev/nvme1n1p1 bs=512 count=1

 

Edited July 19, 2019 by golli53
fixed commands

[golli53]

One additional piece of info in case it might be helpful for development. After fixing the header, I tried reassigning the disk to cache again after getting rid of the empty 2nd cache slot (I made a backup before!). It mounted fine and all the files were preserved.

 

I think the crazy header overwriting was somehow triggered by having an empty 2nd cache slot (2 other disks were previously used for cache in RAID1 LUKS BTRFS and I didn't change explicitly # of slots from 2 to 1 after emptying the disk selections).