PBS setup and operations: WZ-IT supports the agreed backup architecture with Proxmox Backup Server. A restore test also checks key access for the selected recovery path.
As of October 2026.
Contents
- PBS or vzdump
- Enable encryption
- Store and map keys
- Recover with the saved key copy
- Verify and protection against deletion
- Sources
PBS or vzdump
PBS supports optional client-side AES-256-GCM encryption. For PVE integration, add PBS storage under Datacenter. Transport encryption does not replace additional content encryption.
This article covers PBS keys. For vzdump files on a mounted share, the existing encrypted backups on Hetzner Storage Box guide describes a separate method using gocryptfs. Treat these as different storage configurations.
Enable encryption
Review the existing PBS storage, datastore and backup scope. PVE storage encryption can be configured through the interface or encryption-key. The official PBS storage documentation source documents autogen for generation and /etc/pve/priv/storage/<STORAGE-ID>.enc for storage. The PVE integration uses key files without password protection there. Protect host access as well.
For an already connected new PBS storage without an existing key, using the example ID pbs-encrypted, enable encryption before the first backup. The pvesm synopsis documents the command and autogen:
pvesm set pbs-encrypted --encryption-key autogen
Replace the example ID with the reviewed storage entry. Do not use this example to overwrite an existing key. Then store the generated key file separately, run a backup job to this storage and inspect the new snapshot.
For the standalone backup client, such as file backups outside PVE guest backups, the client documentation describes a different procedure:
proxmox-backup-client key create /secure/path/backup.key
Assign this key to the client invocation with --keyfile. A password is requested by default. This is not an instruction to replace the existing PVE storage key. After changing configuration, create a new snapshot and check its encryption state and key mapping; existing snapshots are not rewritten retroactively.
Store and map keys
Maintain a key inventory with storage ID, fingerprint, backup period, custody location and authorised people. Keep keys out of assessment reports. Store an access-controlled copy outside the backed-up host and test emergency access to its location.
The client manual documents key paperkey for a printable copy and key create-master-key and key import-with-master-key for optional RSA recovery. The public master key alone is insufficient: keep the private part separately available. Retain old keys while any retained snapshot still needs them.
Recover with the saved key copy
Plan an isolated PBS restore test and deliberately use the independent key copy. Record the snapshot, key fingerprint, access result and application checks. Testing only with the still-functioning original host does not address its total loss.
After a key change, test an old snapshot as well. Record missing key access as an unresolved finding even when backup and verify jobs succeed. Without decryptable data, the recovery path has not been demonstrated.
Verify and protection against deletion
For encrypted chunks, a server without the key can check only CRC-32, not the plaintext against its checksum (technical overview). Verify replaces neither decryption checks nor application startup.
Treat deletion privileges, retention and offsite backups as separate review items. Encryption alone does not prevent deletion. Likewise, a separately stored key is useful only if the authorised person can actually access it in an emergency.
Have key access checked: Define the snapshot and acceptance criteria for a Proxmox restore test. For setup and ongoing backup operations: PBS services.
