Proxmox Backup Server on a Storage VPS

Build a capacity-focused off-site PBS repository with an SSD system disk, HDD datastore, narrow credentials and restore tests that prove recovery works.

Explore Storage VPSOfficial PBS docs
HYEHOST mascot connecting Proxmox VE to encrypted Storage VPS backups and a verified restore

Proxmox Backup Server gives Proxmox VE native incremental backups, deduplication, client-side encryption, retention, verification and file-level recovery. A HYEHOST Storage VPS can make a practical remote PBS target when usable capacity and geographic separation matter more than all-flash ingest speed.

This guide is deliberately about the details that decide whether that design works: memory per terabyte, where the datastore is mounted, how many jobs run together, when verification happens and how often somebody actually restores a guest. For a shorter installation walkthrough, start with our general Proxmox Backup Server guide.

When Storage VPS Is the Right PBS Target

HYEHOST Storage VPS separates a small SSD boot disk from HDD data capacity. The storage platform uses enterprise drives in RAIDZ2 across multiple vdevs, striped NVMe cache and a separate QSFP+ backend network. Public connectivity starts at 1Gbps, with a 10Gbps port option that keeps the plan's transfer allowance unchanged.

The published baseline is up to 100 MB/s sequential read, 75 MB/s sequential write and 300 IOPS, with short cached bursts possible above those figures. That profile suits overnight backup jobs, archives and a secondary recovery copy. It is not a promise that dozens of simultaneous random-I/O jobs will behave like local NVMe.

WorkloadRecommended designReason
Lab or small clusterProxmox VE direct to remote PBSSimple, low cost and genuinely off-site
Busy production clusterLocal fast PBS, then sync to Storage VPS PBSFast local restores with a remote failure domain
High concurrent ingestDedicated PBS storageMore predictable IOPS, RAM and maintenance windows

Size Proxmox Backup Server Honestly

The current Proxmox production guidance starts at four CPU cores and at least 4 GiB RAM, plus roughly 1 GiB of RAM per TiB of storage. The 2-core, 2 GB evaluation minimum is not a sensible target for a growing production repository.

Usable datastoreMemory target from guidancePractical note
1-2 TiB6-8 GiBSmall estates and a limited number of concurrent jobs
4 TiBAt least 8 GiBStagger backup, prune and verification windows
8 TiBAt least 12 GiBConsider local PBS plus remote sync for busy clusters
12 TiBAt least 16 GiBWatch chunk metadata and verification duration
20 TiBAt least 24 GiBDiscuss a resource upgrade or dedicated design

Leave free capacity too. Deduplication is useful, but it is not a capacity plan: the result depends on guest data, churn and retention. Alert before the datastore becomes tight enough to interrupt new backups or garbage collection.

Install PBS on Debian

Use a supported Debian release and the repository instructions from the current Proxmox installation guide. Repository suites and package signing details change, so copy those values from Proxmox rather than an old command pasted from a forum. Once the repository is configured:

apt update
apt full-upgrade -y
apt install proxmox-backup-server

Confirm the PBS hostname resolves correctly, install a trusted TLS certificate where appropriate and open the management interface at https://pbs.example.net:8007. Configure notifications before the first scheduled job.

Prepare the HDD Datastore

Identify the SSD system disk and HDD data volume before formatting anything. The following commands are inspection steps, not permission to erase an unfamiliar device:

lsblk -o NAME,SIZE,FSTYPE,UUID,MOUNTPOINTS,MODEL
findmnt /
df -hT

For a virtual data volume, ext4 or XFS is a clean choice. Do not add another ZFS layer inside the guest merely because PBS can run on ZFS; the HYEHOST storage platform already provides RAIDZ2 protection and cache below the VM. After formatting the correct empty volume, mount it persistently by UUID:

mkdir -p /mnt/pbs-data
blkid /dev/vdb
# Add the UUID to /etc/fstab, then verify it:
mount -a
findmnt /mnt/pbs-data
df -hT /mnt/pbs-data

Create the datastore only after the mount survives a reboot:

proxmox-backup-manager datastore create offsite /mnt/pbs-data

Ext4 and XFS provide the directory capacity required by the PBS chunk namespace. Never let PBS silently create the datastore on the SSD root filesystem because the intended data volume failed to mount.

Connect Proxmox VE with Narrow Permissions

