Install Proxmox Backup Server 4.2 and Back Up a Proxmox VE Cluster

A backup is only real when you can restore it. In this guide, you will install Proxmox Backup Server (PBS) 4.2 on its own machine, connect it to your Proxmox VE cluster, run scheduled backups, and then restore a full VM to prove it all works. 

We will build this layout for the Proxmox backup server setup:

These names match our Proxmox VE HA cluster guide. The cluster has three nodes (pve1, pve2, pve3), the name prod-cluster, and a private Corosync network of 10.10.10.0/24. 

Here is the most important rule: PBS must run on a separate server. Do not install it on a cluster node, and do not store backups on the same disks as your VMs. If the cluster fails, you still need the backups. A separate machine is a separate failure domain.

Before you start, make sure to get these things ready:

• One separate server for PBS. A dedicated server is best for production.
• At least 4 CPU cores and 4 GiB of RAM, plus 1 GiB of RAM for each TiB of backup storage.
• At least 32 GiB of free space for the operating system.
• Fast backup disks. The PBS prefers fast local storage with high IOPS, and enterprise SSDs give the best results. If you use HDDs, you can add a ZFS special device mirror to speed up metadata.
• A static IP address and a hostname for the PBS server.
• A working Proxmox VE cluster. If you do not have one yet, build it first with the HA cluster guide.
• Network access from every PVE node to the PBS server on TCP port 8007.

For testing only, PBS needs just 2 CPU cores, 2 GB of RAM, and 8 GB of disk. Do not use this for production.

Two more rules for planning you must consider:

• Use a hardware RAID with a battery-backed cache, or a ZFS mirror, for the PBS operating system disk. Do not use ZFS on top of hardware RAID.
• Send backup traffic over your normal network, not over the private corosync network. Heavy traffic on the corosync link can cause false node failures.

First, you must install Proxmox Backup Server 4.2 on its own separate server. The ISO installer is the easiest way, because it sets up Debian, the Proxmox kernel, and all the backup tools for you. You should download the ISO, write it to a USB drive, and run the installer.

Download the PBS 4.2 ISO from the official Proxmox download page. Then, you can check its checksum by using the command below with the one shown on the download page:

On Linux, you must find your USB device name with the command below:

Plug in the USB drive and run lsblk again. The new device is your USB drive, for example, /dev/sdX. Then, write the image. This erases the USB drive, so double-check the device name:

On Windows, use Etcher, or use Rufus in DD mode. Do not use UNetbootin.

If your server is a rented dedicated server, you can usually mount the ISO from the IPMI or the provider panel instead of using a USB drive.

Now you can start the installer on your backup server. Follow the steps below in order:

1. Boot the server from the USB drive.
2. Choose Install Proxmox Backup Server (Graphical). If the screen has problems, choose the Console option.
3. Accept the license (EULA).
4. Pick the target disk. In Options, choose the file system: ext4 (default), xfs, or ZFS. Choose ZFS mirror if you have no hardware RAID.
5. Set your country, time zone, and keyboard.
6. Set a strong root password (12 or more characters) and an email address.
7. Set the network: choose the interface, set the hostname as an FQDN, for example, pbs1.example.com, the static IP (192.168.1.50/24), the gateway, and the DNS server.
8. Check the summary, click Install, and reboot when it finishes. Remove the USB drive.

All data on the selected disks is deleted. The installer sets up either IPv4 or IPv6 during install, not both.

Use this only if you already run Debian 13 (Trixie) and know the disk and network setup. Create the Proxmox repository file:

Add this content to the file, save, and exit:

Download the Proxmox key and check it with the commands below:

Run the system update and install PBS with the following commands:

The proxmox-backup package installs the same set of packages as the ISO, including the Proxmox kernel. The smaller proxmox-backup-server package keeps your current Debian kernel.

In this step, you will log in to the PBS web interface for the first time. Then, you must turn off the paid repository, add the free one, and update the server. This keeps your backup server current and free of update errors. Open the web interface in your browser:

Your browser will warn about the self-signed certificate. This is normal for now. Log in with user root and realm Linux PAM standard authentication.

Now connect to the server over SSH and set up the update repository. The ISO enables the enterprise repository by default. Without a subscription key, it gives errors, so disable it:

Add this line at the end of the stanza:

Then, create the no-subscription repository file:

The no-subscription repository is fine for labs and small setups. For production, a subscription and the enterprise repository are the better choice.

Update the server and reboot if a new kernel was installed:

After the reboot, check the version, the time, and the hostname:

You should see proxmox-backup-server version 4.2.x. Correct time matters, because the wrong time can break verification schedules and certificate checks.

A datastore is the place where PBS keeps backup data, so this part of the Proxmox backup server setup needs good disks. You must use separate disks from the operating system disk. List the free disks with:

Then, create a mirrored ZFS pool and a datastore on it in one command. Replace sdb and sdc with your disks:

This creates the pool store1, mounts it under /mnt/datastore/store1, and adds a datastore named store1. If you prefer a single disk with ext4 or xfs, use this instead:

Check that the datastore exists with the command below:

Also, you can do this in the web interface: Administration > Storage / Disks, then Datastore > Add Datastore.

Optional: You can turn on verification of every new backup right after it finishes:

Do not give Proxmox VE the root password of your backup server. You must create a separate user with only the rights it needs.

First, create the user. This user logs in only through its API token, so no password is needed:

Then, create an API token for this user:

The command prints a token ID and a secret. The token ID looks like pve-backup@pbs!pve-cluster. Copy the secret now. PBS shows it only once.

Give the DatastoreBackup role to both the user and the token, on this datastore only:

Check the permissions with the commands below:

