Offsite
Offsite Proxmox Backup Server, because local is not a copy
The most common finding in a Proxmox backup review is not a failed job. It is that the backup datastore lives on the same hardware, in the same rack, in the same building, as the VMs it is protecting.
What 3-2-1 means on Proxmox specifically
- Production VMs on your PVE cluster — that is the one copy everybody has
- A local PBS datastore or snapshot for fast restores of a single VM or file
- An offsite PBS datastore on separate hardware in a separate building
- Sync jobs that move chunks between them on a schedule you can inspect
- Verify jobs on the offsite copy, because an unverified remote copy is a hope
Why the offsite copy fails in practice
None of these are exotic. All of them are things we find.
- The sync job was configured once and has been failing for months unnoticed
- The offsite target filled up and jobs began failing silently
- Retention on the offsite copy is shorter than anyone believes it is
- The offsite copy has never been restored from, only written to
- Both copies share a credential, so one compromise reaches both
How it is connected
- Added as a Proxmox Backup Server storage target in Datacenter → Storage
- Server address, datastore name, and TLS fingerprint supplied by us
- An API token scoped to your datastore, without prune or delete rights
- Outbound from your cluster on TCP 8007 — nothing opens inbound towards you
- Rate-limited where the uplink is shared with production traffic
Questions people ask on this
How much bandwidth does this need?
The first run is a full copy and is bounded by your uplink. After that, PBS sends only changed, deduplicated chunks, which for most estates is a small fraction of the first run. Where the link is shared with production we rate-limit the job so the initial seed does not saturate the site during business hours.
Is the data encrypted before it leaves our network?
With client-side encryption enabled, yes — PBS encrypts the chunks on your side and we never hold the key or the plaintext. That is the configuration we recommend and the one your auditors will prefer. It carries a real duty: if you lose the key, those backups are unrecoverable by anyone, including us.
Can we restore directly from the offsite copy?
Yes. It is a normal PBS datastore attached to your cluster, so restores work the same way as from a local one — full VM, container, or file-level. Speed depends on your link rather than on anything we control, which is exactly why a local copy for fast restores and an offsite copy for disaster are complementary rather than alternatives.
What about immutability against ransomware?
Proxmox Backup Server has no immutability or WORM feature — no flag, no retention lock, no certification. Real protection comes from the content-addressed chunk store, ZFS snapshots on the datastore, tokens without delete rights, and optionally S3 Object Lock on a synced bucket. Our security page sets this out in full, including what we previously got wrong about it.
Find out whether your offsite copy is real
The health check reports whether an offsite copy genuinely exists, whether its sync jobs are passing, and when anything was last restored from it.