Keep Your Proxmox Restore Key Outside the Backup Chain

An encrypted backup can remain intact yet be unusable. If the only decryption key disappears with the system you need to restore, the backup server cannot recover the protected data. Proxmox therefore recommends keeping encryption keys separate from the contents being backed up (Proxmox VE PBS storage documentation).

Here, “separate” means more than another directory on the same host. You need a recovery path that remains available without the original Proxmox VE client—and without services that must themselves be restored before you can retrieve the key.

Evidence scope: This is a documentation-based explanation of Proxmox Backup Server encryption and recovery semantics, not a hands-on or destructive restore test. The cited pages were retrieved on September 12, 2026, and display different Proxmox documentation versions.

The basic recovery dependency

Proxmox VE’s Proxmox Backup Server integration supports optional client-side encryption using AES-256 in GCM mode (Proxmox VE PBS storage documentation). A simplified encrypted-restore chain contains:

The Proxmox VE client that creates the backup.
The encrypted backup data stored on Proxmox Backup Server.
The encryption key needed to decrypt that data.

Preserving the datastore does not necessarily preserve the key. In the Proxmox VE integration, the ordinary encryption key is stored on the Proxmox VE side. If that client holds the only copy and becomes unavailable, the workload and its means of recovery can disappear together. Proxmox explicitly warns that encrypted backups are inaccessible without their key and that restoration may become impossible when the key is lost with the failed system (Proxmox VE PBS storage documentation).

Key custody is therefore part of restore design, not merely a question of where to file a secret.

Test whether a copy is genuinely separate

A recovery copy should remain reachable under the failure scenario that prompts the restore. A second copy on the original host still depends on that host. Similarly, a key in a self-hosted password manager may not provide an independent route if the vault runs inside the environment being recovered.

For each proposed location, ask:

System: Can you retrieve the key without booting the original client?
Storage: Is the copy outside the client’s disks and storage pool?
Authentication: Can you obtain the required credentials and second factors?
Network: Does retrieval require local DNS, identity services, or other homelab infrastructure?
Physical location: Could one incident affect both the systems and the key copy?
Identification: Can an authorized person determine which key belongs to the selected backup without exposing the secret in an inventory?

Moving a key outside the client removes that client as the sole key failure domain. It does not guarantee that the external copy is readable, protected, or available.

Compare the documented custody options

Proxmox suggests storing a key in a password manager, saving another copy to a securely stored USB device, and optionally keeping a paper copy in a safe place (Proxmox VE PBS storage documentation).

Password manager

A password manager offers convenient retrieval if its account, devices, credentials, and second factors remain available independently of the homelab. The documentation recommends this option, but it does not establish that every password-manager deployment provides an independent recovery path.

Detached USB storage

A securely stored USB device detaches a key copy from running systems, matching Proxmox’s guidance. That copy still needs to be identifiable and protected against unauthorized access. When keys change, the retained recovery material must continue to correspond to the backups it is intended to unlock.

Printable recovery copy

The paperkey command can produce a printable, human-readable representation of an encryption key with a scannable QR code (Proxmox Backup command syntax). This creates an offline option, although the documentation does not demonstrate the durability or successful scanning of any particular printout.

Using multiple custody methods can prevent one device or service from becoming the only recovery path. Those copies must be protected against disclosure as well as loss.

What the master-key mechanism changes

Proxmox also documents an RSA master-key workflow. A backup client uses the public master key to encrypt the symmetric backup key, then appends that encrypted key copy to the backup (Proxmox Backup command syntax).

In the documented client workflow, this copy is stored as rsa-encrypted.key. It can be extracted from the backup without the ordinary encryption key and then processed with import-with-master-key using the corresponding private master key (Backup Client Usage).

The recovery chain then becomes:

The encrypted backup data
The symmetric key that encrypted it
rsa-encrypted.key, containing an encrypted copy of that symmetric key
The private master key required to recover the symmetric key

This allows recovery of the symmetric key even if the original client is unavailable (Proxmox VE PBS storage documentation). A practical pattern is to distribute the public master key to backup clients while retaining the private master key in independent recovery storage.

The mechanism moves the critical dependency; it does not remove it. Proxmox warns that master-key recovery is impossible if no copy of the corresponding private key remains (Proxmox VE PBS storage documentation).

A concise recovery-design checklist

Before relying on encrypted backups:

Identify every ordinary encryption key and private master key needed by retained backups.
Record which backup sets use which keys without placing the secrets in the inventory.
Keep at least one key-recovery path independent of the original Proxmox VE host.
Check whether that path depends on local networking, identity services, devices, or second factors.
Preserve keys required by older backups when rotating or retiring keys.
Keep recovery instructions outside the environment being protected.
Protect every recovery copy against both loss and unauthorized access.

Two integration-specific caveats may influence the design. Proxmox documents that backups encrypted with different keys cannot deduplicate against one another. Its Proxmox VE PBS storage backend documentation also says configured encryption keys must currently be non-password-protected; that restriction is specific to this integration, while standalone proxmox-backup-client keys can be password-protected (Proxmox VE PBS storage documentation; Backup Client Usage).

The decisive question is: If the original client were unavailable, could you still retrieve the correct key and every credential needed to begin restoration?

The documentation supports this dependency model, but it does not prove that any particular key store or complete restore procedure will work in your environment.

Keep Your Proxmox Restore Key Outside the Backup Chain

The basic recovery dependency

Test whether a copy is genuinely separate