Veeam v13: Backup Encryption Best Practices

Veeam encryption is not a single toggle. There are three distinct layers, and each one protects a different part of the data path. You can use any one of them in isolation or stack them together depending on your threat model.

The first is job-level encryption. This encrypts backup data at the source before it ever touches the network or lands on a repository. It is the most common configuration and the one you should be using for any backup that leaves your controlled environment. The second is storage-level encryption, which is configured at the repository rather than the job. This is the right approach when you want encryption to apply to all backups landing on a repository regardless of how the individual jobs are configured - it is also the mechanism that controls encryption for SOBR Capacity Tier offload to object storage. The third is in-transit encryption, which protects the backup data stream as it moves between Veeam components across the network.

The algorithm across all three layers is AES-256. For password-based encryption, Veeam derives the secret key using 600,000 HMAC-SHA256 iterations with a 512-bit salt, following PKCS #5 v2.0. For KMS-based encryption, data encryption keys are protected with RSA-4096. These are not Veeam-specific standards - they are the same algorithms you will find in any serious enterprise security product.

Understanding the key hierarchy matters, especially when you are thinking about password rotation, password loss scenarios, and what happens during a restore. Veeam uses a layered key structure rather than encrypting each backup file directly with your password.

When you set an encryption password, Veeam derives a secret key from that password using PKCS #5. That secret key then encrypts a set of data encryption keys, which are the keys actually used to encrypt the backup data blocks. The data encryption keys themselves are stored in the configuration database, encrypted by the secret key. A new set of data encryption keys is generated for every job session, which means each backup session's data is encrypted with different keys even if the password has not changed.

This design has two important practical consequences. First, changing the password mid-chain creates a situation where different restore points in the same backup chain are encrypted with different user keys - Veeam handles this, but if you are ever importing a backup chain that has had its password changed you need to supply all of the passwords that were ever used. Second, if Password Loss Protection is enabled via Enterprise Manager, an additional copy of the session key is stored in the backup file itself, encrypted with the Enterprise Manager public key. This is the mechanism that allows Enterprise Manager to unlock a backup when the original password is gone.

Job encryption is configured per job in the job wizard. For both greenfield deployments and jobs migrated from v12, the path is the same: reach the Storage step in the backup or backup copy job wizard, click Advanced, and go to the Storage tab within the advanced settings dialog. Check Enable backup file encryption and either select an existing password record or add a new one.

Storage-level encryption is configured at the repository rather than the job. It applies to all backup data written to that repository, regardless of whether the individual jobs have job-level encryption enabled or not. There are two specific scenarios where this is the right configuration.

The first is hardened Linux repositories. When you configure a Linux hardened repository in VBR, you have the option to enable encryption at the repository level. This protects the data at rest independent of any job-level settings. If your hardened repo is also your immutability target, having repository-level encryption means even if someone physically removes the drives they cannot read the data without the key.

The second is SOBR Capacity Tier encryption. When you configure a Scale-Out Backup Repository and add a Capacity Tier (object storage target), there is a separate encryption setting specifically for data being offloaded to object storage. Enable this whenever the object storage target is outside your security perimeter - cloud storage buckets, off-site S3 targets, anything that crosses a trust boundary. If your source jobs are already encrypting, enabling Capacity Tier encryption as well means data gets encrypted twice - once at the job level and again before the upload. The Veeam best practice guide is direct about this: the double encryption has a performance cost and consumes extra compute, so if source jobs are already encrypted and the object storage is adequately secured, you can skip the redundant layer. If source jobs are not encrypted, always enable Capacity Tier encryption before offloading anywhere outside your control.

In-transit encryption protects the backup data stream as it moves between Veeam infrastructure components - proxy to repository, proxy to backup server, and so on. It is not enabled by default and the performance overhead is low on modern hardware, but whether you need it depends on your network topology.

If all Veeam components live on the same isolated management network with no traffic crossing untrusted segments, in-transit encryption is less critical. If backup proxies or repositories are separated from the backup server by a WAN link, a shared network segment, or anything that could be monitored by a third party, turn it on.

Configure it in Configuration > Network Traffic Rules. You can apply network traffic rules globally or per source/target IP range. The setting is labeled Encrypt backup traffic in the rule configuration. Veeam uses TLS for this traffic. The cipher suites and protocol versions supported are documented at helpcenter.veeam.com under Communications Encryption Standards for v13.

Instead of managing encryption passwords manually, you can connect Veeam to an external Key Management Server that speaks KMIP. With KMS integration, Veeam requests keys from the KMS rather than deriving them from a password you store somewhere. The KMS manages key rotation automatically - Veeam only sends requests, it does not hold the master keys.

