A backup on the main site cannot protect you from losing that whole site. With encrypted sync jobs in Proxmox backup server, you can keep a second copy at another location and encrypt plain backup data before it leaves the main backup server.
PBS 4.2 adds server-side encryption for push sync jobs, decryption for pull sync jobs, and parallel backup-group transfers through worker-threads. This guide uses these features to build an off-site copy, check it, and restore a VM without the main site.
There are three separate parts for the encrypted sync jobs in Proxmox Backup Server setup:
Sync encryption leaves the source unchanged and encrypts only the remote copy. PBS copies already encrypted snapshots as they are and skips partly encrypted snapshots.
Important Note: Do not enable encrypted-only to encrypt plain snapshots during push. It skips plain snapshots and copies only those already encrypted.
First, you must start with an unencrypted test backup. Also, for client-encrypted backups, keep the original key too.
Use two PBS servers, one at your main site and one at a separate location. The table below lists the example names used in this guide:
Use two PBS 4.2 installations with current 4.2 updates, root shell access for setup, working DNS, correct time, and enough disk space. Keep a recovery PVE host or an install plan ready.
If the primary backup server is not ready, you can check the Proxmox Backup Server setup guide.
For encrypted sync jobs in Proxmox Backup Server, the second server must be in a separate location, not just a different VM on the main cluster. You must use separate power, storage, and network access. Keep the recovery credentials and keys somewhere you can reach if the main site fails.
Run these commands on both servers to check the PBS version, time settings, and hostname:
Check that your PBS repository matches your subscription, then update during planned downtime:
Reboot if the update requires it. Do not replace repository files with settings from a different PBS major release.
For network access, you must allow TCP port 8007 from PBS1 to PBS2 for push. For recovery, allow the recovery PVE host to reach PBS2 on the same port. If you use the optional pull workflow, its receiving PBS needs access to PBS2 on port 8007.
Use a private VPN between sites if possible. Allow only the needed hosts through the firewall, and limit SSH and the PBS web interface to your admin network.
In this step, you must install PBS 4.2 on PBS2 using the same base installation process as PBS1. Use separate backup disks and check their names before creating storage. On PBS2, run the commands below:
The next command erases the selected disks. Run it only after confirming that sdb and sdc are unused backup disks, not system disks:
This creates a mirrored ZFS pool and adds its datastore. Do not use this command if you already have a suitable mounted storage pool. For an existing and correctly mounted backup filesystem, you must create only the datastore instead:
These are alternative methods, not two commands to run for the same datastore. Confirm that the existing filesystem really is mounted before using its path. Check the result with:
In the PBS2 web interface, open the offsite datastore and its Content view. Create a namespace named site-a.
Create it as the PBS2 administrator before giving the sync account access. This lets the sync account write backups without needing rights to create or remove namespaces. Namespace permissions use the path /datastore/offsite/site-a.
For encrypted sync jobs in Proxmox backup server, use a separate destination namespace for each source site. Do not send two unrelated source sites into the same backup groups.
You must create a sync account on PBS2 that can receive backups only in the site-a namespace. Use an API token to connect PBS1 to this account. On PBS2, run the commands below:
Save the displayed token secret in your password manager. PBS shows the secret only when the token is created. The token ID is:
Then, give the user and token backup access to this namespace only:
Set permissions for both the user and its API token. DatastoreBackup allows creating backups and restoring backups they own, but not pruning backups or managing namespaces.
Check permissions for both the user and its API token:
Use this remote account for this push job only. Proxmox recommends a dedicated remote entry and destination user for each push job because destination group ownership follows the remote account.
Now you can add PBS2 as a remote on PBS1 using its address, API token, and certificate fingerprint. This lets PBS1 connect to PBS2 and send backups. On PBS2, get its certificate fingerprint with:
Copy the SHA-256 fingerprint through a trusted admin connection. This fingerprint identifies the TLS certificate; it is not the encryption-key fingerprint.
On PBS1, open Configuration > Remotes and add:
PBS1, check the results with the commands below:
Do not disable TLS checks to fix a fingerprint mismatch. Compare the current certificate with your saved fingerprint and confirm any certificate change through a trusted path.
On PBS1, open the central Encryption Keys panel in the PBS 4.2 web interface. Create an active encryption key for the sync job. Use site-a-key as its ID where the key dialog allows an ID; if PBS assigns a different ID, use that actual ID in all commands below. PBS 4.2 brings tape and sync key management into a central panel.
Save the exported key file and its password, if it has one. Keep a secure copy away from the main site. Record:
Save the actual key file, not just its ID or fingerprint. Keep a copy away from the main site, and test it by restoring a backup.
This guide runs the push job as root@pam. If you use another local job owner, give it the required key, datastore, and remote permissions, not full admin access.
Now create a push job on PBS1 to encrypt unencrypted backups and send them to the site-a namespace on PBS2. Leave the schedule unset until you test the job:
Review the saved job with the following command:
The example reads backups directly in the root namespace of store1. If your backups are in production, add:
ns is the local namespace; remote-ns is the remote one. Push sends local to remote; pull does the reverse. max-depth 0 includes only that namespace. Higher values include child namespaces.
Start with one VM to check the sync setup before copying all backups. The example below uses VM 100:
After a successful test, remove that filter if you want all accessible backup groups in the selected namespace:
Filters limit what a job copies; a successful job does not prove that an excluded VM is protected.
Make sure the selected source namespace contains a completed backup. To create a fresh backup of test VM 100, you must run on its Proxmox VE node:
Replace pbs-store1 with the PVE storage ID linked to store1. For this feature test, use a test backup that is not already client-encrypted; do not remove production encryption just to run the test.
Start the job on PBS1 with the command below:
Check the task log for copied backups and any skip or encryption warnings. A successful task may still have copied nothing.
On PBS2, open Datastore > offsite > Content and select site-a. Check:
With encrypted sync jobs in Proxmox backup server, a green task result is only the first check. Also, you must confirm the destination content and complete a restore using the saved key.
Once the first test passes, add a schedule on PBS1:
This job runs daily at 04:00 in the server’s time zone. Schedule it after backups, with extra time for delays. It will not wait for backups to finish, so check backup completion and the latest remote copy.
PBS 4.2 supports 1 to 32 worker threads, with a default of 1. They sync different backup groups in parallel, not parts of one VM group. More workers use more memory and connections on both servers.
Start with four workers and compare a few runs. Add more only if CPU, disk, RAM, and network capacity allow:
Compare sync time, data transferred, CPU, disk delay, and RAM using the same backup groups. Test with multiple groups to see the benefit of parallel workers.
Use --rate-out for push and --rate-in for pull. Limits are in bytes per second. 20MiB is about 168 Mbit/s before network overhead, so a 100 Mbit/s link cannot reach that speed. Plan for:
For encrypted sync jobs in Proxmox backup server, use enough workers to meet your recovery target, not the highest count. You can recover only as far as the latest completed backup copied to the remote site.
Check that your remote backups are complete and readable, then set retention rules to control how long PBS keeps them. Run a full verification on PBS2:
Then, create a daily verification job with the command below:
This job checks new snapshots and rechecks older ones. Review the logs and verify results, run a full check at least monthly, and allow enough time for each job.
Verification does not test your recovery key or application. Keep the key off less-trusted remote servers and test a restore on a trusted host.
Set retention rules on PBS2 to control how long remote backups stay, without following deletions on PBS1:
Prune removes snapshot records. GC later frees unused data after a safety period, so disk space is not freed immediately. These retention settings are examples, not a fixed backup count or storage size.
Keep remove-vanished disabled, so source deletions do not remove remote backups. Sync does not copy snapshot protection flags, so protect important remote snapshots separately.
Admins on PBS2 can still delete backups. Keep admin access separate and add a protected or offline copy if needed.
At this point, you must create a read-only recovery account on PBS2 and save its credentials away from the main site. Keep the backup details and encryption keys ready, so you can restore if the main site fails.
DatastoreReader lets this account read and restore the namespace's backups without depending on the push account's group ownership. Store its secret away from the primary site. Your recovery kit should contain:
Use a fresh or separate recovery PVE host. For this test, it must not rely on the primary PVE cluster's shared configuration or key files.
After the remote sync finishes, block the recovery host's route to PBS1 using your lab or network firewall. Keep access to PBS2 working. Do not erase primary data or stop a production site to run this test.
For encrypted sync jobs in Proxmox backup server, this test proves that the remote copy is useful when the primary PBS and cluster are unavailable.
In the recovery PVE web interface, use Datacenter > Storage > Add > Proxmox Backup Server:
Import the saved key that matches your backup. Do not create a new one; it cannot decrypt existing backups.
If PVE needs a key without a password, remove the password only from a temporary copy on the trusted recovery host:
Enter the key password when asked. --kdf none removes the password from the temporary copy; keep it accessible only to root. Leave the vault copy unchanged. Use key show to check that its fingerprint matches the snapshot.
For client-encrypted backups, use the original client key, not the sync key. If backups use different keys, create a PVE storage entry for each key or switch to the matching key before restoring. Check storage access with:
Choose a free VM ID, such as 9100, and confirm the recovery storage has enough space:
Copy the exact backup volume ID shown by pvesm list. Then, run the commands below:
Replace local-lvm with storage that exists on the recovery node. Keep VM 9100 stopped after restore. Check its configuration with:
Before starting the VM, disconnect all network adapters in the recovery PVE interface. Check passthrough devices and host-specific settings too. A new MAC address does not change the VM’s static IP. Start the isolated VM with:
Open its console and check:
Use an isolated recovery network for application tests that need network access. Record the backup time, last successful sync time, restore duration, key fingerprint, and test result. A restored VM that only boots is not yet proof that its application works.
You can also pull the encrypted remote backups into a trusted recovery PBS and decrypt them during the transfer. This needs another datastore with enough capacity. Do not enable decryption on a server that should only hold unreadable backups.
On the trusted recovery PBS:
recovered on its own mounted backup storage.pbs2-recovery, using the read-only recovery token and verified certificate fingerprint.Backups from remote namespace site-a go into the root namespace of the local datastore recovered. Add the matching keys to decrypt them. active-encryption-key has no effect on pull jobs.
Verify the recovered datastore and test a restore from it:
Keep the encrypted remote copy. Secure the recovery datastore because its backups are unencrypted.
Choose push or pull based on where the job runs and whether you need to encrypt or decrypt backups.
Pull jobs do not encrypt plain backups. For an encrypted remote copy, use client-side encryption or the encrypted push setup above.
At this point, you have learned to set up encrypted sync jobs in Proxmox backup server. Keep an encrypted off-site copy, save recovery keys away from the main site, and check backups regularly. Test a restore without the primary PBS to confirm you can recover when the main site is unavailable.
Remember to host your secondary PBS on a reliable dedicated server in a different location.