o/1MS\o ⌨️🐧 | #WeAreNatenom

@Hercules That was really luck. I hope, that your backup will be successful.

Until now I didn’t used it, but probably I will also have a deeper look into luksHeaderBackup.

https://man.archlinux.org/man/cryptsetup-luksHeaderBackup.8.en
https://man.archlinux.org/man/cryptsetup-luksHeaderRestore.8.en

@Hercules So it was possible to use one of the other keyslots to open the encryption?

Probably you can test your wanted configuration in a virtual machine with some small virtual drives to avoid any loss of data.
I found it relative difficult to find the correct UUID which had to be used when I setup my system in the past.

@Hercules My exampled assumed, that you only have a password set on keyslot 0.

LUKS keyslots are starting at 0, so it seems, that you deleted the initial set password.
I hope, you know the other keyslots.

As far I can see, you can specify, which keyslot has to be selected for unlocking the volume key.
More information you can find in the man page.

man cryptsetup-luksaddkey

cryptsetup luksAddKey /dev/md0 --new-key-slot 0 --key-slot 1  

@Hercules I created it on my own, because I have some keys for other devices, too.
But you can place it, where you want.
But with crypttab.d I have a simple connection to crypttab configuration file.

Another way can be pam_mount, which I’m using on an SBC for opening an encrypted device:
https://inai.de/projects/pam/_mount/

@Hercules I have a similar setup with RAID1 and BTRFS.
I’m using a keyfile for that:
dd bs=512 count=4 if=/dev/random of=/etc/crypttab.d/keyfile-data.bin iflag=fullblock
chmod 600 /etc/crypttab.d/keyfile-data.bin

cryptsetup luksAddKey /dev/mapper/raid /etc/crypttab.d/keyfile-data.bin --new-key-slot 1

entry in /etc/crypttab:
data UUID=<blkid from /dev/md0> /etc/crypttab.d/keyfile-data.bin luks

entry in /etc/fstab:
UUID=<blkid from /dev/mapper/raid> /mnt/data …