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.
| Workload | Recommended design | Reason |
|---|---|---|
| Lab or small cluster | Proxmox VE direct to remote PBS | Simple, low cost and genuinely off-site |
| Busy production cluster | Local fast PBS, then sync to Storage VPS PBS | Fast local restores with a remote failure domain |
| High concurrent ingest | Dedicated PBS storage | More 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 datastore | Memory target from guidance | Practical note |
|---|---|---|
| 1-2 TiB | 6-8 GiB | Small estates and a limited number of concurrent jobs |
| 4 TiB | At least 8 GiB | Stagger backup, prune and verification windows |
| 8 TiB | At least 12 GiB | Consider local PBS plus remote sync for busy clusters |
| 12 TiB | At least 16 GiB | Watch chunk metadata and verification duration |
| 20 TiB | At least 24 GiB | Discuss 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.
| Window | Task | Purpose |
|---|---|---|
| Nightly | Staggered backup jobs | Keep concurrency within the repository's real throughput |
| After backup window | Prune expired snapshots | Apply the retention policy |
| Separate quiet window | Garbage collection | Reclaim chunks no remaining snapshot needs |
| Frequent | Verify new or expired data | Catch recent corruption early |
| At least monthly | Reverify all backup data | Read 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.
- Select a known backup snapshot in Proxmox VE.
- Restore it with a temporary VM ID and disconnected network interface.
- Boot the guest and verify files, databases and service startup.
- Record download throughput, restore duration and manual steps.
- Confirm the encryption key and credentials were available from outside the failed systems.
- 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.

