Skip to content

Category: Virtualisation

Managed Proxmox Backup Server: backups of your machines that can be restored

Backups of your virtual machines and containers, deduplicated, encrypted and verified, with a second copy well away from the cluster and restores we rehearse before you need them.

Where it runs
In your account, in your name
Backups
With tested restores
Updates
Planned and documented
Licence
Open source, AGPLv3 (optional subscription)

In short

Proxmox Backup Server is the open source backup server from Proxmox: it stores incremental, deduplicated backups of virtual machines, containers and Linux servers, with client-side encryption. We set it up separately from your cluster, schedule backups, verification and pruning, replicate to another site and restore in tests so you know how long it would take you to get back up.

What do we take care of?

A backup that has never been restored is an assumption. Proxmox Backup Server does its job well, but someone has to decide what is backed up and how often, make sure it does not fill up, verify the data and prove that you can go back.

  • Backup server

    Proxmox Backup Server on its own machine, with ZFS and patches up to date.

  • Backup jobs

    A schedule per machine based on how much can be lost, from several times a day to once a week.

  • Encryption and access

    Client-side encryption, tokens that cannot delete and users separate from the cluster.

  • Verification

    Regular checks of the stored chunks to detect corruption.

  • Off site

    Sync to a second backup server or to an S3-compatible datastore.

  • Restores

    Tests of complete machines and individual files, with the time recorded.

How do we set it up?

The basic rule is to have at least three copies, on two different media and one off site. With Proxmox Backup Server we handle it like this:

  1. Local backup server

    A physical machine separate from the nodes, close to them so that backing up and restoring is fast.

  2. Minimal access

    Proxmox VE writes with a limited token; the backup server is administered with another user and two-factor authentication.

  3. Scheduled maintenance

    Retention, pruning, garbage collection and verification at times that do not clash with the backups.

  4. Off-site copy

    A second server in another location pulls the backups from the first, or they are synced to an S3 datastore.

Having the second server pull the backups, rather than the first one pushing them, means an attacker on the main network has no credentials to delete the remote copy.

What problems do we come across most often?

  • The backup server as a virtual machine in the same cluster: a serious fault takes out the machines and their backups.
  • No garbage collection: expired backups are removed from the index, but the disk does not get the space back.
  • Verification never run: a damaged chunk is discovered on the day of the restore.
  • Encryption key only in the cluster: if the cluster is lost, the encrypted backups cannot be read.
  • A token with administrator permissions: whoever compromises Proxmox VE can delete every backup.
  • A single location: backups and cluster in the same room, exposed to the same fire or power cut.

How do we prove the backup works?

Every month, at the very least, we restore a complete machine on an isolated network, check that it boots and that its services respond, and recover a few individual files from another one. We rotate the machines so that over time all the critical ones are covered. Once a year, or after a major change, we rehearse restoring from the off-site copy, which is the one you would use if you lost the main site. The times go into the report: they are your real recovery time, not an estimate.

Who is it for?

  • A company running Proxmox VE that currently backs up with vzdump to a shared disk and wants long retention without multiplying the space.
  • A team that has migrated from VMware and needs to replace its backup tool with something integrated with the new cluster.
  • Anyone with standalone Linux servers who wants to back them up to the same place as their virtual machines.

We manage the cluster these backups come from as we describe in managed Proxmox VE. If you are looking for somewhere to keep the off-site copy, we explain it in S3-compatible storage for backups.

How do we upgrade it?

Proxmox Backup Server is upgraded like any Debian system, from the subscription or no-subscription repository. We apply minor versions outside the backup window. For a major version we read the notes, check that the Proxmox VE clients are compatible with the new version, upgrade the off-site server first and, once it works, the main one. Before touching anything we make sure there is a recent, verified backup of everything critical.

How the pieces fit together
  1. Proxmox VEScheduled backups
  2. Proxmox Backup ServerDeduplicated and encrypted
  3. VerificationChunk integrity
  4. Off-site copyAnother PBS or S3 datastore

Where do we set it up?

In your account, with the provider you already use or the one that fits best. If the data has to stay in the EU, Hetzner and OVHcloud are the European options.

Providers we set it up on

  • Hetzner
  • OVH
  • Own server
ProviderHow we set it upThings to bear in mind
HetznerA dedicated server with several ZFS disks as the backup server, in a different location from the cluster.For the main datastore we prefer local disks on the backup server itself.
OVHDedicated storage server running Proxmox Backup Server, in a different data centre from the nodes.
Own serverProxmox Backup Server on a dedicated physical machine in your office, plus a second copy synced off site.Installing it as a virtual machine inside the same cluster it backs up is convenient, but if the cluster goes down the backups go down with it.

What is included

  • Proxmox Backup Server on a machine separate from the cluster, with ZFS disks sized for the agreed retention.
  • Backup jobs from Proxmox VE with an access token that can write backups but not delete them.
  • Client-side encryption with a key stored outside the backup server and documented.
  • Scheduled retention policies, pruning of expired backups and garbage collection.
  • Regular verification of the backups to detect damaged chunks before you need them.
  • Second copy at another site with sync jobs to another Proxmox Backup Server, whose datastore can be on S3-compatible storage.
  • Test restores of complete machines and individual files, with the time measured in the report.
  • Alerts on failed backups, space, verifications with errors and pending updates.

Frequently asked questions

What advantage does it have over Proxmox VE vzdump backups?

With vzdump each backup is a complete file, so keeping many takes up a lot of space and time. Proxmox Backup Server splits the data into chunks, stores only the chunks that change and does not repeat identical ones across machines. That allows more frequent backups and long retention on less disk, plus verification and restoring individual files.

Does it protect us against ransomware?

It helps a great deal if it is set up properly. Proxmox VE connects with a token that can create backups but not delete them, the backup server shares no credentials with the cluster and there is a second copy at another site that syncs from there. That way, whoever compromises the cluster cannot delete the backup history.

Can we also back up servers that are not on Proxmox?

Yes, physical Linux servers or those in another cloud are backed up with the Proxmox Backup Server client, at file or block device level. For other systems we look case by case at which tool is best.

Can the backups be stored on S3 storage?

Yes. Since version 4.2, Proxmox Backup Server officially supports datastores on S3-compatible object storage, which also need a local disk cache. We use it mainly for the off-site copy; for the main datastore, the one you restore from in a hurry, we still prefer local disks.

What happens if I lose the encryption key?

The encrypted backups cannot be read, by you or by anyone. That is why we store the key and its copy on paper or in your company's password manager, outside the cluster and the backup server, and we write it down in the documentation.

Tell us about your case

In a free 20-minute call we look at where you are and where to start. No commitment.

Book a 20-minute call

Official documentation consulted

The technical details on this page are based on:

Reviewed on

WhatsApp