Offsite Backups for Proxmox: Proxmox Backup Server, Remote Sync and Cloud Object Storage for Small Business
Three ways to get a verified, encrypted copy of your Proxmox backups out of the building, what each costs, and the restore evidence an insurer will ask to see.
By William Bradshaw | November 2, 2026 | 10 min read
A lot of small Proxmox hosts are protected by a nightly vzdump job that writes to a second disk, or a NAS, in the same rack. That is a real backup. It is also one power surge, one failed controller, one fire or one ransomware event away from losing the server and its only copy together. The backup and the thing it protects share a fate.
Cyber-insurance questionnaires have noticed. The backup section now routinely asks whether you keep a copy offsite, whether any copy is offline or immutable, and when you last proved a restore works. For an Ohio township or fire district, the same questions show up when you document your cybersecurity program under ORC 9.64. This article covers the three practical ways to put a Proxmox Backup Server (PBS) copy somewhere else, what each costs in money and in effort, and the evidence to keep.
It assumes you already run Proxmox VE. If you are still sizing the hardware, start with our Proxmox host sizing guide, which covers where backup storage fits in the budget. For the policy side (recovery objectives, the 3-2-1-1-0 rule, what insurers ask), see backup and disaster recovery for Ohio public entities. Version note: everything below reflects the PBS 4.x series as of early November 2026, with 4.2 the most recent release we checked. Proxmox changes this area quickly, so confirm details against the release notes for your version.
What Proxmox Backup Server Adds Over vzdump
vzdump writes a full archive of each guest to a file. It works, it is built in, and it is easy to reason about. It is also heavy: every run copies everything, so a 2 TB environment either burns a lot of disk or keeps very few restore points.
PBS is a separate backup server product built to remove those limits. The features that matter to a small office:
- Deduplication. Data is stored as chunks, and a chunk that already exists is stored once. Ten nightly backups of mostly unchanged virtual machines cost far less than ten archives.
- Incremental backups. After the first run, only changed data crosses the wire. This is what makes an offsite copy over a business internet connection realistic at all.
- Verification jobs. PBS can re-read stored chunks on a schedule and check them against their checksums, so you find a damaged backup before the day you need it.
- Retention and pruning. Keep-last, daily, weekly and monthly rules are set once on the datastore instead of in a script.
- Client-side encryption. Backups can be encrypted before they leave the Proxmox host, so whoever holds the offsite copy (a partner site or a storage provider) never sees your data. Store the key separately from the backups, and print a copy: without the key, the encrypted backups cannot be restored.
PBS runs happily on a small dedicated machine or a virtual machine, but treat it like the safe it is: not on the same host and datastore it is protecting. Our Proxmox hardening guide covers locking down the hosts themselves, which applies to the backup server too.
Three Offsite Patterns, Compared
There is no single right answer. Most small offices end up with one of the first two patterns, and a few add the third for a copy ransomware cannot reach.
Pattern A: a second PBS at another site, fed by a sync job
PBS has a remote and sync job feature: one PBS pulls snapshots from another on a schedule. The offsite server can pull from the office (so the office holds no credentials to the offsite box), and since PBS 3.3 a push direction also exists, which helps when the offsite server cannot open connections back to you. PBS 4.2 added the option to encrypt snapshots during a push sync and decrypt them on a pull. Good fits are a township with a second building, two small offices that back each other up, or a modest server at a partner location. You carry the cost of a second machine, its disks, its patching and its power.
Pattern B: a PBS datastore on S3-compatible object storage
The S3 backend (introduced as a technology preview in PBS 4.0 and reported as no longer a preview in 4.2) lets a datastore keep its chunks in an S3-compatible bucket instead of on local disk. Providers named in community write-ups include Backblaze B2, Wasabi, Hetzner Object Storage, AWS S3 and self-hosted MinIO; Proxmox does not publish a certified list that we found, so test the provider you plan to use. PBS keeps a local cache on disk, so you still need a small local disk on the PBS machine. There is no second site to maintain, and you pay a monthly storage bill. Restores run at the speed of your download link.
Pattern C: removable media or tape for an air-gapped copy
PBS has long supported removable datastores and tape. A rotated set of USB disks or LTO cartridges, kept somewhere else and physically disconnected, is the one copy that an attacker on your network cannot touch. It is manual, so it only works if someone owns the rotation and a calendar reminder.
| Question | A: Second PBS, sync job | B: S3-compatible datastore | C: Removable media or tape |
|---|---|---|---|
| Up-front cost | A second server and disks | Small local cache disk | Drives or a tape drive plus cartridges |
| Running cost | Power, space, patching | Monthly storage, possible download charges | Staff time for rotation |
| Restore speed | Network speed between sites; or carry the box | Your download bandwidth | Fast once the media is in hand |
| Ransomware reach | Low with a pull job and separate credentials | Depends on credential handling (see below) | None while disconnected |
| Effort to keep honest | Keep a second machine patched | Watch the bill and the cache | Someone must actually rotate it |
A Worked Example: A 2 TB Office
These figures are illustrations built on stated assumptions, not quotes. Replace them with your own numbers and your provider's current price sheet before you decide.
Assumptions
- 2 TB of used guest data across a dozen virtual machines.
- Deduplication and compression bring the first stored copy to about 1 TB (this varies a lot; databases and media compress less).
- About 1 percent of data changes per day, which after deduplication is on the order of 10 to 20 GB a night.
- Retention of 14 daily, 8 weekly and 6 monthly restore points, which we assume grows the stored size to roughly 1.5 TB.
- A 50 Mbps business upload link, assuming about 80 percent of it is usable.
Seeding. One terabyte at 50 Mbps is roughly 160,000 seconds at full speed, so plan on two to three days for the first copy. Run it over a weekend, and throttle it during business hours. Pattern A can skip this by seeding the second server locally and then moving it, and Pattern C is limited only by disk speed.
Nightly traffic. 10 to 20 GB at the same link is well under an hour of transfer. The ongoing bandwidth is rarely the problem; the first copy is.
Pattern B cost. Take 1.5 TB of stored data and multiply by your provider's per-terabyte monthly rate. At an illustrative 6 dollars per terabyte per month, that is about 9 dollars a month, roughly 110 dollars a year. Then check three line items most price pages hide in the footnotes: minimum storage commitments, minimum retention periods that bill for deleted data, and download (egress) or request charges. A full restore of 1 TB is where egress matters, and a provider that charges for it at an illustrative 10 dollars per terabyte would add about 10 dollars to a rare event. The point of the arithmetic is the shape: storage is a small recurring number, and the real cost is the hour you spend verifying the restore path.
Pattern A cost. A second small server with two 4 TB disks in a mirror is a one-time purchase in the high hundreds to low thousands of dollars depending on what you buy, plus rack or shelf space, power and patching at the other site, and a VPN or tunnel between them. It pays back if you already have a second site, and it is more work than a bucket if you do not. Restores are fast if the server is on the same network and slower if you pull data across a link.
How to choose. If you have a trusted second location and someone who will patch the box, Pattern A gives you the most control. If you do not, Pattern B is usually cheaper than the second machine over three years and has less to maintain. Either way, add Pattern C once a quarter if you can: a disk that is unplugged costs the least and is the one copy that no credential theft can reach.
Immutability and Ransomware: What Actually Protects the Copy
A backup that an attacker can delete is a second copy of the problem. Modern ransomware operators look for the backup server and its stored credentials before they detonate. The rules below are about making that search fail. They map to the "one copy offline or immutable" line in the 3-2-1-1-0 rule we describe in the Ohio backup article.
- Prefer pull to push. If the offsite PBS pulls from the office, the office server holds no way into the offsite copy. If you use a push job, create a dedicated user for it, give that user the narrowest datastore role that works, and leave the option that removes vanished snapshots off so a deleted source cannot cascade.
- Separate credentials for each side. The offsite PBS, the bucket keys and the encryption key should not share a password or a password manager vault with domain admin accounts. Use API tokens with limited roles instead of the root account, and turn on two-factor sign-in for PBS administrators.
- The backup host is not domain-joined. A PBS server in your Windows domain falls with the domain. Give it local accounts, put it on its own network zone with only the ports Proxmox needs open from the hosts, and manage it from a hardened admin machine. Our Proxmox networking guide covers carrying zones into the virtual environment.
- Run verification jobs, and read their result. Verification catches silent corruption and gives you a dated record. A job that fails every night and nobody reads is not a control.
- Be careful with bucket object lock. It is natural to reach for Object Lock or versioning on the bucket for immutability. Reports on the 4.x series say the PBS S3 datastore does not support those features and that enabling Object Lock can damage the datastore. Check the current Proxmox documentation and test on a throwaway bucket first. Until Proxmox documents support, treat bucket-level immutability as unavailable and rely on credential separation and the offline copy in Pattern C.
- Keep one copy physically disconnected. Removable disks or tape, rotated and stored elsewhere, remain the only control that does not depend on any software behaving.
If you would rather not own this design yourself, our business continuity service builds and tests it, and our managed services team can run the verification jobs, the rotation and the quarterly restore test for you.
Prove It: A Test Restore Procedure and the Evidence to Keep
A backup you have never restored is a hope. Do this once a quarter, and after any major change to the backup design:
- Pick a real guest, not the smallest one. Rotate through your critical systems so each gets tested at least once a year.
- Restore it from the offsite copy, not the local one, to an isolated network or a spare host so it cannot collide with the live machine.
- Boot it and check what matters: the application starts, a known record is present, a user can sign in. Record how long the whole thing took from request to working.
- Compare that time to your recovery target. If it is longer, you have found the gap while it is cheap to fix.
- Delete the test guest, and write the one-page record.
The record is the evidence. Keep the date, the guest restored, the copy it came from, the time taken, the person who checked it, and the result. Add the verification job history, the retention settings, and a short note saying which copy is offsite and which is offline or immutable. That packet answers the backup questions on a cyber-insurance application and gives you something concrete to point to when you document the backup and recovery part of your cybersecurity program under ORC 9.64. For the Proxmox side of resilience, our virtualization services page describes how we build and document these environments.
Frequently Asked Questions
Is the Proxmox Backup Server S3 backend ready for production?
The S3-compatible object storage datastore backend was introduced as a technology preview in the PBS 4.0 series and, according to published coverage of the 4.2 release in spring 2026, is no longer labelled a preview. Check the release notes for the version you run, keep a local copy of your backups as well, and run a test restore before you rely on it.
Do I need a second Proxmox Backup Server at another site?
Not necessarily. A second PBS with a sync job is the simplest way to get a verified, deduplicated offsite copy, but an S3-compatible datastore removes the second server and the second site. The trade is a per-month storage bill and restore times set by your internet connection.
Can ransomware delete my offsite Proxmox backups?
It can if the credentials sit on a machine the attacker controls and they carry delete rights. Use a pull sync from the offsite server where you can, give any push credential the narrowest role that works, keep the backup hosts out of your Windows domain, and keep one copy on media that is physically disconnected.
How much internet bandwidth does an offsite PBS copy need?
The first copy is the slow one: a terabyte over a 50 Mbps upload link takes roughly two to three days. After that, only changed chunks travel, so a typical office with a few percent daily change moves tens of gigabytes a night and finishes in well under a few hours.
What should I keep as evidence of a working backup for cyber insurance?
Keep the dated test restore record (what you restored, from which copy, how long it took, who checked it), the verification job history, the retention settings, and a note showing which copy is offsite and which is offline or immutable. A one-page log per quarter is enough for most questionnaires.
Want Someone to Design and Test Your Offsite Copy?
Bullium builds and tests Proxmox backup designs for small offices, townships and fire districts: the backup server, the offsite pattern, the credentials, and the restore test record your insurer and auditor ask for. We start with a walkthrough of what you have today. No commitment to engage further.
Related Reading
Backup and Disaster Recovery for Ohio Public Entities
Recovery objectives, the 3-2-1-1-0 rule and what insurers ask about backups.
Proxmox Hardening for Small Business
Locking down the hosts and the backup server before the first incident.
Proxmox Networking: VLAN-Aware Bridges Explained
Giving the backup server its own zone.
Proxmox Host Sizing Guide
Where backup storage fits in the hardware budget.