Using 7.1.4 version of unraid, i cannot backup my xfs luksheaders?

I've documented the commands ive used in the past to backup my luksheaders but they dont seem to work the same anymore?

root@NAS3:~# cryptsetup luksHeaderBackup /dev/sdq1 --header-backup-file /boot/config/ST18000NM003D-3DL103_ZVT2DYKY.bin

Device /dev/sdq1 does not exist or access denied.

lsblk output:

root@NAS3:~# lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS

loop0 7:0 0 579.8M 1 loop /usr

loop1 7:1 0 169.8M 1 loop /lib

sda 8:0 1 14.6G 0 disk

└─sda1 8:1 1 14.6G 0 part /boot

sdb 8:16 0 16.4T 0 disk

└─sdb1 8:17 0 16.4T 0 part

sdc 8:32 0 16.4T 0 disk

└─sdc1 8:33 0 16.4T 0 part

sdd 8:48 0 16.4T 0 disk

└─sdd1 8:49 0 16.4T 0 part

sde 8:64 0 16.4T 0 disk

└─sde1 8:65 0 16.4T 0 part

sdf 8:80 0 16.4T 0 disk

└─sdf1 8:81 0 16.4T 0 part

sdg 8:96 0 16.4T 0 disk

└─sdg1 8:97 0 16.4T 0 part

sdh 8:112 0 16.4T 0 disk

└─sdh1 8:113 0 16.4T 0 part

sdi 8:128 0 16.4T 0 disk

└─sdi1 8:129 0 16.4T 0 part

sdj 8:144 0 16.4T 0 disk

└─sdj1 8:145 0 16.4T 0 part

sdk 8:160 0 16.4T 0 disk

└─sdk1 8:161 0 16.4T 0 part

sdl 8:176 0 16.4T 0 disk

└─sdl1 8:177 0 16.4T 0 part

sdm 8:192 0 16.4T 0 disk

└─sdm1 8:193 0 16.4T 0 part

sdn 8:208 0 16.4T 0 disk

└─sdn1 8:209 0 16.4T 0 part

sdo 8:224 0 16.4T 0 disk

└─sdo1 8:225 0 16.4T 0 part

sdp 8:240 0 16.4T 0 disk

└─sdp1 8:241 0 16.4T 0 part

md1p1 9:1 0 16.4T 0 md

└─md1p1 253:0 0 16.4T 0 crypt /mnt/disk1

md2p1 9:2 0 16.4T 0 md

└─md2p1 253:1 0 16.4T 0 crypt /mnt/disk2

md3p1 9:3 0 16.4T 0 md

└─md3p1 253:2 0 16.4T 0 crypt /mnt/disk3

md4p1 9:4 0 16.4T 0 md

└─md4p1 253:3 0 16.4T 0 crypt /mnt/disk4

md5p1 9:5 0 16.4T 0 md

└─md5p1 253:4 0 16.4T 0 crypt /mnt/disk5

md6p1 9:6 0 16.4T 0 md

└─md6p1 253:5 0 16.4T 0 crypt /mnt/disk6

md7p1 9:7 0 16.4T 0 md

└─md7p1 253:6 0 16.4T 0 crypt /mnt/disk7

md8p1 9:8 0 16.4T 0 md

└─md8p1 253:7 0 16.4T 0 crypt /mnt/disk8

md9p1 9:9 0 16.4T 0 md

└─md9p1 253:8 0 16.4T 0 crypt /mnt/disk9

md10p1 9:10 0 16.4T 0 md

└─md10p1 253:9 0 16.4T 0 crypt /mnt/disk10

md11p1 9:11 0 16.4T 0 md

└─md11p1 253:10 0 16.4T 0 crypt /mnt/disk11

md12p1 9:12 0 16.4T 0 md

└─md12p1 253:11 0 16.4T 0 crypt /mnt/disk12

md13p1 9:13 0 16.4T 0 md

└─md13p1 253:12 0 16.4T 0 crypt /mnt/disk13

md14p1 9:14 0 16.4T 0 md

└─md14p1 253:13 0 16.4T 0 crypt /mnt/disk14

md15p1 9:15 0 16.4T 0 md

└─md15p1 253:14 0 16.4T 0 crypt /mnt/disk15

