Create, Open and Safely Back Up a LUKS2 Volume with cryptsetup

You will finish with a LUKS2 container formatted on a block device, an active mapping at /dev/mapper/secure_data, and a separate binary header backup. This guide uses cryptsetup 2.7.0 from the installed cryptsetup-bin package. Allow about 20 minutes, excluding the time needed to copy or verify a large backup.

The examples use /dev/EXAMPLE_DEVICE as a placeholder. Replace it only with a device you have positively identified. Every command that changes or reads encrypted-device state needs elevated privileges, so the examples use sudo. The inspection commands do not.

1. Confirm the command and identify the device

Check the installed version and the block devices before touching anything:

$ cryptsetup --version
cryptsetup 2.7.0 flags: UDEV BLKID KEYRING FIPS KERNEL_CAPI HW_OPAL
$ lsblk --output NAME,PATH,SIZE,TYPE,FSTYPE,MOUNTPOINTS

The lsblk output is host-specific. A whole disk and a partition can both look plausible, so check the path, size and current mountpoints against your own inventory. Do not continue until /dev/EXAMPLE_DEVICE identifies the intended, unmounted target.

2. Format the device as LUKS2

Run luksFormat with the explicit LUKS2 type:

$ sudo cryptsetup --type luks2 luksFormat /dev/EXAMPLE_DEVICE

cryptsetup asks you to confirm and then prompts for the initial passphrase. Enter the same passphrase twice. LUKS2 stores a header, key-slot area and encrypted data area; the passphrase protects a key slot rather than directly acting as the volume key. The local manual describes eight key slots, which lets you add or revoke passphrases later.

On success, the command exits with status zero. It normally prints a warning and prompts rather than producing a useful result for a later pipeline. Check that the new header is recognisable:

$ sudo cryptsetup isLuks /dev/EXAMPLE_DEVICE
$ printf 'exit status: %s\n' "$?"
exit status: 0

isLuks returns success for a LUKS device and failure otherwise. It does not unlock the volume and does not prove that your backup is usable.

3. Save a header backup before using the volume

A damaged LUKS header or key-slot area can make the encrypted data permanently inaccessible. Save the binary header backup somewhere separate from the encrypted device:

$ sudo install -m 600 /dev/null /var/tmp/EXAMPLE_DEVICE-luks-header.img
$ sudo cryptsetup luksHeaderBackup /dev/EXAMPLE_DEVICE \
    --header-backup-file /var/tmp/EXAMPLE_DEVICE-luks-header.img
$ sudo ls -l /var/tmp/EXAMPLE_DEVICE-luks-header.img

Choose a destination with enough space and copy the resulting file to protected storage. The backup contains sensitive key-slot material: treat it as confidential and do not leave the only copy on the same physical device. The install command is not required by cryptsetup; it creates an empty, mode-600 destination so an accidental pre-existing file is not silently reused.

4. Open the LUKS2 mapping

Open the container under a memorable mapping name:

$ sudo cryptsetup open /dev/EXAMPLE_DEVICE secure_data
Enter passphrase for /dev/EXAMPLE_DEVICE:

After a successful unlock, the mapped block device is usually /dev/mapper/secure_data. Confirm both the mapping and its cryptsetup status:

$ ls -l /dev/mapper/secure_data
$ sudo cryptsetup status secure_data

The status output is dependent on the kernel and device, but it should identify an active crypt mapping and the backing device. Do not format the original path now. Any filesystem you create must be created on the mapped path, after checking it carefully.

For a new data volume, the next operation might be a filesystem creation command such as mkfs.ext4 /dev/mapper/secure_data. That command is destructive to the mapped contents, so it is intentionally not included as an automatic step here. Choose the filesystem and mount policy for your system first.

5. Close the mapping cleanly

Unmount any filesystem that uses the mapping, stop processes that still have files open, and then close the mapping:

$ sudo cryptsetup close secure_data
$ sudo cryptsetup status secure_data
Device secure_data is not active.

The final message may vary by build, but the status command must report that the mapping is not active or otherwise return a non-zero status for an absent mapping. Closing removes the mapping and wipes its key from kernel memory. If close reports that the device is busy, inspect mounts and open files before trying again:

$ findmnt --source /dev/mapper/secure_data
$ sudo fuser -vm /dev/mapper/secure_data

Do not force a close while applications are still writing. Resolve the mount or process holding the device, then retry the ordinary close command.

6. Handle the common mistakes

• Wrong passphrase: LUKS checks the passphrase and refuses to open the device. Check keyboard layout and special characters before changing anything. The manual recommends 7-bit ASCII for passphrases when encoding changes are a concern.
• Wrong device: stop immediately. Re-run lsblk and compare stable identifiers, size and connection details. Do not guess based only on /dev/sdX, because device names can change between boots.
• Missing backup: do not assume a successful format is recoverable. Create the header backup before adding data or changing key slots.
• Plain dm-crypt temptation: plain mode has no metadata, no key slots and no passphrase validity check. Unless you understand its operational and cryptographic constraints, use LUKS2 instead.