What Is LUKS and Why Encrypt a Server Disk
LUKS (Linux Unified Key Setup) is the standard disk encryption subsystem in Linux built on top of dm-crypt. LUKS encrypts an entire block device: a partition, an LVM volume, or a whole disk, and without the correct key the data on it looks like a random set of bytes. For a rented VDS or a dedicated server this is not an abstract concern: the physical drive at the provider's site is not under the client's full control, it can be removed, replaced during service work, or scrapped with leftover data still on it. LUKS disk encryption removes that risk — without the key the content is unreadable.
It is important to understand the threat model: LUKS protects data at rest — on a powered-off server or on a removed drive. While the server is running and the partition is mounted, data is available in plain form to any process with the right permissions, so LUKS does not replace SSH access hardening or proper permission separation in the system.
Full-Disk Encryption or Encrypting Only the /data Partition — Which to Choose
Full-disk encryption encrypts the entire disk, including the root partition, and requires a password or key to be entered before the system even starts — usually at the GRUB bootloader stage. This is the strongest protection, but on a remote server without IPMI/KVM console access it is risky: if the unlock does not happen automatically, the server will not come up, and you cannot physically walk up and type the password.
A more practical approach for rented VDS and dedicated servers is to encrypt only the partition holding the data, for example /dev/sdb1, mounted as /data. The system boots as usual, and the encrypted partition is opened separately by a script or automatically through crypttab. This approach fits well with ready-made control panels — cPanel or ISPmanager 6 — which do not require the whole system to be under LUKS.
| Option | What Is Protected | Risk on Remote Boot |
|---|---|---|
| Full-disk encryption | Entire OS and data | High without IPMI/KVM |
| Encrypting /data | Only the data partition | Low, OS boots on its own |
| LVM on top of LUKS | Flexible layout of the encrypted volume | Medium, depends on initramfs |
How to Create a LUKS Container: luksFormat and luksOpen in Practice
Before formatting, make sure the partition does not hold data you still need — luksFormat irreversibly destroys everything that was on the device. A minimal working scenario for partition /dev/sdb1:
cryptsetup luksFormat /dev/sdb1
cryptsetup luksOpen /dev/sdb1 data
mkfs.ext4 /dev/mapper/data
mkdir -p /data
mount /dev/mapper/data /data
By default, luksFormat uses AES in XTS mode with a 256-bit key and asks for a passphrase for the first slot. After luksOpen, the device appears at /dev/mapper/data and mounts like a normal partition. You can check the container's parameters with cryptsetup luksDump /dev/sdb1.
How to Set Up Automatic Unlocking on Boot Through /etc/crypttab
Without automation, the server will stop after a reboot at a LUKS password prompt on the console, which is not reachable remotely. An entry in /etc/crypttab like this:
data /dev/sdb1 /root/keys/data.key luks
tells the system to open the partition with the keyfile /root/keys/data.key at boot. The keyfile is added to LUKS as a separate slot: cryptsetup luksAddKey /dev/sdb1 /root/keys/data.key, and the file itself must be kept on protected storage with chmod 400 permissions — if it sits on the same disk with no extra protection, encryption loses its point against removal of the whole server at once.
For a server without physical access, a more reliable option is network-bound disk encryption through Clevis and Tang: the unlock key is automatically fetched over the network from a separate Tang server at boot time, and the disk will not decrypt if the server is physically moved to another network. Setup is done with the clevis luks bind utility after binding the Tang advertisement — details are in the upstream Clevis/Tang project documentation.
How to Back Up the LUKS Header and Manage Key Slots
The LUKS header stores the master key in encrypted form along with slot metadata. If the header is damaged — for example, part of the disk gets overwritten — the data cannot be recovered even if you know the password. A backup is mandatory and should be made before putting the container into production:
cryptsetup luksHeaderBackup /dev/sdb1 --header-backup-file /root/keys/sdb1-header.img
Store the backup file separately from the server — for example, in a secrets storage vault or encrypted with GPG before uploading to external storage. LUKS supports up to 8 key slots, which lets you keep a separate administrator password and a separate keyfile for auto-boot without sharing one common secret:
cryptsetup luksAddKey /dev/sdb1— add a new password or keyfile to a free slotcryptsetup luksRemoveKey /dev/sdb1— remove a specific password from a slotcryptsetup luksKillSlot /dev/sdb1 1— forcibly wipe a slot by its number
Summary: LUKS Encryption Checklist for a Rented Server
Modern CPUs almost always support AES-NI — hardware-accelerated AES, and the encryption overhead usually does not exceed a few percent of disk throughput. You can check for support with grep aes /proc/cpuinfo; without it, encryption noticeably loads the CPU under heavy write volumes.
- Decided whether full-disk encryption is needed or encrypting the
/datapartition is enough - Created the container with
cryptsetup luksFormatand checked it withluksDump - Configured
/etc/crypttabwith a keyfile or Clevis+Tang for auto-boot without console access - Ran
luksHeaderBackupand moved the file off the server - Added separate key slots for the administrator and for automation
- Checked keyfile permissions against basic Linux access rules and factored in AES-NI when choosing a disk