Running PBS on the Same Host? Why Your Backups Might Crawl

So you've got a monster server with 24 cores, 256 gigs of DDR5 RAM, and a Gen5 datacenter NVMe that could outrun most SSDs in its sleep. And yet… your Proxmox Backup Server (PBS) chugs along at a sluggish 200MB/s when backing up VMs. What gives?

This is the exact headache one user ran into after deciding to host PBS inside a VM on the same Proxmox node it was backing up. On paper, the setup screams performance. In practice, the speed graph looked more like a tortoise on a treadmill.

Here's why this happens, and why no amount of raw hardware muscle can save you from virtual bottlenecks if you're not careful.

The problem: when high-end hardware underperforms

In this case, the server had every performance checkbox ticked: blazing fast NVMe (Kingston DC3000ME Gen5), gobs of memory, and CPU headroom for days. There was no load on the system and no apparent I/O bottleneck, and yet backups plateaued around 350MB/s read/write.

What made it worse was the drive's advertised specs of over 10,000MB/s in both directions. You expect snappy backups, not a traffic jam. So where was all that speed going?

VM networking: your first suspect

Here's the big "aha" moment: running PBS inside a VM on the same Proxmox host means all backup traffic has to travel through virtualized layers, including virtual NICs that can drag performance down without any obvious sign.

The Reddit user suspected this and was right to do so. The virtual NIC (likely defaulted to VirtIO) introduces some overhead, and when you're backing up a few hundred gigs, that adds up. Virtual network interfaces don't always saturate the same throughput as native ones, especially when you don't optimize for multi-queue support or jumbo frames (MTU 9000).

Another commenter chimed in with a recommendation: match your NIC's multiqueue setting to the number of vCPUs and crank up your MTU size. That might not sound like a silver bullet, but it often delivers immediate gains.

LVM and virtual disk overhead

A closer look at the setup reveals the PBS VM uses a virtual SCSI disk with SSD emulation enabled, layered on top of LVM. Sounds cool, but it's one abstraction layer too many. Performance often takes a hit when you're moving data across multiple virtualized volumes, especially when both read and write streams are dancing between LVM layers.

While SCSI is fine in general, running heavy I/O through this virtual pipe on top of a host-based LVM can add latency to reads and also during write amplification, syncs, and compression. And that's before we even talk about PBS's own deduplication and chunking workload.

CPU and RAM? Probably not your problem

The system reported just 30% CPU usage and 3% RAM usage during backup, so raw horsepower isn't what's missing.

What you're likely looking at is a software-driven bottleneck where virtualized I/O and PBS's internal mechanics are not playing nice. And if your CPU's doing too little, the bottleneck may be happening earlier in the pipeline, most likely in the data path between the source VM and the PBS storage.

The alternative: bare metal or hybrid install

Several voices in the thread echoed the same sentiment: "Why not just install PBS directly on the Proxmox node?"

It turns out that's possible, and even efficient. You can install PBS alongside Proxmox on the same physical server using a simple apt install proxmox-backup-server after adding the repo. This way, PBS has direct disk access, and you skip the VM overhead entirely.

If you don't want to go full bare metal, a hybrid setup using LXC containers with bind mounts might be a sweet spot. One user noted better performance running PBS in an LXC versus a full VM, likely because LXCs skip the virtual disk layers and go straight to host storage.

"But what if my node dies?"

It's a valid concern. Running PBS and Proxmox on the same server feels risky, because if the host blows up, what happens to your backups?

This is where good storage hygiene comes into play. Some users combat this by placing backup storage on a completely separate drive, isolated from the Proxmox system disk. That way, even if the OS gets nuked, you can reinstall and mount your backup volume without data loss.

Others take it further by setting up multiple PBS instances across separate nodes and syncing backups between them. Yes, that's more complex, but it gives you redundancy, and peace of mind is worth it.

FIO testing: measure instead of guessing

Want hard numbers? One savvy commenter dropped an FIO command to benchmark real-world disk performance from inside the PBS VM. This test tells you whether your bottleneck is disk I/O or somewhere else.

Here's the kind of command they suggested:

fio --name=seq-read128k --ioengine=io_uring --rw=read --bs=128k --size=2g --numjobs=8 --iodepth=64 --runtime=20 --time_based --group_reporting

Run that inside your VM and compare it with host performance. If your VM is significantly slower, you've got your culprit.

TL;DR: why your PBS VM is slow

• Virtual NIC overhead can throttle performance. Try jumbo frames (MTU 9000) and multiqueue.
• A virtual disk over LVM adds unnecessary latency. Consider direct disk access or bind mounts.
• Running PBS in a VM on the same node causes backup traffic to loop through virtual layers.
• PBS on the host (bare metal or containerized) is often faster, and sometimes simpler.
• Separate disks for system and backup storage reduce risk and increase speed.
• Benchmarking with FIO shows your real-world I/O limits.

Final thoughts

Putting PBS inside a VM seems like a clever way to keep things modular. In practice, though, it often leads to performance bottlenecks that waste your time and hardware potential.

If you're hitting the same speed walls, take a hard look at how you're layering your stack. Sometimes the fix is to peel back the layers that are slowing you down, rather than throwing more hardware at the problem.