🔐 Encrypting Linux Disks with LUKS Without Losing Your Data

A laptop gets stolen, a decommissioned drive ends up on eBay, a backup disk falls out of a shipping box — and suddenly your at-rest data is someone else’s. Full-disk encryption is the cheapest insurance against all of it, and on Linux that means LUKS. I’ve run it on everything from edge nodes to backup arrays, and the technology is rock-solid. The danger is never the crypto; it’s the operator who loses the only passphrase or formats the wrong device. This is how I avoid both.

What LUKS actually is

LUKS (Linux Unified Key Setup) is a header format on top of dm-crypt. The clever part is the key layout: your data is encrypted with a single random master key, and that master key is itself encrypted by one or more key slots. Each slot holds a passphrase or keyfile. This indirection is why you can change your passphrase without re-encrypting the whole disk — you’re just re-wrapping the master key in a new slot.

LUKS2 is the current format and the default on modern distros. It supports multiple slots, Argon2 key derivation, and online re-encryption.

Encrypting a new volume

For a fresh data disk (this destroys everything on the target — triple-check the device name):

# Confirm the device first. lsblk shows you the layout.
lsblk
# Format with LUKS2
sudo cryptsetup luksFormat --type luks2 /dev/sdX

It forces you to type YES in capitals and then a passphrase. That capital YES is the kernel saving you from yourself — respect it, and read the device path one more time.

Open it, make a filesystem, mount it:

sudo cryptsetup open /dev/sdX cryptdata   # maps to /dev/mapper/cryptdata
sudo mkfs.ext4 /dev/mapper/cryptdata
sudo mount /dev/mapper/cryptdata /mnt/data

The step everyone skips: back up the header

If the LUKS header is corrupted — a botched dd, a bad sector in the first few MB — your data is gone, even with the right passphrase. The master key lives in that header. So before you put anything on the volume:

sudo cryptsetup luksHeaderBackup /dev/sdX \
  --header-backup-file /root/cryptdata-header.img

Store that backup somewhere off the machine, encrypted itself. I treat the header backup with the same care as the passphrase, because functionally it’s half the key. I have recovered a “dead” encrypted volume from a header backup exactly once, and that one time paid for the habit forever.

Multiple keys, because humans forget

Add a second passphrase or a keyfile so you’re not one forgotten password away from data loss. You authenticate with an existing key to add a new one:

# Add another passphrase to a free slot
sudo cryptsetup luksAddKey /dev/sdX

# Or add a keyfile for automated unlock
sudo dd if=/dev/urandom of=/root/cryptdata.key bs=512 count=4
sudo chmod 400 /root/cryptdata.key
sudo cryptsetup luksAddKey /dev/sdX /root/cryptdata.key

Inspect your slots anytime:

sudo cryptsetup luksDump /dev/sdX

To revoke a key — say an admin left — kill that slot:

sudo cryptsetup luksKillSlot /dev/sdX 1

Auto-unlock at boot for servers

A headless server can’t have someone typing a passphrase at the console every reboot. The clean answer is a keyfile referenced from /etc/crypttab:

# /etc/crypttab
# name        device                          keyfile               options
cryptdata     UUID=<luks-uuid>                /root/cryptdata.key   luks

Get the UUID with sudo cryptsetup luksUUID /dev/sdX, add the mount to /etc/fstab using /dev/mapper/cryptdata, and rebuild your initramfs if the volume is needed early.

The honest tradeoff: a keyfile on the same machine protects against a stolen disk, not a stolen running server. For higher assurance, bind the key to the TPM with systemd-cryptenroll so the disk only unlocks on the trusted hardware:

sudo systemd-cryptenroll --tpm2-device=auto /dev/sdX

Encrypting a disk that already has data

LUKS2 supports in-place encryption, but this is the highest-risk operation in this whole article. Back up first, no exceptions — an interruption mid-conversion can leave the volume in a partial state.

sudo cryptsetup reencrypt --encrypt --reduce-device-size 32M /dev/sdX

The --reduce-device-size makes room for the LUKS header by shrinking the data area. Test the entire procedure on a throwaway volume before you ever run it on real data.

Where AI helps and where it must not

The cryptsetup flag surface is wide and the failure modes are unforgiving, so I do use a model to draft and explain commands — “what does --reduce-device-size do here”, “build me a crypttab entry for TPM auto-unlock.” That’s a great use.

What AI must never do is pick the device for you or run the format. The one command in this article that’s irreversible — luksFormat on the wrong /dev/sdX — is exactly the one a human must own. Read the device path against lsblk with your own eyes, every time. Keep a Linux storage prompt set for the explain-this-command part and keep the destructive command on your own keyboard.

The checklist that keeps you out of trouble

• Confirm the device with lsblk before any luksFormat.
• Back up the LUKS header before writing data, and store it off-box.
• Add a second key (passphrase or keyfile) so one forgotten secret isn’t fatal.
• For servers, decide deliberately between keyfile and TPM auto-unlock.
• For in-place encryption, back up everything and rehearse on a test volume.

The crypto won’t fail you. Process will, if you let it. Follow the checklist and LUKS becomes a quiet, reliable layer you stop thinking about. More foundational Linux ops live in the AI for Linux Admins series.

Disk encryption operations can be irreversible. Verify device paths, back up headers, and test destructive commands on disposable volumes before touching production data.