Re-encrypt a LUKS Volume Safely with cryptsetup reencrypt

cryptsetup reencrypt changes encryption on an existing LUKS volume in place. Used carefully, it can refresh a LUKS2 volume key without changing the passphrase, change the cipher or sector size, encrypt a plaintext device, or remove LUKS2 encryption. This guide covers the safe operational path on the installed cryptsetup 2.7.0.

Allow at least the time needed to read the whole device, plus time for a backup and a controlled recovery test. The command needs root access for ordinary block devices. Have a reliable, tested backup, a maintenance window, console access, and enough free space if you plan to use a data-shifting mode. A failed or interrupted storage migration is not a good problem to discover over an unreachable SSH session.

1. Identify the volume and make a backup

Set a shell variable to the real block device. Do not copy the example path without checking it. The inspection commands are read-only and can be run without sudo if your account can read the device.

DEVICE=/dev/mapper/cryptdata
sudo cryptsetup status "$DEVICE"
sudo cryptsetup luksDump "$DEVICE"
sudo cryptsetup luksHeaderBackup "$DEVICE" --header-backup-file /secure/backup/cryptdata-luks-header.img

For a mapped device, use the underlying LUKS device with the re-encryption command, not an arbitrary filesystem path. Confirm the mapping and header backup before proceeding. A header backup helps recover keyslot metadata, but it is not a replacement for a copy of the data and it does not make a destructive operation reversible.

2. Choose the operation

Plain reencrypt starts LUKS2 re-encryption. With no new data-changing option, the useful common case is a volume-key refresh while existing encryption remains in use. An active LUKS2 mapping gives an online operation; an inactive device is processed offline. LUKS1 is different: its mapping and filesystem must be offline, and the local manpage warns that hardware or kernel failure can lose data.

Use an explicit type when the format matters:

# LUKS2: refresh the effective volume key and keep the existing cipher.
sudo cryptsetup reencrypt --type luks2 "$DEVICE"

# LUKS2: resume an operation already recorded in the header.
sudo cryptsetup reencrypt --resume-only "$DEVICE"

--resume-only is a useful distraction trap: it refuses to start a new operation when no re-encryption is pending. Without it, running the command again is the documented way to resume an initialised or interrupted LUKS2 operation.

3. Stop services before offline work

For offline LUKS2 work, unmount filesystems and stop every process using the volume. For LUKS1, this is mandatory. Check for open users before starting:

sudo findmnt --source "$DEVICE"
sudo lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINTS "$DEVICE"
sudo fuser -vm "$DEVICE"

Do not add --force-offline-reencrypt merely to get past active-device detection. It bypasses that safety check and can destroy data if the volume is active or in use. It is mainly useful for LUKS2 images in files or a known detection failure, after you have independently proved that nothing can access the data.

4. Watch progress and let interruptions recover

Progress can be made easier to monitor, or emitted as JSON for a supervisor:

sudo cryptsetup reencrypt --progress-frequency 10 "$DEVICE"
sudo cryptsetup reencrypt --progress-json "$DEVICE"

For LUKS2, checksum resilience is the default. The journal mode writes the hotzone twice and costs more I/O; none is a performance mode with no interruption protection and is unsuitable for a normal maintenance job. A deliberate Ctrl-C is safe according to the manpage, as is termination during an orderly system shutdown. If the process crashes or the system loses power, activate the volume again so cryptsetup can perform automatic recovery, or run the repair action explicitly:

sudo cryptsetup repair "$DEVICE"
sudo cryptsetup open "$DEVICE" cryptdata

Do not confuse a clean interruption with permission to reboot repeatedly. Keep the machine powered and stable, and resume with the same device. Resilience and hotzone settings may be changed when resuming except for operations using implicit data-shift resilience.

5. Treat encryption and decryption as migrations

In-place encryption begins with plaintext on the device. During the operation, the whole device must be treated as unencrypted. This is a confidentiality boundary, not just a progress detail. A new header can be written to a detached file:

sudo cryptsetup reencrypt --encrypt --type luks2 \
  --header /secure/cryptdata-luks2.header /dev/mapper/plaindata

The command may ask for a new passphrase and will process the data in place. If you use --reduce-device-size 32M for LUKS2 encryption, the final 32 MiB is sacrificed to make room for the metadata arrangement. That loss is destructive and cannot be undone. Use it only after checking the device layout and confirming that the area is disposable.

LUKS2 decryption is equally destructive from a confidentiality perspective. If the header is at the head of the data device, export it to a file that is not stored on the device being decrypted:

sudo cryptsetup reencrypt --decrypt \
  --header /secure/exported-original-luks2.header /dev/mapper/cryptdata

The destination header file must not already exist when this decryption is initialised. Never put it on a filesystem backed by the device being decrypted, because that can deadlock the migration. If you need the data available quickly after initialisation, the optional new mapping name for encryption activates only after encryption initialisation, not after the entire data area has finished.

6. Verify the result

After the command reports completion, inspect the metadata and open the volume using the intended passphrase. Check the filesystem separately, then compare representative files with the backup. A successful cryptsetup exit proves that the metadata operation completed; it does not prove that an application-level backup is complete.

sudo cryptsetup luksDump "$DEVICE"
sudo cryptsetup status cryptdata
sudo cryptsetup open "$DEVICE" cryptdata-check
sudo mount -o ro /dev/mapper/cryptdata-check /mnt/cryptdata-check
sudo umount /mnt/cryptdata-check
sudo cryptsetup close cryptdata-check

With a detached header, supply --header /secure/cryptdata-luks2.header to both the inspection and open commands. Store that header backup separately and protect its permissions: it contains the metadata needed to attack or restore the volume.

Done means

• The device, LUKS version and intended mode were confirmed before writing.
• A tested data backup and a separate LUKS header backup exist.
• No filesystem or process used the device during offline work.
• The operation completed or resumed cleanly, with recovery handled if needed.
• luksDump, a read-only mount, and representative file checks match the plan.