Does full-disk encryption protect a running VPS?

No. While the server runs, the disk is unlocked and the key sits in RAM. Anyone with control of the host machine can, in principle, read that memory. Encryption protects data at rest: a copied disk image, an old snapshot, a retired drive.

Can I encrypt the root filesystem of a VPS?

Technically yes, but the server then waits for a passphrase at every boot. You'd type it into the web console, or set up a tiny SSH server in the initramfs. It works, it's fragile, and it protects little extra — encrypting a separate data volume gives most of the benefit with far less pain.

What's better than disk encryption for sensitive data?

Encrypting the data itself before it's written or backed up: encrypted backups with restic, files encrypted with age or GPG, application-level encryption for secrets. That protection travels with the data wherever it's copied.

Are EQVPS backups encrypted?

Yes — Managed Backups are encrypted before they leave the server's host and stay encrypted in storage. They're encrypted with our key, though, because we have to be able to restore them. For data only you should read, encrypt it yourself first.

What happens if I lose the LUKS passphrase?

The data is gone. There's no recovery path — that's the point of encryption. Store the passphrase in a password manager and add a second key slot as a backup.

Full-disk encryption on a VPS: what it really protects

A search for a "privacy-focused VPS with full-disk encryption" usually ends at a checkbox on a pricing page. The checkbox is real, but what it buys you is narrower than the marketing suggests. Before you encrypt anything, it helps to be precise about who you're protecting the data from — because for one important case, disk encryption does nothing at all.

What encryption on a VPS protects — and what it doesn't

A VPS is a virtual machine on someone else's hardware. While it runs, the disk is unlocked and the encryption key lives in the VM's memory. The host machine can, in principle, read that memory. So:

Encryption helps against:

A copy of your disk image or snapshot ending up where it shouldn't.
Old drives being retired after a hardware replacement.
Someone getting access to storage or backups without access to your running server.

Encryption does not help against:

Anyone who controls the running host.
An attacker who gets a shell on your server — to them, the disk is already unlocked.
Legal requests served while the server is up.

That's not a reason to skip it. It's a reason to use it for the right job and not mistake it for invisibility.

Why not encrypt the whole root disk?

You can, but every reboot then stops at a passphrase prompt. You'd unlock it through the web console, or build an SSH server into the initramfs (dropbear) and unlock remotely. Kernel updates now need you present; an unattended reboot means downtime until you log in. For most people the better trade is: system disk as usual, sensitive data on an encrypted volume you unlock after boot.

Set up an encrypted vault in five commands

A LUKS container in a file works on any VPS — no extra disk needed:

apt install -y cryptsetup
fallocate -l 10G /srv/vault.img
cryptsetup luksFormat /srv/vault.img          # set a strong passphrase
cryptsetup open /srv/vault.img vault
mkfs.ext4 /dev/mapper/vault

Mount it and use it:

mkdir -p /mnt/vault && mount /dev/mapper/vault /mnt/vault

After a reboot the vault stays locked until you open it again:

cryptsetup open /srv/vault.img vault && mount /dev/mapper/vault /mnt/vault

Add a second passphrase as a spare key (cryptsetup luksAddKey /srv/vault.img) and store both in a password manager. Lose them and the data is gone for good — no support ticket can bring it back.

Point your sensitive services at /mnt/vault (a database directory, document storage, a password manager's data folder) and make them start only after the vault is mounted.

Often better: encrypt the data, not the disk

Disk encryption stops at the disk. Data you copy elsewhere — backups, exports, syncs — travels unencrypted unless you encrypt it too. Protection that follows the data is usually worth more:

Backups: restic encrypts everything client-side before upload.
Files: age -p secrets.tar > secrets.tar.age encrypts with a passphrase.
Secrets in apps: use the app's own encryption (many password managers, Nextcloud's server-side encryption, database column encryption).

How this looks at EQVPS

We don't ask for ID, we don't sell your data, and we publish a warrant canary. Managed Backups are encrypted before they leave the host and stay encrypted in storage — but with our key, because a backup we can't restore isn't a backup. If you need data that nobody but you can read, encrypt it yourself before it touches the disk. That's true on any server, including ours.

The takeaway

Encrypt a data volume for anything you'd hate to see in a leaked snapshot. Encrypt backups at the source. And don't let a checkbox convince you that a running virtual server is a vault — the strongest privacy tool you have is not keeping data you don't need.