How to encrypt a disk on your VPS with LUKS2
6 min readUpdated 28 Oct 2026
Encrypt an extra disk or a container file on your KVM VPS with LUKS2: install, unlock after reboot, passphrases and header backup.
LUKS2 is the standard way to encrypt disks on Linux. Data written to an encrypted disk is unreadable without your passphrase, so a copied disk image, an old backup or storage from a terminated server shows only random data. This guide sets it up on a VPS from jetguard running Debian or Ubuntu. The same commands work on AlmaLinux, Rocky and other distributions that ship cryptsetup.
What encryption protects, and what it does not
- It protects data at rest: disk images, snapshots, backups and the disk after your service ends. Without the passphrase the data cannot be read, by anyone.
- It does not protect a running, unlocked server. While the volume is open, the key is in the server's memory and the files are readable by anyone who can log in. Keep SSH locked down (keys only, no password login) and lock the volume when you do not need it.
- There is no recovery. If you lose the passphrase and the header backup, the data is gone. We cannot open it for you, and that is the point.
Pick an approach
- A. Encrypt an extra disk (recommended). Order an Extra disk from the Disks card of your VPS (10 GB to 100 GB, it can be added with the server running or powered off). The operating system stays on the main disk and your private data lives on the encrypted one. This is the simplest and safest setup.
- B. An encrypted container file on the main disk. No extra disk needed; good for a few gigabytes of sensitive files.
- C. The whole system disk. Only possible when the operating system is installed with encryption from the start, and you then type the passphrase at every boot from the VNC console in the panel. Converting a running system disk in place is risky and not covered here.
1. Install cryptsetup
Debian and Ubuntu:
sudo apt update
sudo apt install -y cryptsetup
AlmaLinux, Rocky, CentOS Stream:
sudo dnf install -y cryptsetup
Check the CPU acceleration. Our KVM servers run on AMD EPYC or Intel Xeon processors. Both have AES instructions built in (AES-NI), so encryption works the same on either and costs very little speed. Confirm your server sees them:
grep -m1 -o -w aes /proc/cpuinfo
If it prints aes, you are set. Then look at the actual speed:
cryptsetup benchmark
The aes-xts lines should show well over 1000 MiB/s. If the first command prints nothing, open a ticket so we can check the server; meanwhile you can add --cipher xchacha20,aes-adiantum-plain64 to the luksFormat commands below, a cipher designed to be fast without AES instructions.
2. Option A: encrypt the extra disk
Find the disk. The extra disk is the one with no partitions and nothing mounted, usually /dev/vdb (on some servers /dev/sdb):
lsblk
Double check the name. The next command erases everything on that disk. Never run it on /dev/vda or /dev/sda, which is your system disk.
Create the LUKS2 volume. Type YES in capitals when asked, then choose a long passphrase (a sentence of five or more random words works well):
sudo cryptsetup luksFormat --type luks2 --pbkdf argon2id /dev/vdb
Open it, create a filesystem and mount it:
sudo cryptsetup open /dev/vdb secure
sudo mkfs.ext4 -L secure /dev/mapper/secure
sudo mkdir -p /mnt/secure
sudo mount /dev/mapper/secure /mnt/secure
secure is just a name; you can pick another one. Everything you save under /mnt/secure is now encrypted on disk.
Check it:
sudo cryptsetup status secure
lsblk -f
The status shows type: LUKS2 and the cipher, usually aes-xts-plain64 with a 512 bit key.
3. Unlocking after a reboot
After a restart the volume is locked again. Unlock and mount it by hand:
sudo cryptsetup open /dev/vdb secure
sudo mount /dev/mapper/secure /mnt/secure
Optional: shorter commands with crypttab and fstab. Get the disk's UUID, which stays the same even if the disk name changes:
sudo blkid -s UUID -o value /dev/vdb
Add one line to each file, replacing YOUR-UUID with the value above:
echo 'secure UUID=YOUR-UUID none luks,noauto' | sudo tee -a /etc/crypttab
echo '/dev/mapper/secure /mnt/secure ext4 defaults,noauto,nofail 0 2' | sudo tee -a /etc/fstab
From now on, unlocking is:
sudo cryptdisks_start secure
sudo mount /mnt/secure
With noauto the server boots normally and the volume stays locked until you run these commands. nofail makes sure a missing disk never blocks the boot.
Optional: type the passphrase at boot from the VNC console. If you want the disk opened and mounted during boot, so that services using it (a database, a website) start on their own, remove noauto from both lines. The server then stops early in the boot and asks for the passphrase. Click Open console on your VPS page, type it and press Enter; the boot carries on. Until you do, the server does not answer on the network, so only use this if you can reach the panel after every reboot. Keep nofail so a wrong or missing disk never leaves the system unbootable.
Why not unlock automatically with a key file? The key file would sit on the unencrypted system disk, so anyone holding a copy of that disk could open your data too. If you want the server to come back fully on its own after a reboot, that is the trade off; for private data, unlock by hand.
4. Option B: an encrypted container file
This creates a 10 GB file that works like an encrypted disk. Change the size to what you need, as long as it fits in your free space (df -h):
sudo fallocate -l 10G /root/vault.img
sudo cryptsetup luksFormat --type luks2 --pbkdf argon2id /root/vault.img
sudo cryptsetup open /root/vault.img vault
sudo mkfs.ext4 -L vault /dev/mapper/vault
sudo mkdir -p /mnt/vault
sudo mount /dev/mapper/vault /mnt/vault
After a reboot, open it again with the last two lines of commands: cryptsetup open and mount.
5. Lock the volume when you are done
sudo umount /mnt/secure
sudo cryptsetup close secure
For the container, use /mnt/vault and vault. Once closed, the data cannot be read until the passphrase is entered again.
6. Passphrases and the header backup
LUKS2 has several key slots, so you can have more than one passphrase (for example, a second one kept offline as a spare).
sudo cryptsetup luksAddKey /dev/vdb
sudo cryptsetup luksDump /dev/vdb
luksDump lists the slots in use. To change a passphrase, add the new one first and then remove the old one:
sudo cryptsetup luksRemoveKey /dev/vdb
Back up the header. The first megabytes of the volume hold the encrypted keys. If they are damaged, the data cannot be recovered even with the right passphrase. Save a copy, move it off the server and delete it from the server:
sudo cryptsetup luksHeaderBackup /dev/vdb --header-backup-file /root/secure-header.img
From your own computer:
scp root@YOUR-SERVER-IP:/root/secure-header.img .
Then on the server:
sudo shred -u /root/secure-header.img
Keep the backup somewhere safe: together with any passphrase that was valid when you made it, it opens the volume.
Good to know
- Lost passphrase means lost data. Store it in a password manager.
- Removing the extra disk from the panel deletes it and its data for good.
- Growing a volume: after enlarging the underlying disk, run
sudo cryptsetup resize secureand thensudo resize2fs /dev/mapper/secure. - Stuck at boot? If the server does not come up after editing
/etc/crypttabor/etc/fstab, open the VNC console from the panel to see what it is waiting for.
Questions? Open a ticket or write to us on Telegram at @HostAgent_Bot.
