To recover an encrypted PBS backup after losing its PVE host, you need access to the datastore and the encryption key that matches that backup. Preserve a protected copy independently of PVE, record which backups use it, and test it on another recovery installation. Resetting a PBS password or creating a new key does not recover the old decryption key.
This guide is a recovery plan for PVE-managed VM backups. The standalone backup client has different key defaults. Tape keys and server-side encryption during push sync are outside this example. For the initial storage connection, use the PBS setup guide; for the recovered guest, follow the isolated VM restore runbook.
Validation: official documentation reviewed November 10, 2026; PBS manuals identify as 4.2.9-1. No real keys were read or generated and no recovery test has been performed. Rehearse with a disposable encrypted backup before relying on the plan.
Identify each secret by what it does
| Item | Function | Recovery question |
|---|---|---|
| PBS account password or API token | Authenticates access subject to ACLs | Can another recovery host read the required snapshot? |
| Backup encryption key | Decrypts backups made with that key | Is the matching key available outside the lost host? |
| Key passphrase, where used | Unlocks a protected key file | Can the authorized operator retrieve it independently? |
| Optional RSA master private key | Recovers a wrapped backup key when that wrapped copy exists | Was the master public key configured before this backup? |
| Master public key | Lets a client wrap a backup key | Is the corresponding private key preserved? |
The private key and public key have different roles. A public key alone cannot unwrap the recovery material. No administrative PBS role provides a decryption override for an independently encrypted backup.
Preserve the PVE key and its context
For a storage ID such as pbs-lab, the
PVE PBS backend
documents /etc/pve/priv/storage/pbs-lab.enc as the key location. PVE’s backend
supports a key without passphrase protection. Root-only file access is not
an encrypted independent recovery copy.
Use your approved encrypted secret-storage or offline recovery process to preserve the actual key, without pasting its contents into tickets, logs or ordinary notes. Keep access to that store independent of the protected host. Treat any export, staging file or printout as secret material.
Store a non-secret record alongside the runbook:
| Field | Example to complete |
|---|---|
| Source PVE storage ID | pbs-lab |
| PBS location | Server, datastore and namespace |
| Key identifier | Fingerprint or identifier from the chosen tool |
| Covered snapshots | Known snapshot IDs confirmed by a recovery test |
| Protected key copy | Reference to the secret store, not the key itself |
| Recovery operator | Who can retrieve it if the host and local identity service fail |
| Last drill | Date, recovery build and application result; blank until tested |
The storage ID alone is not a permanent key identity. It may be reused after a reinstall. If a new key is introduced, keep earlier keys for snapshots that still require them. Test representative old and new snapshots before retiring any key material.
Keep standalone-client and PVE behavior distinct
The backup client encryption guide describes password-protected key files and a default user configuration location. Those defaults do not mean that PVE can directly use the same password-protected file for unattended storage access.
If your independent copy is encrypted by a vault or another recovery tool, plan how an authorized operator will obtain the usable key on a trusted recovery PVE host. Preserve the encrypted original. Any conversion to a PVE-compatible key belongs in a restricted temporary location and needs its own rehearsal; do not replace the working key in place as an experiment.
Decide whether to add master-key recovery
The documented optional RSA route wraps a backup encryption key and includes that wrapped copy with the backup. Keep the master private key and any unlocking passphrase independent of both backup storage and the protected host. Configure the public counterpart on the backup side before creating the test snapshot.
For an existing snapshot, inspect whether its wrapped key is actually present. Adding a master public key today does not retroactively put one into old snapshots. Follow the documented master-key recovery sequence on a trusted recovery workstation, then test the recovered key against data. Successfully unwrapping a file is an intermediate check, not proof that the application can be recovered.
Prove recovery with the original host absent
Use a disposable VM and create an encrypted test backup with a known application marker. On a separate recovery PVE installation:
- Retrieve only the independent credential and key copies defined in the runbook. Do not copy a still-working key from the source host during the drill.
- Connect to the correct PBS datastore and namespace with verified TLS and scoped recovery access.
- Import the matching existing key using the backend workflow for the installed PVE build. Avoid automatic generation of a new key for old backups.
- Restore to an unused VM ID with startup disabled; isolate every NIC before boot.
- Read the known marker and perform an application write/read check on the isolated copy. Record the snapshot, key identifier and result.
Failure to list a snapshot suggests access or scope trouble; seeing a snapshot but failing to decrypt it points to key selection or key-file handling. A successful decryption followed by application failure needs a dependency and consistency investigation. Preserve task logs without exporting secrets.
Remove temporary plaintext copies through the recovery environment’s approved secret-handling process after the drill. Retain the protected recovery copy for as long as any required backup depends on it.