How to Back Up and Restore a LUKS Header in Linux

A corrupted LUKS header—or a bad luksKillSlot—can brick an otherwise healthy encrypted partition. Your file backup does not fix that; you need a copy of the header and key slots from when the volume still unlocked cleanly. cryptsetup luksHeaderBackup writes that metadata to a file; luksHeaderRestore writes it back when the on-disk header is damaged.

Examples use the lab LUKS2 partition /dev/sdc1 from encrypt a disk partition with LUKS. Substitute your LUKS device name in every command.

Tested on: Ubuntu 26.04 LTS (Resolute Raccoon); kernel 7.0.0-27-generic; cryptsetup 2.8.4.

What you need on your system

Before luksHeaderBackup or luksHeaderRestore, identify these on your host:

Also confirm:

• Close the mapper before luksHeaderRestore—restore overwrites on-disk LUKS metadata. For luksHeaderBackup, closing the mapper is conservative but not usually required; avoid backup while another key-slot operation is running.
• Your backup filename includes the LUKS UUID so you do not restore onto the wrong disk later.
• You take a fresh header backup after every successful luksChangeKey, luksKillSlot, or major disk migration (for example root PV migration onto LUKS).

What the LUKS header contains

On LUKS2, metadata and key slots occupy the start of the partition; the encrypted payload usually begins at byte offset 16777216 (16 MiB).

The header holds:

• Encryption parameters (cipher, key size, LUKS UUID).
• Key slots that wrap the volume key with a passphrase, key file, or token. LUKS1 supports up to 8 key slots; LUKS2 can support up to 32 depending on keyslot area size and key size.
• Not your ext4/xfs files—the payload stays on the partition; the backup is only the metadata region.

A header backup is a byte-for-byte copy of that metadata area. luksHeaderBackup does not read your filesystem blocks.

Quick reference

Close any mapper on the partition before restore (sudo cryptsetup close mapper_name). Restore overwrites on-disk metadata—confirm partition name and backup UUID first.

Back up the header

