Quick command to back up all LUKS headers


golli53

8 posts in this topic Last Reply

Recommended Posts

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

 

Link to post
  • 1 year later...

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 by Opawesome
added: script modified with built-in "cryptsetup luksHeaderBackup" command
Link to post
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 by Opawesome
Link to post
  • 3 weeks later...
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?

Link to post
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 by Opawesome
Link to post
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!

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.