Encrypting a data volume with LUKS2: format, open, crypttab, and what a lost header means

Goal

Encrypt a non-root data partition with LUKS2, mount it automatically at boot, and back up the one piece of state that cannot be recreated: the LUKS header.

Prerequisites

Root; cryptsetup installed. A partition or block device with no data worth keeping unencrypted on it (luksFormat overwrites the area used for the header and destroys any prior filesystem signature there).

Steps

1. Format the device as a LUKS2 volume: cryptsetup luksFormat --type luks2 /dev/sdb1. By default it asks for confirmation (type YES) and a passphrase interactively; for a non-interactive run add --batch-mode and --key-file=/path/to/keyfile, and lock down that file's permissions immediately (chmod 600).
2. Back up the header before writing any data: cryptsetup luksHeaderBackup /dev/sdb1 --header-backup-file /root/sdb1-luks-header.img. Store this file somewhere other than the encrypted device itself (a lost or corrupted header makes the data unrecoverable even with the correct passphrase, since the header holds the encrypted master key). Protect it like a key: it still opens the volume with any passphrase that was valid when it was taken, even after that passphrase is later removed.
3. Open the volume to get a usable mapped device: cryptsetup luksOpen /dev/sdb1 data1 (creates /dev/mapper/data1); format and mount that mapped device as usual, not the raw partition.
4. Add an additional key slot for a second passphrase or a keyfile before relying on a single one: cryptsetup luksAddKey /dev/sdb1 /path/to/keyfile. LUKS2 supports multiple key slots so a lost passphrase does not require re-encrypting, as long as at least one slot's credential is known.
5. For automatic unlocking at boot, add a line to /etc/crypttab: data1 /dev/disk/by-uuid/<uuid> /path/to/keyfile luks. crypttab's four fields are the mapped name, the underlying device, the key file (or none for an interactive passphrase prompt at boot), and options; luks in the options tells the boot-time tooling to expect a LUKS volume rather than plain dm-crypt. A keyfile on an unencrypted root filesystem unlocks the data volume for anyone holding the machine's disks; keep it chmod 600 on an encrypted root. Add nofail in crypttab and fstab if the host must still boot when the volume cannot be unlocked.
6. Add the mapped device to /etc/fstab using /dev/mapper/data1. mount -a only tests fstab; test the crypttab line before rebooting with systemctl daemon-reload and systemctl start systemd-cryptsetup@data1.service (Debian also offers cryptdisks_start data1).

Expected result

cryptsetup status data1 shows the mapping active with the LUKS2 cipher in use; a reboot brings the volume up automatically if crypttab and the keyfile are in place, or prompts for the passphrase at boot otherwise.

Limits and test basis

Verified against cryptsetup(8) (luksFormat, luksHeaderBackup, key slots) and crypttab(5) (four-field format). Nothing here recovers a lost passphrase with no other key slot, or a device whose header is damaged and was never backed up — both are stated by the cryptsetup project as unrecoverable by design, not merely inconvenient.