LUKS (Linux Unified Key Setup) is the standard way to encrypt block devices on Linux. Everything written to an encrypted volume is unreadable without the key. That protects data on disks that are removed, replaced, decommissioned or stolen. On servers it’s most useful for data disks on dedicated servers, and for storage that holds sensitive data such as backups and customer files.

What encryption at rest does, and doesn’t, do

Protects against:

  • someone reading a disk that has left your control (an RMA’d drive, a decommissioned server, theft);
  • offline access to the raw disk.

Doesn’t protect against:

  • attackers who get into the running system. The volume is unlocked while mounted, and files are readable like any others;
  • application vulnerabilities, stolen SSH keys, or misconfigured permissions.

Keep that in mind. LUKS is one layer, not a replacement for server hardening. On a VPS, the provider’s host can access guest memory, so encryption inside a VPS guards mainly against storage-level exposure.

Install

sudo apt install cryptsetup      # Debian/Ubuntu
sudo dnf install cryptsetup      # RHEL family

Encrypt a new data disk

This erases the target. Identify it carefully with lsblk -f. See lsblk.

# 1. Create the LUKS2 container (asks for a passphrase; type YES to confirm)
sudo cryptsetup luksFormat --type luks2 /dev/vdb1

# 2. Open it: creates /dev/mapper/securedata
sudo cryptsetup open /dev/vdb1 securedata

# 3. Create a filesystem inside and mount it
sudo mkfs.ext4 -L securedata /dev/mapper/securedata
sudo mkdir -p /srv/secure
sudo mount /dev/mapper/securedata /srv/secure

Check it:

sudo cryptsetup status securedata
lsblk -f            # vdb1 shows TYPE crypto_LUKS with securedata inside

Close it when not in use:

sudo umount /srv/secure
sudo cryptsetup close securedata

Unlock at boot

Option A: passphrase at boot (most secure, needs the console)

/etc/crypttab:

securedata  UUID=<uuid-of-vdb1>  none  luks

/etc/fstab:

/dev/mapper/securedata  /srv/secure  ext4  defaults,nofail  0  2

Get the UUID with sudo blkid /dev/vdb1. At boot, the system asks for the passphrase on the console. For a remote server, that means using the VNC console at every reboot, or setting up remote unlock (dropbear-initramfs, which lets you SSH into the initramfs to enter the passphrase).

nofail stops the boot from hanging if the volume isn’t unlocked. See fstab.

Option B: key file (automatic, less protection)

sudo dd if=/dev/urandom of=/root/.securedata.key bs=512 count=8
sudo chmod 400 /root/.securedata.key
sudo cryptsetup luksAddKey /dev/vdb1 /root/.securedata.key

/etc/crypttab:

securedata  UUID=<uuid>  /root/.securedata.key  luks

The key file lives on the (unencrypted) root disk, so this protects the data disk only if it’s separated from the root disk, for example a drive pulled for RMA. It still beats an unencrypted disk for decommissioning scenarios.

Network-bound unlocking (Clevis + Tang) is a middle ground. The disk unlocks automatically only when the server can reach a key server on your network.

Key slots: add, remove, back up

LUKS has up to 32 key slots. Each holds a passphrase or key file that can unlock the volume:

sudo cryptsetup luksDump /dev/vdb1            # header info and used slots
sudo cryptsetup luksAddKey /dev/vdb1          # add a second passphrase (e.g. recovery)
sudo cryptsetup luksRemoveKey /dev/vdb1       # remove one (asks which passphrase)
sudo cryptsetup luksChangeKey /dev/vdb1       # change a passphrase

Back up the LUKS header. If the header gets corrupted, the data is lost for good, even with the right passphrase:

sudo cryptsetup luksHeaderBackup /dev/vdb1 --header-backup-file /root/vdb1-luks-header.img

Store the header backup and the passphrases off the server, securely (a password manager, offline storage).

Performance

Modern CPUs encrypt with AES-NI hardware acceleration. The overhead is usually a few percent, and hard to notice except on very fast NVMe arrays. Check:

grep -m1 -o aes /proc/cpuinfo
cryptsetup benchmark

Encrypt existing data

LUKS can’t encrypt a filesystem in place safely in general (cryptsetup reencrypt exists, but it’s risky without backups). The practical way:

  1. Back up the data.
  2. Format the disk as LUKS (as above).
  3. Restore the data into the encrypted filesystem.

Alternatives

  • Encrypted backups (gpg, restic, Borg) protect data where it’s stored off-site. That’s often the most valuable encryption for a VPS. See GPG encryption.
  • Application or database-level encryption for specific sensitive fields.
  • ZFS native encryption per dataset. See ZFS.

Quick reference

Task Command
Create cryptsetup luksFormat --type luks2 /dev/vdb1
Open cryptsetup open /dev/vdb1 name
Close cryptsetup close name
Status cryptsetup status name
Add key cryptsetup luksAddKey /dev/vdb1 [keyfile]
Header backup cryptsetup luksHeaderBackup /dev/vdb1 --header-backup-file f
Boot unlock /etc/crypttab + fstab

Related: mkfs and secrets management.

  • Security
  • Storage
  • Encryption