Proxmox Backup Server host restore is the half of disaster recovery everyone skips until the host actually dies. The datastore is on a separate disk, the backups are intact, and yet the backup server is down. You rebuild the OS, reinstall PBS, and point it at the existing datastore. That’s the whole recovery, and it works because the datastore is just a directory with chunks and indexes. The hard part is not the restore. It’s knowing what to check before you declare victory.
Why the datastore survives
PBS stores everything in a datastore directory. Backups are split into chunks, deduplicated, and indexed. The datastore has no database running in the background that can corrupt if the host dies uncleanly. It’s files on disk. If the disk is fine, the datastore is fine. That’s the design win. It means the backup server is replaceable. The host can be reinstalled from scratch and the datastore reattached.
I’ve had to do this once after a kernel update left the PBS host unbootable. The evidence checklist post covers the diagnosis: PBS Backup Host Outage: Evidence Checklist After a Kernel Update. The recovery was straightforward because the datastore lived on a separate ZFS pool. I did not have to restore a single backup. I just needed the host back.
Rebuilding the host
Install Proxmox Backup Server on the new or repaired host. Use the same version or newer. The installer is a standard Debian-based ISO. After installation, you have a clean PBS with no datastores configured. Do not create a new datastore. Do not initialize anything. The existing datastore will be attached as-is.
If the datastore is on a separate disk or pool, import it. For ZFS, that’s zpool import. For a plain disk, mount it. The datastore directory will be there. Note the mount point. You’ll need it for the next step.
Reattaching the datastore
In the PBS web interface, go to Administration > Storage / Disks. Click Add Datastore. Give it the same name as before. Set the backing path to the mount point of your existing datastore. Do not check the box to create the datastore. That would initialize a new one. You want to attach the existing one. PBS will detect the existing chunk store and index. It may take a moment to scan, but it will not rewrite anything.
After attaching, verify the datastore contents. Go to the datastore and check the summary. You should see the existing backup groups and snapshots. If you see nothing, the path is wrong or the datastore is not being read correctly. Check permissions. The backup user needs read/write access to the datastore directory. Usually the installer sets this up, but if you mounted a disk manually, you may need to chown -R backup:backup /path/to/datastore.
Reconfiguring clients
Once the datastore is attached and verified, point your Proxmox VE hosts back to the PBS. If the PBS hostname or IP changed, update the storage configuration on each PVE node. In PVE, go to Datacenter > Storage, edit the PBS storage, and enter the new hostname or IP. The password or API token may need to be re-entered if the PBS host was reinstalled. Test with a small backup job.
If the PBS hostname stayed the same because you restored the same host or used the same DNS name, clients may reconnect automatically. But don’t assume. Check the backup logs on a PVE node. A failed connection is the first sign something is off.
What to check before you call it done
After reattaching, run a verification job on the datastore. This reads all chunks and indexes, and it will catch corruption that happened during the outage. If the host died uncleanly, some chunks may be incomplete. Verification will tell you. Run it before you delete any old backups or change retention.
Check the datastore’s GC schedule. Garbage collection should run after verification. If the datastore was offline for a while, GC may have missed runs. It’s safe to run manually. The command is proxmox-backup-manager garbage-collection start <datastore>.
Also check the prune schedule. If backups were not running during the outage, you may have a gap. That’s fine, but be aware of it. The retention policy will not magically fill the gap. You’ll just have a hole in your backup history.
One thing that bit me: after reattaching, the datastore showed all backups, but new backups from PVE failed with a permission error. The backup user did not have write access to the datastore directory because I had mounted the disk with root-only permissions. A quick chown fixed it. It’s the kind of thing that’s easy to miss when you’re focused on the big picture.
Why this is better than restoring from backup
If you had to restore the PBS host from a backup of the host itself, you’d need a backup of the PBS configuration and the datastore. That’s a chicken-and-egg problem. The datastore is the backup. Backing up the backup server means duplicating the datastore, which is expensive and usually unnecessary. The datastore’s design makes the host disposable. That’s a feature, not an accident.
This is different from a Veeam hardened repository, which is a whole different beast. Veeam hardened repository: what it buys you that PBS prune settings do not covers that. PBS prune settings are about retention. A hardened repo is about immutability. They solve different problems.
What I’d do differently
Next time, I’d document the datastore mount point and the PBS hostname somewhere outside the PBS host. A note in the PVE cluster’s password manager or a text file on a different machine. When the host is down, you don’t want to be guessing where the datastore was mounted. The datastore itself is self-describing once you attach it, but the mount point is not.
I’d also set up a simple health check that alerts when the PBS host is unreachable. The outage was caught by a failed backup job, not by monitoring. A ping check or a systemd timer that curls the PBS API would have caught it sooner. The recovery was easy, but the downtime was longer than it needed to be.
If you’re running PBS in a homelab, this is the recovery you should practice. Not restoring a VM from backup, but rebuilding the backup server itself. It’s the one that feels scary until you do it once. Then it’s just a checklist.
If you’d rather pay for this
The obvious paid option is Proxmox Backup Server support from Proxmox Server Solutions GmbH. It’s billed per server per year, and it gets you access to the enterprise repository and support tickets. For a homelab, that’s overkill. The community repository and the forums are plenty. The support subscription is really for businesses that need a vendor to call.
Another option is a managed backup service like Backblaze B2 or Wasabi. You’d still run PBS, but you could sync the datastore to object storage for off-site redundancy. That’s billed per TB stored per month. At the time of writing, Backblaze B2 is around $6 per TB per month. For a homelab with a few hundred gigabytes of backups, that’s a few dollars a month. It’s worth it if you want off-site copies without maintaining a second PBS host. But it doesn’t replace the host rebuild process. It just adds another copy of the data.
Honestly, for a homelab, the free path is fine. The datastore survives, the host is replaceable, and the recovery is a couple of hours. Paying for support or off-site sync is a choice, not a necessity.