When a KMS key is used, Veeam protects the data encryption keys with RSA-4096 rather than the AES-256 CBC key derivation used for password-based encryption. The KMS also provides the audit trail: every key request is logged by the KMS, giving you a record of when backups were encrypted and when they were accessed for restore.

KMS configuration lives under Configuration > Key Management Servers. Add your KMIP-compliant KMS server, configure the certificate for mutual TLS authentication, and then select the KMS option when you enable encryption on a job instead of entering a password.

Password Loss Protection is the feature that lets you recover data from an encrypted backup without knowing the original password. It relies on Enterprise Manager and requires the backup server to be connected to a Veeam Backup Enterprise Manager instance.

The way it works: when Password Loss Protection is active, Veeam stores an additional copy of the session key inside every encrypted backup file. That copy is encrypted with the Enterprise Manager public key rather than the user password. If the password is ever lost, you initiate a key restore request from the VBR console. Enterprise Manager receives the request, verifies the requesting backup server is authorized, and issues a response key. The backup server uses that response key to unlock the backup without needing the original password.

Three things to keep in mind here. First, this only works if the Enterprise Manager instance that holds the private key is available. If Enterprise Manager goes down and you have not exported a copy of the active keyset, the mechanism fails. Export keysets regularly and store the exports in a separate secure location. Second, Enterprise Manager itself needs to be backed up. If you lose the EM server and have no backup, you lose the ability to recover via Password Loss Protection. The Enterprise Manager backup should also be encrypted - but make absolutely sure that password is never lost, because there is no Password Loss Protection for Enterprise Manager's own backups. Third, rotate Enterprise Manager keysets regularly. When you activate a new keyset, the public key propagates to all connected backup servers automatically. Old keysets should be retained until all backup chains encrypted under the old public key have been retired.

This one catches people out. The moment you enable job-level encryption in VBR, Veeam automatically disables the configuration backup. It does this because the configuration database contains encryption keys and metadata - sending an unencrypted configuration backup offsite would undermine the protection you just turned on for your job backups.

You need to re-enable the configuration backup with encryption turned on. Go to Configuration > Configuration Backup and check Encrypt configuration backup, then set a password. Once this is done, the configuration backup runs again and includes credentials and key metadata in the encrypted backup. In large environments with many managed servers, application-aware processing configurations, and service accounts, the configuration backup is the difference between a fast restore and spending days manually re-entering everything.

If your repository target is a deduplication appliance - Dell Data Domain, HPE StoreOnce, ExaGrid, or similar - job-level encryption will destroy your dedup ratios. The reason is straightforward: Veeam generates unique data encryption keys for every job session. Two identical data blocks from two different job sessions get encrypted with different keys and produce different ciphertext. The deduplication appliance sees them as unique blocks and cannot deduplicate them. In practice, dedup ratios on an encrypted workload can drop from 3:1 or 4:1 down to 1.1:1 or worse.

The right approach for dedup appliances is to disable job-level encryption and instead use the hardware encryption capability built into the appliance itself. Most enterprise dedup appliances support hardware-accelerated encryption that operates after deduplication, so you get both storage efficiency and encryption. Configure encryption on the appliance directly and disable it on the Veeam job side. This is the documented Veeam recommendation and the correct architecture for this scenario.

If you are offloading to a SOBR Capacity Tier with a dedup appliance as the performance tier, the same logic applies: keep the performance tier unencrypted for dedup efficiency, and enable Capacity Tier encryption separately for the object storage offload target.

If you are upgrading an existing VBR v12 deployment to v13, existing encryption configurations carry over without changes. Jobs that were encrypted in v12 continue to use the same passwords and key hierarchy. No re-keying is required and no new full backups are triggered by the upgrade itself.

The areas worth reviewing post-upgrade are KMS and the REST API. The v13 REST API adds the ability to programmatically check and update encryption passwords, which was not available in v12. If you have a v12 environment where password rotation is manual and error-prone, v13 gives you the tooling to automate that via the REST API or PowerShell. Review the helpcenter.veeam.com/references/vbr/13/rest/ REST API reference for the encryption password management endpoints.

Also review any jobs that were configured to use password-based encryption in v12 and consider whether they should be moved to KMS now that you are on v13. The migration path is straightforward - add your KMS server, update the job encryption setting to use the KMS key instead of the password, and the next job run will re-key under KMS management.

Use this table to map your deployment scenario to the right encryption configuration.