Identify your LUKS partition with lsblk before you run luksHeaderBackup on the partition, not /dev/mapper/*:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT /dev/sdc

NAME        SIZE TYPE  FSTYPE      MOUNTPOINT
sdc           5G disk
└─sdc1        5G part  crypto_LUKS

For a normal backup, you can back up the LUKS header while the volume is open. If you want a quiet maintenance-state backup, unmount and close it first—the same close sequence as in mount LUKS at boot:

sudo umount /mnt/secure-data 2>/dev/null
sudo cryptsetup close secure_data 2>/dev/null

Run the backup (use your partition path and a filename that includes the UUID):

sudo cryptsetup luksHeaderBackup --header-backup-file luks-header-5f452b2f.img /dev/sdc1
sudo chmod 600 luks-header-5f452b2f.img

Do not leave the only copy of this file inside /mnt/secure-data or any filesystem stored inside the same LUKS volume.

Privileged steps below assume sudo command on a root-capable shell.

Check the file size:

ls -l luks-header-5f452b2f.img
stat -c '%s bytes' luks-header-5f452b2f.img

On many default LUKS2 volumes, the backup is 16777216 bytes (16 MiB). Do not rely on that size for every system—custom LUKS2 metadata, keyslot size, or detached-header layouts can differ:

-r-------- 1 root root 16777216 Jul  5 19:10 luks-header-5f452b2f.img
16777216 bytes

file recognizes the format:

file luks-header-5f452b2f.img

luks-header-5f452b2f.img: LUKS encrypted file, ver 2, header size 16384, ... UUID: 5f452b2f-3b11-4494-890b-d6c3e509c0ef, ...

Inspect the backup without touching the disk:

sudo cryptsetup luksDump luks-header-5f452b2f.img

LUKS header information
Version:       	2
UUID:          	5f452b2f-3b11-4494-890b-d6c3e509c0ef
...
Data segments:
  0: crypt
	offset: 16777216 [bytes]

Confirm the on-disk UUID matches:

sudo cryptsetup luksUUID /dev/sdc1

5f452b2f-3b11-4494-890b-d6c3e509c0ef

Store the backup off the encrypted disk—another machine, offline media, or an encrypted archive.

When to take a header backup

Take a header backup:

• Immediately after luksFormat on a new volume.
• Before luksChangeKey, luksAddKey, or luksKillSlot.
• Before risky operations (resize LUKS, partition moves, or pvmove during root encryption migration).
• After any successful key-slot change—so the spare metadata matches what is on disk today.

For day-to-day cryptsetup syntax, keep the cryptsetup command cheat sheet open while you work.

Passphrase changes and header backup

luksChangeKey re-wraps the same volume key in a key slot. It does not re-encrypt your files. The lab below uses a throwaway loop partition (/dev/loop29p1); the behavior is the same on your LUKS device.

The printf examples are for a disposable lab device only. On a real disk, enter passphrases interactively so they are not visible in shell history, terminal scrollback, process arguments, or copied notes.

Back up first, then rotate:

sudo cryptsetup luksHeaderBackup --header-backup-file header-before-change.img /dev/loop29p1
printf '%s\n%s\n%s\n' 'old-pass' 'new-pass' 'new-pass' | sudo cryptsetup luksChangeKey /dev/loop29p1

Test which passphrase the live device accepts:

printf '%s\n' 'old-pass' | sudo cryptsetup open --test-passphrase /dev/loop29p1

No key available with this passphrase.

printf '%s\n' 'new-pass' | sudo cryptsetup open --test-passphrase /dev/loop29p1

The second command exits silently when the new passphrase works.

What this means for your backup:

• A header backup taken before rotation still reflects old key slots—you can open with that file and the old passphrase using a detached header (next section).
• If a rotation goes wrong, luksHeaderRestore from the pre-change backup returns metadata to the saved state—only if a passphrase valid for that backup still exists.
• Take a fresh header backup after every successful change.

For volume-key re-encryption (not just passphrase re-wrap), read change LUKS passphrases and reencrypt and back up the header again before you start.

Restore a damaged header

When luksDump fails on the partition but the encrypted payload is intact, restore from your backup file.

The lab corrupts the first megabyte of a throwaway loop LUKS partition, then restores:

sudo cryptsetup luksHeaderBackup --header-backup-file header-pre.img /dev/loop29p1
sudo dd if=/dev/zero of=/dev/loop29p1 bs=1M count=1 conv=notrunc status=none
sudo cryptsetup luksDump /dev/loop29p1

Device /dev/loop29p1 is not a valid LUKS device.

sudo cryptsetup luksHeaderRestore --header-backup-file header-pre.img /dev/loop29p1
printf '%s\n' 'your-passphrase' | sudo cryptsetup open --test-passphrase /dev/loop29p1

The test-passphrase step exits silently when restore succeeded.

On your production partition, confirm the backup belongs to that device, close any mapper, then restore (example /dev/sdc1):

sudo cryptsetup luksDump luks-header-5f452b2f.img | grep UUID
sudo cryptsetup luksUUID /dev/sdc1 2>/dev/null || true

If the on-disk header is damaged, luksUUID /dev/sdc1 may fail. Rely on your filename, inventory notes, and backup records before restoring.

sudo cryptsetup close secure_data 2>/dev/null
sudo cryptsetup luksHeaderRestore --header-backup-file luks-header-5f452b2f.img /dev/sdc1

luksHeaderRestore overwrites on-disk LUKS metadata. Before you confirm:

• Partition path matches the backup UUID (luksDump on the backup file).
• Backup predates any luksChangeKey you intend to keep—or you accept rolling back to older key slots.

Use batch mode only in scripts after manual verification:

sudo cryptsetup -q luksHeaderRestore --header-backup-file luks-header-5f452b2f.img /dev/sdc1

After restore, unlock with a passphrase valid for the restored header, then run sudo fsck -f /dev/mapper/name if the filesystem was not cleanly unmounted.

Detached header (--header)

Some layouts store the LUKS header on separate media. On a standard single-partition setup, you can point cryptsetup at a header backup file instead of the on-disk copy—the backup file supplies metadata and the partition supplies ciphertext. Useful when the on-disk header is damaged but the backup is intact.

Confirm the backup UUID before you open with --header:

sudo cryptsetup luksDump luks-header-5f452b2f.img | grep UUID

UUID:          	5f452b2f-3b11-4494-890b-d6c3e509c0ef

Match that UUID to your device notes and inventory before opening the partition.

The lab opens a loop partition with the header backup taken before luksChangeKey, using the matching old passphrase:

sudo cryptsetup open --header header-pre.img /dev/loop29p1 rescue_hdr

For read-only rescue—copy data out without writes through the mapper:

sudo cryptsetup open --readonly --header luks-header-5f452b2f.img /dev/sdc1 rescue_hdr

Use --readonly when you only need to copy data out and do not want to risk writes through a restored or detached-header recovery session.

Check the stack:

lsblk -o NAME,TYPE,FSTYPE /dev/loop29

NAME           TYPE  FSTYPE
loop29         loop
└─loop29p1     part  crypto_LUKS
  └─rescue_hdr crypt

sudo cryptsetup status rescue_hdr

/dev/mapper/rescue_hdr is active.
  type:    LUKS2
  cipher:  aes-xts-plain64
  device:  /dev/loop29p1
  offset:  32768 [512-byte units] (16777216 [bytes])

The mapper reads the same ciphertext on the partition; only the metadata source changes. On /dev/sdc1, use the same --header flag with your backup file and partition path. Mount /dev/mapper/rescue_hdr if you need files, then close when finished:

sudo cryptsetup close rescue_hdr

When a header backup cannot help

If every key slot is lost and no backup key file exists, recovery requires a full data backup from before encryption. cryptsetup-reencrypt and header tools assume you can still unlock at least one slot.

Protect the header backup file

The backup exposes key-slot material for offline guessing. An attacker with luks-header.img can run passphrase trials without touching the original disk.

• Store the file outside the encrypted volume it belongs to.
• Restrict permissions (chmod 600 or tighter; root ownership).
• Prefer an encrypted archive or hardware token for long-term storage.
• Do not commit header images to git, ticket attachments, or shared drives without encryption.
• Rotate backups when you change passphrases or retire key slots.
• If you securely retire or wipe a LUKS device, destroy every header backup too—a valid old passphrase plus a kept backup can still unlock the data area.

Losing the header file is less critical than losing the only passphrase, but leaking it weakens the same passphrases that guard your data.

Troubleshooting

References

• cryptsetup FAQ — backup and restore (official)
• Ubuntu man page: cryptsetup(8)
• Linux kernel dm-crypt documentation

Summary

1. Map your LUKS partition and UUID; close the mapper before luksHeaderRestore (not required for normal backup).
2. Run cryptsetup luksHeaderBackup to copy LUKS metadata to a file; chmod 600 and store it offline.
3. Use luksHeaderRestore when on-disk metadata is damaged and the backup UUID matches—unlock with a passphrase valid for that backup.
4. Back up before every luksChangeKey or risky disk operation; refresh the backup after successful changes.
5. A header image never replaces a forgotten passphrase or a full data backup.