Back Up a LUKS Header Safely with cryptsetup

You will create a binary backup of a LUKS header and its keyslot area, check that the backup is readable, and store it with permissions that match its sensitivity. Allow about 15 minutes, plus time to decide where an offline copy will live. This guide describes the cryptsetup 2.7.0 command shipped by the installed cryptsetup-bin package.

A header backup is not an ordinary configuration file. It contains the metadata and encrypted keyslots needed to unlock the volume. Anyone who obtains the backup and a passphrase that was valid when it was made may be able to decrypt the data, even after that passphrase has been removed or changed on the live device.

1. Check the command and identify the device

Run the version check as your normal account. The backup itself usually needs elevated access because the source is commonly a block device, so use sudo only for the cryptsetup operation and the checks that need it.

$ command -v cryptsetup
/usr/sbin/cryptsetup
$ cryptsetup --version
cryptsetup 2.7.0 flags: UDEV BLKID KEYRING FIPS KERNEL_CAPI HW_OPAL
$ dpkg-query -W -f='${Package} ${Version}\n' cryptsetup-bin
cryptsetup-bin 2:2.7.0-1ubuntu4.2

Replace /dev/REPLACE_WITH_LUKS_DEVICE below with the device that stores the LUKS header. Do not guess from a mount point or a filesystem label. Check the mapping and block devices first:

$ lsblk -o NAME,PATH,TYPE,FSTYPE,SIZE,MOUNTPOINTS
$ sudo cryptsetup luksDump /dev/REPLACE_WITH_LUKS_DEVICE

Checkpoint: the device path and the LUKS metadata have been identified, and you have not written anything yet.

2. Choose a protected backup destination

Use a destination on storage that will not disappear with the source device. The example creates a private directory in your home directory. A root-owned recovery directory or encrypted offline storage can be more appropriate for a production host, but do not put the only copy on the same disk as the LUKS volume.

$ install -d -m 700 "$HOME/luks-header-backups"
$ BACKUP="$HOME/luks-header-backups/REPLACE_WITH_DEVICE_NAME-$(date +%Y%m%d).luks-header"
$ printf '%s\n' "$BACKUP"
/home/you/luks-header-backups/REPLACE_WITH_DEVICE_NAME-20260922.luks-header

The command treats the backup path as a normal file. Do not use - expecting standard output: this subcommand writes a file literally named - when that is supplied as the filename. Use an explicit path instead.

3. Create the binary header backup

This is the first state-changing step. It reads the source metadata and writes the backup file. It does not change the LUKS header on the device, but shell redirection and an existing destination still deserve care. If the destination already exists, choose a new name or move the old copy aside before running the command. Do not overwrite the only known-good backup casually.

$ sudo cryptsetup luksHeaderBackup \
    --header-backup-file "$BACKUP" \
    /dev/REPLACE_WITH_LUKS_DEVICE

A successful run is normally quiet and returns to the shell prompt. Confirm that the file exists and has a non-zero size:

$ sudo stat -c 'mode=%A owner=%U:%G size=%s path=%n' "$BACKUP"
mode=-rw------- owner=you:you size=16777216 path=/home/you/luks-header-backups/REPLACE_WITH_DEVICE_NAME-20260922.luks-header

The size depends on the LUKS format and metadata layout. Do not treat one particular byte count as a universal expected result. The useful checks are that the command returned success, the file exists, and its permissions prevent unintended readers.

If you need non-interactive operation, the manual documents --batch-mode and -q as suppressing confirmation questions. Use that only in a reviewed script: it also disables passphrase verification when --verify-passphrase is not specified. A header backup is sensitive enough that quiet automation should be deliberate, logged and access-controlled.

4. Handle a detached LUKS header

With a detached header, the data device and the header file are separate. Pass the data device as the final argument and identify the header with --header. The backup file still contains the header and keyslot area, not the encrypted data.

$ sudo cryptsetup luksHeaderBackup \
    --header /path/to/REPLACE_WITH_DETACHED_HEADER \
    --header-backup-file "$BACKUP" \
    /dev/REPLACE_WITH_CIPHERTEXT_DEVICE

For an ordinary, non-detached volume, omit --header. If you swap these paths, cryptsetup may report that the device is not a recognised LUKS volume, or you may back up metadata from the wrong volume. Re-run luksDump with the same --header and device pairing before investigating permissions.

Checkpoint: the backup file has been created using the same header arrangement that the volume uses. The source device and detached header have not been modified.

5. Verify the copy without restoring it

Keep the live device untouched while checking the result. First compare the source metadata report with a report from the backup file. A backup contains LUKS metadata, so cryptsetup can inspect it as a LUKS input:

$ sudo cryptsetup luksDump /dev/REPLACE_WITH_LUKS_DEVICE > /tmp/luks-live.txt
$ sudo cryptsetup luksDump "$BACKUP" > /tmp/luks-backup.txt
$ diff -u /tmp/luks-live.txt /tmp/luks-backup.txt
$ rm -f /tmp/luks-live.txt /tmp/luks-backup.txt

No output from diff means the reports match byte-for-byte as text for this invocation. The reports can include sensitive metadata, so remove the temporary files after the check and do not paste them into an issue tracker. For a detached header, add the same --header option to the first luksDump command, then inspect the backup file without that option.

This verifies that the backup is structurally readable and reports the same metadata. It does not test every possible passphrase, external token or future restore destination. Keep the original device available until you have tested your recovery procedure on suitable spare media.

6. Store and recover it with the right assumptions

Keep at least one copy separate from the encrypted disk, and protect copies during transport and at rest. A header backup is not made safe merely by renaming it. Consider who can read the backup, who can read the corresponding passphrase, and whether your backup system exposes historical versions after deletion.

Removing a keyslot from the live volume does not revoke a passphrase's ability to work with an older header backup. If you deliberately retire a passphrase, securely delete every header backup made while that passphrase was valid, or accept that the old copy remains a recovery path. Secure deletion of files on flash storage, snapshots or remote backup systems may require the controls provided by those systems; a simple rm is not a universal erasure guarantee.

Do not practise luksHeaderRestore against the production device as a verification shortcut. Restoring is a write operation that can replace live metadata and make the current state unusable if the wrong source or backup is selected. Use a disposable test volume and a documented recovery window when you need to rehearse restoration. If a backup is lost, the undo is not another cryptsetup command: preserve the live device, stop destructive changes, and recover from another trusted copy.