Create a dedicated PBS user and one API token per source cluster. Grant the token DatastoreBackup on only /datastore/offsite. Keep prune, delete and administration rights away from the source hypervisor so stolen Proxmox VE credentials cannot erase every recovery point.

  • Restrict TCP 8007 to known source and management addresses, a VPN or private network.
  • Enable two-factor authentication for interactive administrators.
  • Use client-side encryption where required and store the key outside both systems.
  • Send failed jobs, verification errors and capacity warnings to a monitored destination.
  • Use a separate token for each cluster so it can be revoked without disturbing the others.

In Proxmox VE, go to Datacenter > Storage > Add > Proxmox Backup Server. Enter the PBS hostname, datastore, token identity, secret and TLS fingerprint. Start with one non-critical guest and inspect both task logs before scheduling the estate.

Schedule PBS for Capacity Storage

HDD-backed storage behaves best when heavy jobs do not all arrive at once. Split large clusters into groups, stagger start times and avoid running backup ingest, full verification and garbage collection together.

WindowTaskPurpose
NightlyStaggered backup jobsKeep concurrency within the repository's real throughput
After backup windowPrune expired snapshotsApply the retention policy
Separate quiet windowGarbage collectionReclaim chunks no remaining snapshot needs
FrequentVerify new or expired dataCatch recent corruption early
At least monthlyReverify all backup dataRead older chunks before they are needed

Prune and garbage collection are different jobs. Prune removes snapshots from the retention set; garbage collection later reclaims unreferenced chunks. Schedule both and give GC enough uninterrupted time to complete.

Use Retention That Matches Recovery

A small environment might retain seven daily, four weekly and six monthly recovery points. A database with a short recovery-point objective may need more frequent application-aware backups. Model the policy against changed data and measured deduplication instead of multiplying the source disk size by the snapshot count.

If you run a local PBS and sync to the remote instance, decide whether removals propagate. A remote retention policy that is deliberately independent can preserve recovery points after a mistake or compromise at the primary site. Proxmox sync jobs understand PBS datastores and transfer missing chunks; ordinary file synchronisation tools do not.

Run a Measured Restore Drill

A green job says the server accepted data. It does not prove that the team can recover a service. Restore a small VM to a new ID on an isolated network, boot it, check application data and record the elapsed time.

  1. Select a known backup snapshot in Proxmox VE.
  2. Restore it with a temporary VM ID and disconnected network interface.
  3. Boot the guest and verify files, databases and service startup.
  4. Record download throughput, restore duration and manual steps.
  5. Confirm the encryption key and credentials were available from outside the failed systems.
  6. Repeat quarterly and after major backup-platform changes.

That measurement tells you whether the 1Gbps port is enough, whether a 10Gbps upgrade would help, and whether the repository belongs on dedicated hardware.

Proxmox Backup Server on Storage VPS FAQ

Can Proxmox Backup Server run on a Storage VPS?

Yes. It is a useful design for smaller off-site repositories and secondary PBS copies. Size RAM for the datastore, stagger I/O-heavy work and use dedicated hardware when concurrency or recovery targets demand more predictable performance.

Should the PBS datastore use HDD or SSD?

HDD is economical for capacity-focused backup retention. SSD or NVMe is better for high ingest concurrency and faster random I/O. HYEHOST Storage VPS pairs HDD data capacity with a separate SSD boot disk and platform-level NVMe cache.

How much RAM does PBS need?

Proxmox recommends at least 4 GiB for production plus roughly 1 GiB per TiB of storage. Treat that as a starting point and increase it for large namespaces, heavy verification or concurrent jobs.

Does the 10Gbps option make restores ten times faster?

Not automatically. It removes a 1Gbps port ceiling, but source speed, route, HDD throughput, IOPS and workload shape still determine the result. The monthly transfer allowance also stays the same.

Is one remote PBS a complete 3-2-1 strategy?

No. It creates a valuable separate copy, but important systems should retain another independent copy and offline access to encryption keys and recovery credentials.

Build the Repository Around Recovery

A useful off-site PBS deployment is quiet and predictable: enough RAM, a datastore mounted on the right volume, limited credentials, non-overlapping maintenance jobs and a restore procedure already used by the team. Start with one guest, measure the full path and expand only when recovery works.

Compare HYEHOST Storage VPS plans for capacity-focused repositories, or choose a dedicated server when the backup window, repository size or isolation requirement calls for its own hardware.

Official Proxmox Resources