Verify Proxmox Backup trust before accepting a PVE storage entry

Bottom line: Confirm which backup server the PVE node is meant to trust before saving a fingerprint. Keep credential handling and the storage-status check distinct from a later demonstration that the intended backup can actually be recovered.

Source fact: what the authority says

The Proxmox VE integration guide adds PBS as storage of type pbs in Proxmox VE. Supplying --password without an argument causes the program to prompt, rather than placing the password in a literal argument. For a self-signed backup-server certificate, the guide requires the fingerprint in the configuration and obtains it on the backup server through proxmox-backup-manager cert info. The guide then checks the added storage with pvesm status --storage and says VM and container backups use the integrated storage.

What the source does not establish

The source’s storage-status example is not a completed restore test or a statement that an arbitrary supplied fingerprint is trustworthy. This article does not establish encryption-key recovery, retention protection or permission completeness for an existing deployment.

Applicability questions

• What server and datastore are approved, and how is their identity independently established?
• Who can obtain the certificate fingerprint through trusted server access?
• Which credential and entry method are approved without exposing a password?
• What separate backup and recovery observations are needed before operational acceptance?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends recording the intended server, datastore, PVE storage identifier and account as separate references. Obtain the expected fingerprint through an approved administrative channel and compare it with the value being configured. Do not accept a value copied from an unexplained connection warning as its own identity proof.

Choose the documented password prompt when using the command-line workflow, and follow the organization’s credential-handling procedure. Keep the password out of tickets, example commands and screenshots. Have the account owner review its intended use without broadening permissions merely to obtain a successful status response.

Preserve the storage configuration and the source of the fingerprint comparison. If the certificate changes later, investigate the reason and repeat the trust decision rather than automatically replacing the saved value. Keep that review separate from a routine datastore capacity check.

Prepare a proposed small backup and isolated restore with harmless marker data once the integration is accepted. State which VM or container is involved and where the recovery copy may run. Do not attach a production network or retire the prior recovery route merely because the storage appears active.

Verification and evidence

Proposed verification: inspect the configured endpoint, datastore, account reference and fingerprint against the approved record, then run the documented storage-status check. Preserve the actual output and time without reporting the example’s numbers as local capacity evidence.

Perform the separately authorized backup and isolated recovery exercise, inspect the marker data and record the result. Retain trust verification, connection status and recovery evidence as three named observations. Keep any unresolved permission, certificate or restore failure visible until its owner accepts the specific correction.

Official references

• Proxmox — Proxmox VE Integration — official product documentation; confirm the installed release and configuration.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.