Backups / Cloud

Build an Offsite Proxmox Backup Server Replica on a Cheap VPS

A backup server in the same building as everything it protects is not a disaster recovery plan. A second, independent backup instance on a cheap cloud VPS closes that gap for a few dollars a month. Done right, it does not need to trust the network it is protecting against.

Picking the VPS

You do not need much. If you replicate only VM and container backups, not bulk media or file shares, a small instance is plenty. One vCPU, a couple of GB of RAM, a modest boot disk. The backup data lives on a separate attached block-storage volume sized to your real dataset. Size that volume from du -sh on your actual backup datastore path, not df on the mount. The two numbers differ by an order of magnitude on a shared NAS export.

BE WARNED: check your backup software's OS support before provisioning. Proxmox Backup Server only ships packages for Debian. There is no Ubuntu build at all, despite Ubuntu being the default option on most cloud providers' droplet-creation screens. Confirm against the vendor's own package repository listing before you install anything, not after.

DigitalOcean Droplets list showing two small droplets, IP addresses redacted — **DigitalOcean → Droplets.** A small droplet is plenty. The real capacity lives on a separate attached block-storage volume, not the droplet's boot disk. IPs redacted.

The instinct to "tunnel everything", and why it is the wrong tool here

If you already run a reverse tunnel to expose a NAT'd home service to the internet, it is tempting to reach for the same tool to "hide" the new backup server. Pause on that. A generic TCP tunnel changes which address traffic arrives at. It adds no access control of its own. It solves a NAT problem, not a security problem. A cloud VPS does not have a NAT problem. It already has its own public IP. Layering a tunnel on top adds complexity without adding the restriction you want.

What restricts access is a firewall rule scoped to a specific source IP. Most cloud providers offer this as a free built-in cloud firewall or security group, enforced at the network edge before traffic reaches the instance:

Inbound SSH restricted to your home's public IP only.
Inbound access to the backup server's own API/web port, same restriction.
Everything else inbound: denied by default.

Verify it right after you create it. Confirm you can still reach both ports from the allowed address, and ideally confirm from a second network that you cannot.

BE WARNED: your home's public IP can change. A rule this specific breaks silently when your ISP reassigns it. Check it periodically, and check it first if backups mysteriously stop syncing one day.

Does this backup replica need TLS?

Yes. Get a real, trusted certificate instead of clicking through a browser warning every time. If you do not have one going already, see running your own internal certificate authority. Here is the interesting wrinkle. A cloud VPS normally needs a certificate from a public CA like Let's Encrypt, because public CAs validate a domain by reaching it over the internet. But once you firewall this server down to your own home IP, it is functionally an internal-only service despite having a real public IP and DNS record. So it can use your existing internal CA the same way every other admin tool on your LAN does. No public-CA validation dance.

A DNS quirk worth checking while you are in there

Not specific to this setup. If the domain hosting this replica sits on a zone proxied through a CDN for your other public sites, set this record to DNS-only, not proxied. Backup server protocols and ports are not things a CDN's free-tier proxy passes through cleanly.

Locking down the sync credential

Scope the token your home backup server uses to push data offsite to the absolute minimum. Write new backups, nothing else. No delete, no prune, no modify rights. Then even if that credential leaks, or your home server is compromised, whatever gets hold of it cannot reach back and destroy backups that already landed offsite.

BE WARNED: verify the credential's real effective permissions, not what you granted it. Some platforms compute a token's access as the intersection of the token's own grant and its parent account's grant. A token looks correctly scoped in an access-control listing while its parent account has broader or narrower rights that change the real outcome. Use whatever command your platform provides for "what can this credential actually do", not "what was it granted".

Proxmox Backup Server Remotes configuration showing a remote entry with host, auth ID, fingerprint, and comment — **Proxmox Backup Server → Configuration → Remotes.** The offsite target registered as a PBS "Remote". This is what the push-only sync job below points at.

Configure a one-way, push-only sync, and disable "remove vanished"

Point your home backup server at the new offsite instance and set up a push sync job, home to offsite, not a pull. Then find the option usually called "remove vanished" or "delete extraneous" and make sure it is off. That setting mirrors deletions. If a backup disappears from the source, the next sync deletes it from the destination. That is exactly the behaviour you do not want on a disaster-recovery copy. A ransomware event, a fat-fingered delete or a bug on the home side should never cascade into wiping the offsite copies.

The honest answer about "immutable" backups

Free and community-tier self-hosted backup software does not offer true WORM or immutable storage. The kind where nothing, not even an admin with full access, can delete or modify a backup before its retention period expires. That belongs to paid object-storage tiers with S3-style object lock, or dedicated enterprise backup appliances. A self-hosted community tool does not implement it internally. Do not assume a commercial licence for the same self-hosted tool adds it either. Check the product's actual feature list. A paid tier does not always mean more security features. Sometimes it is purely support and repository access.

The two mitigations above cover a real and specific threat model. A compromised home network or a leaked sync credential cannot reach back and destroy the offsite copies. Here is what they do not cover. Someone with direct root access on the offsite instance deliberately deleting files. If that level of protection matters to you, swap the backend storage for something with real object-lock support. That is a bigger architectural decision than anything here.

Test it before you trust it

Trigger the sync job by hand once and watch it transfer real data. A green checkmark on the job configuration means nothing. Check the destination instance directly too. Its disk usage growing and a snapshot list populating is the only real confirmation data arrived, rather than just left the source.

BE WARNED: a job-listing command can lie by omission. On at least one platform, "list all sync jobs" returned an empty result immediately after a job was confirmed created and configured correctly. Asking to "show" that specific job by name or ID returned it just fine. If a list view looks suspiciously empty right after you create something, check the specific item directly before you assume it did not save.

BE WARNED: intermittent connection timeouts to a brand-new cloud instance do not necessarily mean anything is wrong. Small, freshly provisioned cloud instances show transient network-path flakiness for a while after creation, especially under install or configuration load. One connection attempt timing out is not proof of a real outage or a firewall misconfiguration. Check the provider's own dashboard first. Is the instance reported healthy? What do its CPU and network graphs show? Retry with a short backoff before you conclude something is broken.

Reminder: a fresh cloud instance has no password set on its administrative account. Most providers configure key-based login only. If you need to log into a web UI that wants a username and password rather than your SSH key, set one on the instance first.