PBS: fix the fingerprint mismatch after a rename or reinstall

28 August 2026

In short. The fingerprint pinned in /etc/pve/storage.cfg and in the other PBS's remote definition is a hash of the certificate, and the certificate changed. Read the new one with proxmox-backup-manager cert info, update each PVE storage with pvesm set, update the remote on the other PBS, re-run a sync, and check pvesm status. Then write down that a rename is a change with consequences.

"certificate verify failed" everywhere after a rename

The PBS at site A was renamed to fit the naming scheme. Within an hour every cluster using it showed the storage as inactive, and the status output on a node said:

pbs-a: error fetching datastores - 500 ... certificate verify failed

The exact wording varies between PVE and proxmox-backup-client releases, but certificate verify failed or a line naming the fingerprint is in it. The overnight sync on the other PBS failed for the same reason. Nothing is broken on the PBS; everything that pinned its old identity is doing what pinning is for.

flowchart TD
  CERT["PBS A certificate<br/>regenerated on rename or reinstall"] --> FP["new fingerprint<br/>proxmox-backup-manager cert info"]
  FP --> S1["PVE cluster A<br/>/etc/pve/storage.cfg"]
  FP --> S2["any other cluster with<br/>a storage entry for PBS A"]
  FP --> R["PBS B<br/>/etc/proxmox-backup/remote.cfg"]
  FP --> U["proxmox-backup-client units<br/>PBS_FINGERPRINT"]

What you need

PBS 4.x that has been renamed or reinstalled, and PVE 9.2 clusters that back up to it.
Root on the PBS, on one node of each affected cluster (storage.cfg is cluster-wide), and on the other site's PBS.
A list of everything that pins the fingerprint. On this estate that is the PVE storage entry on the local cluster, the remote definition on the other PBS, and the systemd units that run proxmox-backup-client for the CephFS archives.

Steps

Understand why it changed. PBS generates a self-signed certificate at install with the hostname in it. When the proxy starts and the hostname no longer matches, it generates a new one; a reinstall gets a fresh one regardless. The fingerprint is a SHA-256 of that certificate, so a new certificate is a new fingerprint. The private key changed too, so there is nothing to restore.
Read the new fingerprint on the renamed PBS:
```
proxmox-backup-manager cert info
```
Copy the Fingerprint (sha256) line. Compare it with what the GUI shows under Administration, Certificates, to be sure you are reading the certificate the proxy is actually serving.
Find every PVE storage entry that pins the old one. On one node of each cluster:
```
grep -n -B6 fingerprint /etc/pve/storage.cfg
```
Each pbs: block has a fingerprint line. The surviving cluster at the other site has one too, for the read-only replica entry, if the renamed host is the one holding the replica.
Update each storage entry. Do not edit storage.cfg by hand; pvesm set writes it through the cluster filesystem and validates it:
```
pvesm set pbs-a --fingerprint 'AA:BB:CC:...'
pvesm status
```
The storage goes active immediately if the fingerprint is right. Repeat on each cluster that has an entry for this PBS; storage.cfg is shared within a cluster, so once per cluster is enough.
Update the remote on the other PBS. The remote definition on site B pins site A's fingerprint:
```
proxmox-backup-manager remote update site-a --fingerprint 'AA:BB:CC:...'
proxmox-backup-manager remote list
```
If the host that was renamed is the one doing the pulling, nothing changes here; the remote pins the source, not the puller.
Update any client units. The nightly CephFS archive job sets PBS_FINGERPRINT in an environment file:
```
grep -rl PBS_FINGERPRINT /etc/proxmox-backup-client/ /etc/systemd/system/
```
Edit the value, then run the unit once by hand with systemctl start and read its log.
Re-run the sync from the other PBS so tonight's schedule is not the first test:
```
proxmox-backup-manager sync-job run pull-site-a
```

Verify it worked

From a node of each affected cluster:

pvesm status
pvesm list pbs-a | head

The storage shows active and lists backups. On the other PBS, the sync task you ran by hand ends in TASK OK with at least one sync snapshot line, or found N groups to sync where everything was already present. The next morning, check that the backup jobs ran green and the scheduled sync transferred something.

Gotchas

Renaming through the GUI's node settings or hostnamectl without updating /etc/hosts leaves the proxy unable to resolve itself, and then it never regenerates the certificate. Fix the hostname properly and the certificate follows.
The overlay name the other PBS uses to reach the source does not change when the host's own name does. Do not change the remote's host field unless the mesh peer was renamed as well.
A PVE node with a stale fingerprint keeps running scheduled backups, which fail, and the failure email arrives at 01:00. Update the pins the same afternoon.
pvesm set on one node is enough for the cluster, but two clusters each need their own.
If you restore /etc/proxmox-backup/ from a backup of the old host, you bring the old certificate and key back. That is fine for a reinstall under the same name and a bad idea otherwise.

FAQ

Can I avoid pinning fingerprints at all? With a certificate from a CA the PVE nodes trust, the fingerprint field can be left empty and verification goes through the normal chain. PBS supports ACME, and a DNS challenge works for internal names under a public zone. The estate still pins, because a changed identity failing closed is the behaviour it wants from a backup server.

Why not restore the old certificate and key onto the renamed host? Because the name in the certificate would be wrong, and because the point of the rename was to have the host's identity match its name. Updating five pins once is cheaper than an exception that lives forever.

Does the fingerprint change on an upgrade? No. An upgrade keeps /etc/proxmox-backup/proxy.pem and its key. Only a rename, a reinstall, or an explicit regeneration changes it.