DatastoreBackup lets the cluster create backups and read back its own backups. It cannot prune or delete other data. If an attacker gains access to your PVE cluster, they cannot delete your backup history using this token. Prune and garbage collection run on the PBS side.

Also, you must get the TLS fingerprint of the PBS server. You need it in the next step:

Copy the full sha256 fingerprint line value. It looks like 64:d3:ff:...:ab:fe.

At this point, you must connect your Proxmox VE cluster to the backup server. You can add the PBS datastore as a storage in PVE, using the API token and the fingerprint from the last step. Storage settings are shared across the cluster. So you can run the commands on one node, and all nodes can then use the backup storage.

First, check that the node can reach PBS on port 8007:

Then, add the PBS datastore as a storage. Replace the secret and fingerprint with your values:

Check the storage; the type should be pbs and the status should be active:

Now you can confirm on the other nodes with the commands below:

Also, you can use the web interface: Datacenter > Storage > Add > Proxmox Backup Server. Fill in the ID, server, username (pve-backup@pbs!pve-cluster), password (the token secret), datastore, and fingerprint.

Encryption keeps your data private even if someone steals the backup server. You can create a key on the PVE side:

The key is saved at /etc/pve/priv/storage/pbs-store1.enc. Copy it to a safe place outside the cluster, such as a password manager. If you lose the key, you cannot restore your encrypted backups, even if the cluster fails and you rebuild it. Turn encryption on before the first backup, because older backups stay unencrypted.

First, you must install the guest agent in each Linux VM, so PBS can freeze the file system for a clean backup:

Then, enable the agent option on the PVE node. Replace 100 with your VM ID:

Stop and start the VM once so the agent option takes effect.

Before you create a schedule, run one backup manually. This shows you if the connection, the token, and the storage work. If this backup fails, a scheduled job would fail too.

A good run ends with Backup job finished successfully. Do the same for one LXC container, replacing 101:

Check that both backups are visible:

In the web interface, go to Datacenter > Backup > Add and set:

• Storage: pbs-store1
• Schedule: 02:00
• Selection mode: All or pick the VMs and containers you need
• Mode: Snapshot

You can also create the same job from the command line:

After you create the backup job, make sure PVE saved it correctly:

One job covers both VMs and LXC containers. Run backups at night, when the cluster is quiet. Keep the retention in this job empty and set it on PBS in the next step, so you manage retention in one place only.

Retention decides how many backups you keep. It takes two steps on PBS:

1. Prune removes old snapshots by your rules. It only removes the snapshot records.
2. Garbage collection (GC) deletes the backup data that no snapshot uses anymore. This is what frees disk space.

You can create a daily prune job on the PBS server. This example keeps 7 daily, 4 weekly, and 6 monthly backups:

Then, set a weekly GC schedule on the datastore:

Next, check both settings with the commands below:

GC does not free space at once. It skips very new backup data for safety, so the space comes back after about a day. This is normal. To start GC manually and see the result, you can run:

Also, you can manage these jobs in the web interface: Datastore > store1 > Prune & GC.

To protect one important snapshot from pruning, for example, before a big upgrade, use the protected flag in the Content tab of the datastore.

A verification job reads your stored backup data and checks that it is still correct. It finds silent disk damage before you need the backup. Without it, a bad backup looks fine until the day you restore.

You can create a weekly verify job on PBS with the command below:

This job skips snapshots that were verified in the last 30 days and re-checks older ones. The schedule runs after the Saturday GC job, so the jobs do not overlap.

Then, list the job and run a full verify manually:

It should show TASK OK. Check the task log in the web interface under Administration > Tasks, or open the datastore and look for the green verify icon on each snapshot.

A Proxmox backup server setup is not finished until a restore works. Your backup is not proven until you restore it and boot it. Do this test after the first backup, and then again every few months.

You must restore to a new VM ID; we use 9100. This keeps your live VM and your HA settings safe. Do not restore over a VM that is managed by HA.

First, find the backup you want with the command below:

The output shows a volume ID like pbs-store1:backup/vm/100/2026-10-14T02:00:05Z. Copy it. Also, check your target storage name:

Then, run the restore. Replace local-lvm with your own storage, such as local-zfs:

The --unique option creates new MAC addresses, so the copy does not conflict with the live VM. Before you start the copy, cut its network so it does not take the IP address of the live VM:

Now start it and check it with the commands below:

Open the console of the VM 9100 and confirm:

• The operating system boots with no errors.
• Your data and services are there. For example, check the database or website files.
• The disk contents match the time of the backup.

When the test passes, write down the date, the VM ID, and how long the restore took. Then remove the test VM:

The steps are the same for a container. You can use pct restore with a new ID:

Remove the test container when you are done:

Test the worst case: Once a year, run a harder test. Pretend the cluster is gone. On a fresh PVE node, add the PBS storage again (Step 5) and restore a VM. If you use encryption, this is where you prove that your off-cluster copy of the key works.

Your backup server must sit outside the failure domain of the cluster. That means a different physical machine, a different rack or data center, a different power source, and a different network path. If the backup server shares a switch, a power line, or a disk with your VMs, one failure can take out both.

For a reliable Proxmox backup server setup, you can use a dedicated server. You get full disk control, steady IO, and no noisy neighbors during backup and verify jobs. A separate PerLod dedicated server works well as a PBS target, because you can choose the disk layout and a location away from your cluster.

Use a short checklist for the whole system:

• Keep at least two copies of important data, with one copy off-site.
• Use a second PBS or a remote sync job for an extra copy of key backups.
• Check backup, verify, and GC task results every week.
• Update PBS and PVE on a regular schedule.

At this point, you have a complete Proxmox backup server setup. The restore test is what makes the setup trustworthy. Repeat it on a schedule, keep PBS on a separate failure domain, and keep your encryption key outside the cluster.