sdq 65:0 0 16.4T 0 disk

└─sdq1 65:1 0 16.4T 0 part

What am i doing wrong?

Edited October 26, 2025Oct 26 by je82

Just now, je82 said:

What am i doing wrong?

wrong devices, you backup the md*p1 devices

2 minutes ago, Mainfrezzer said:

wrong devices, you backup the md*p1 devices

does this mean that my old luksheaders i backed up in older versions of unraid are wrong? or did the names of the devices change at some point as unraid has gotten updated? (just asking so i know if i have to go back and backup the headers in my other unraid boxes)

according to my own documentation which is years old i used the /dev/ path previously when doing the luksheader backups.

6 minutes ago, je82 said:

does this mean that my old luksheaders i backed up in older versions of unraid are wrong? or did the names of the devices change at some point as unraid has gotten updated? (just asking so i know if i have to go back and backup the headers in my other unraid boxes)

according to my own documentation which is years old i used the /dev/ path previously when doing the luksheader backups.

dont nail me down on it, should be unraid 7. Although the old header should work fine if applied to the md*p1 devices, but im not absolutely sure on that. Doesnt hurt to create a new backup just to have it

Edit: should mention that this is only for array devices, the pools are still the "old way"

Edited October 26, 2025Oct 26 by Mainfrezzer

Hmm this has me a little bit concerned, my oldest NAS which was created in 2019 using XFS Encrypted, whenever i backup the luksheader on this machine, the header is only 1028kb (1mb) , while all the headers backed up on NAS3 which was created 2 years ago, they are 16384kb (16MB) what is causing this massive difference in size?

Disk size on old nas i 12tb, new nas 18tb, but going from 1028kb > 16384kb seems unreasonable? Can i trust these headers? Why is it outputting so small headers on the older nas? (older nas is using 7.1.4 but array was created using unraid 6x something i believe, whatever was modern in 2019.)

asked AI:

Key Factors Explaining the Size Difference

1. LUKS Version Differences:

   • In 2019, Unraid likely used LUKS1, which was the default for many Linux-based systems at the time. LUKS1 headers are smaller, typically around 1 MB (1024 KB or slightly more, such as 1028 KB in your case), depending on the configuration.

   • Modern versions of Unraid likely use LUKS2, which was introduced around 2018 and became more common in later years. LUKS2 headers are significantly larger (defaulting to 16 MB or 16384 KB) to accommodate additional features, such as:

     • Support for more keyslots (up to 32 in LUKS2 vs. 8 in LUKS1).

     • Flexible metadata storage for advanced features like token-based authentication or integrity protection (e.g., using dm-integrity).

     • Larger keyslot sizes to support stronger encryption algorithms or larger keys.

   • The larger header size in LUKS2 is a deliberate design choice to future-proof the format and support additional cryptographic flexibility.

2. Key Size and Encryption Algorithms:

   • Your guess about the key size is partially correct, but it's not necessarily that XFS itself generates different key sizes. Instead, the LUKS header contains the encrypted master key(s) and metadata for the keyslots. In LUKS2, the default keyslot encryption parameters (e.g., Argon2 for key derivation) may use larger memory or computational requirements, leading to larger keyslot sizes.

   • For example:

     • LUKS1 typically used PBKDF2 for key derivation with smaller keyslot sizes (e.g., 256 KB per keyslot).

     • LUKS2 may use Argon2 (introduced as a more secure key derivation function) or other algorithms that require more space in the header for each keyslot, contributing to the overall header size increase.

   • Additionally, modern LUKS2 setups might use larger master key sizes (e.g., 512-bit instead of 256-bit) or different cipher modes, which can slightly increase the header size.

3. Default Header Size in LUKS2:

   • LUKS2 has a default header size of 16 MB (16384 KB), as defined by the cryptsetup tool, to ensure sufficient space for metadata, keyslots, and future extensions. This is a significant increase from the ~1 MB used by LUKS1.

   • Even if the actual data stored in the header doesn't fully utilize this space, the LUKS2 format reserves the full 16 MB to avoid constraints in future updates or when adding new keyslots.

TLDR: old unraid > LUKS1, new(er) unraid > LUKS2