Quick command to back up all LUKS headers

[golli53]

Wrote this after a potential nightmare when mounting a cache drive with an extra empty slot erased my LUKS header

 

Run in ssh from whichever directory you want to store the headers. Will be automatically named with model and serial numbers. Finishes in a few seconds

for i in {/dev/sd*,/dev/nvme*}; do if cryptsetup luksDump $i &>/dev/null; then dd if=$i of=`udevadm info --query=all --name=$i | sed -n 's/.*ID_SERIAL=//p'`.img bs=512 count=4096; fi; done

 

[Xaero]

Excellent idea;
I may make a script to back up superblock information as well; as that could be used to recover a lot of data in the event of multiple disk failures.
Should be fine without though.

[tr0910]

What would we add to have it also grab LUKS headers from unassigned disks mounted?

 

Correction, it seems to already do unassigned disks.  Awesome...

Edited September 7, 2019 by tr0910

[Opawesome]

Hi all,

 

I was wondering what was the advantage of using the "dd" command (which is used in the script kindly shared by @golli53), rather than the built-in "cryptsetup luksHeaderBackup" command.

 

With the built-in command one would just need to run:

cryptsetup luksHeaderBackup /dev/sdbX --header-backup-file /path/to/luks-headers-backup/backed-up-header.bin

to backup the LUKS header,

 

and:

cryptsetup luksHeaderRestore /dev/sdbX --header-backup-file /path/to/luks-headers-backup/backed-up-header.bin

to restore the backed-up header.

 

I also see less risk of messing something with the "dd" command which, as I understand it, can be very destructive if not used correctly (the wikipedia page says that "dd is sometimes humorously called 'Disk Destroyer', due to its drive-erasing capabilities").

 

The script would then look like:

for i in {/dev/sd*,/dev/nvme*}; do if cryptsetup luksDump $i &>/dev/null; then cryptsetup luksHeaderBackup $i --header-backup-file `udevadm info --query=all --name=$i | sed -n 's/.*ID_SERIAL=//p'`.bin; fi; done

 

What do you think ?

 

Best,

OP

 

More on the dd command:

https://opensource.com/article/18/7/how-use-dd-linux

 

Interesting video on LUKS:

https://youtu.be/5rlZtasM-Pk?t=598

Edited February 11, 2021 by Opawesome
added: script modified with built-in "cryptsetup luksHeaderBackup" command

[Opawesome]

6 hours ago, Opawesome said:

I was wondering what was the advantage of using the "dd" command (which is used in the script kindly shared by @golli53), rather than the built-in "cryptsetup luksHeaderBackup" command.

 

It seems that it is actually recommended to use the built-in command rather than the "dd" command:

 

Quote

While you could just copy the appropriate number of bytes from the start of the LUKS partition, the best way is to use command option "luksHeaderBackup" of cryptsetup. This protects also against errors when non-standard parameters have been used in LUKS partition creation.

(abstract from https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery)

 

I also figured that:

 

Quote

While the LUKS1 header has a fixed size that is determined by the cipher spec (see Item 6.12), LUKS2 is more variable. The default size is 16MB, but it can be adjusted on creation by using the --luks2-metadata-size and --luks2-keyslots-size options.

(abstract from https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#10-luks2-questions)

 

That means that @golli53's script, which only backups the first 2MB of each device, may not be compatible with LUKS2 (which is the version used by Unraid as of the date of this post). On the contrary, using "cryptsetup luksHeaderBackup" does create 16MB header backup files.

 

I hope this helps.

 

Best

OP

Edited February 11, 2021 by Opawesome

[je82]

On 2/11/2021 at 3:37 PM, Opawesome said:

Hi all,

 

I was wondering what was the advantage of using the "dd" command (which is used in the script kindly shared by @golli53), rather than the built-in "cryptsetup luksHeaderBackup" command.

 

With the built-in command one would just need to run:

cryptsetup luksHeaderBackup /dev/sdbX --header-backup-file /path/to/luks-headers-backup/backed-up-header.bin

to backup the LUKS header,

 

and:

cryptsetup luksHeaderRestore /dev/sdbX --header-backup-file /path/to/luks-headers-backup/backed-up-header.bin

to restore the backed-up header.

 

I also see less risk of messing something with the "dd" command which, as I understand it, can be very destructive if not used correctly (the wikipedia page says that "dd is sometimes humorously called 'Disk Destroyer', due to its drive-erasing capabilities").

 

The script would then look like:

for i in {/dev/sd*,/dev/nvme*}; do if cryptsetup luksDump $i &>/dev/null; then cryptsetup luksHeaderBackup $i --header-backup-file `udevadm info --query=all --name=$i | sed -n 's/.*ID_SERIAL=//p'`.bin; fi; done

 

What do you think ?

 

Best,

OP

 

More on the dd command:

https://opensource.com/article/18/7/how-use-dd-linux

 

Interesting video on LUKS:

https://youtu.be/5rlZtasM-Pk?t=598

Thank you, i am doing a little bit of research if disaster was to strike and to backup these headers seem essential if you do xfs encryption as if the header is broken all your data is lost on that disk because you cannot mount it even with the correct password (as i understand?)

 

A question to an expert like yourself, is it nessecary to run the header backup as a "cronjob" do have "fresh" header backups or is this only needed to run once as the header never changes?

[Opawesome]

On 3/3/2021 at 10:30 AM, je82 said:

Thank you, i am doing a little bit of research if disaster was to strike and to backup these headers seem essential if you do xfs encryption as if the header is broken all your data is lost on that disk because you cannot mount it even with the correct password (as i understand?)

 

A question to an expert like yourself, is it nessecary to run the header backup as a "cronjob" do have "fresh" header backups or is this only needed to run once as the header never changes?

I believe there is indeed a chance to lose all your data if the LUKS header becomes corrupt, although I understand that the chance of that happening is lower with LUKS2 than with LUKS1.

 

I am by no means an expert. I just have just been doing some reading / testing on the subject during a week or so. My understanding is that the LUKS headers only change if you perform an operation like changing the password, or add a new key. So based on that understanding, my guess would be that you only need to backup LUKS headers if and when you do perform such an operation.

 

Anyway, as long as you keep your previous backups, I see no harm in scheduling a recurrent backup.

Edited March 7, 2021 by Opawesome

[je82]

4 hours ago, Opawesome said:

I believe there is indeed a chance to lose all your data if the LUKS header becomes corrupt, although I understand that the chance of that happening is lower with LUKS2 than with LUKS1.

 

I am by no means an expert. I just have just been doing some reading / testing on the subject during a week or so. My understanding is that the LUKS headers only change if you perform an operation like changing the password, or add a new key. So based on that understanding, my guess would be that you only need to backup LUKS headers if and when you do perform such an operation.

 

Anyway, as long as you keep your previous backups, I see no harm in scheduling a recurrent backup.

Thanks for the info, yeah this was a great find i am happy that you guys made this thread. Something tells me many who use xfs encryption only find out about this very big flaw once it is too late, i am very happy to have found this before shit potentially hit the fan so to speak.

 

Cheers, have a nice day!

[Opawesome]

If anyone is interested, below is a link to the script I wrote and which performs a backup of LUKS headers:

 

Edited May 26, 2021 by Opawesome