LUKS2 backup volumes: key rotation and read-only recovery drills

The backup files are on disk, and the account receiving them has been isolated. But whether someone can still read data directly from retired disks or offline copies is a separate security boundary. Volume encryption protects data while the volume is locked; it does not replace online access controls. Rotating passphrases can revoke old credentials, but it cannot undo a data leak that has already happened. This article rehearses LUKS2 key rotation and recovery in a standalone file container, without touching existing data disks.

1. Define what encryption protects

OnuCloud dedicated servers come with two 1 TB NVMe drives, each directly attached, with no hardware RAID. Volume encryption, disk redundancy, and off-site backups address different problems: encryption restricts offline reads, while the other two address device failure and independent copies, respectively. Encrypting both drives does not automatically create a recoverable backup.

The following example uses Ubuntu Server 24.04 LTS and requires administrator privileges, cryptsetup, e2fsprogs, and approximately 256 MiB of actual free space. Install the required tools through the distribution's package manager first, then open a dedicated administrator shell. Run all subsequent commands in that same shell so the variables remain available.

An unlocked volume is still readable by processes with the appropriate permissions. Volume encryption cannot prevent the misuse of administrator privileges, nor does it automatically make a copy of a database that is still being written to application-consistent.

Before deploying this in production, establish who holds the passphrases, who can read header backups, and how access will be revoked when personnel change. Do not put passphrases in command arguments, scripts, or ticket bodies.

2. Create a practice volume without touching real disks

mktemp creates a separate working directory, and every formatting operation targets only the new file inside it. Before running the commands, check that the mapping name backup-drill is not already in use. If it exists, stop and investigate; do not close an unknown mapping. This example uses interactive passphrase entry, with the initial passphrase assigned to slot 0.

umask 077
work=$(mktemp -d /var/tmp/luks-drill.XXXXXX)
image="$work/backup.img"
mountpoint="$work/mnt"
mkdir "$mountpoint"
truncate -s 256M "$image"
cryptsetup luksFormat --type luks2 --key-slot 0 "$image"
cryptsetup open "$image" backup-drill
mkfs.ext4 /dev/mapper/backup-drill
mount /dev/mapper/backup-drill "$mountpoint"
printf 'backup-recovery-check\n' > "$mountpoint/probe.txt"
(
  cd "$mountpoint"
  sha256sum probe.txt
) > "$work/expected.sha256"
sync
umount "$mountpoint"
cryptsetup close backup-drill

Run each command only after the previous one succeeds. In particular, never proceed with formatting after an unlock failure, and never replace the file path with an unverified NVMe device name. A sparse file's apparent size is not the same as its actual disk usage; make sure the hosting filesystem has enough free space throughout the drill.

The checksum manifest is stored outside the container so it can serve as an independent reference during recovery. In production, the manifest also needs a trusted source. If both the data and the manifest can be tampered with, matching hashes alone do not establish trustworthy provenance.

3. Verify the new slot before revoking the old passphrase

First, run cryptsetup luksDump "$image" and confirm that the type is LUKS2, slot 0 is enabled, and slot 1 is free. A real volume may have a different slot layout, so do not reuse these slot numbers without checking. When adding the new passphrase below, first enter the old passphrase to authorize the operation, then set the new one when prompted.

cryptsetup luksAddKey --key-slot 1 "$image"
cryptsetup open --test-passphrase --key-slot 1 "$image"
cryptsetup luksDump "$image"

Enter the new passphrase for the second command. Verification succeeds only if the exit code is 0. The --test-passphrase option only tests unlocking; it does not create a mapping and therefore does not affect the filesystem's mount state. Adding a slot does not change the volume key or re-encrypt all the data.

Once you have confirmed that authorized personnel have securely stored the new passphrase, delete slot 0. In this drill, authorize deletion with the new passphrase that will remain valid:

cryptsetup luksKillSlot "$image" 0
cryptsetup open --test-passphrase "$image"

For the last command, enter the old passphrase first; it should fail. Then run the command again and enter the new passphrase; it should succeed. Do not mask failures with automatic retries, and do not declare rotation complete based only on the slot list. The acceptance evidence should include the slot changes and both test results, but not the passphrases themselves.

4. Treat header backups as sensitive access material

The LUKS header stores critical metadata needed to unlock the volume. If the data area is intact but the header is damaged, a header backup may be necessary for recovery. It is not a copy of the data, and it must not be lost along with the only data volume. After successful rotation, export the current header:

cryptsetup luksHeaderBackup "$image" \
  --header-backup-file "$work/header-current.bin"
chmod 600 "$work/header-current.bin"
cryptsetup luksDump "$image" > "$work/luks-layout.txt"

Directory and file permissions restrict access only on the local system. Production header backups should be kept in a separate, controlled storage location. Record the corresponding volume, rotation batch, and authorized personnel, and establish a clear association with the relevant data copies. Do not send a header file as an ordinary diagnostic attachment.

Historical versions need particular attention: an old header may retain revoked slots, and restoring it may make an old passphrase valid again. Deleting an old slot from the current volume therefore does not revoke every means of access retained in historical material. If the threat involves a leaked volume key, changing passphrases alone is insufficient; plan re-encryption or migration separately.

5. Verify file contents during read-only recovery

The practice volume has been cleanly unmounted. You can now create a read-only mapping and mount the ext4 filesystem read-only without replaying its journal. These two layers constrain block-device and filesystem behavior, respectively.

cryptsetup open --readonly --key-slot 1 "$image" backup-drill
mount -t ext4 -o ro,noload /dev/mapper/backup-drill "$mountpoint"
findmnt -no SOURCE,FSTYPE,OPTIONS "$mountpoint"
(
  cd "$mountpoint"
  sha256sum -c "$work/expected.sha256"
)
touch "$mountpoint/should-not-exist"

After you enter the new passphrase, the mount options should include ro, the checksum verification should succeed, and the final write attempt should fail. If the write succeeds, stop the acceptance check immediately and inspect the actual mount target; do not dismiss it as an unrelated anomaly. Do not use noload to conceal a dirty filesystem. If a copy was not cleanly unmounted, preserve the original first and assess repairs on a working copy.

When finished, unmount the directory, then close the mapping. Confirm that no mounts or mappings remain before cleaning up the practice directory. Manage production materials under the established retention and custody rules rather than including them in temporary-file cleanup.

The final record should answer four questions: can the new passphrase unlock the volume on its own, does the old passphrase fail, is the header backup under controlled custody, and do the recovered files match a trusted manifest? Only when all four checks pass does the exercise constitute a key rotation and recovery drill that can be reviewed later.

Frequently asked questions