Feature suggestions for PBS backup speedup.

[tomtom13]

Hi,
After some testing and feedback from proxmox staff, I would suggest:
1. reenable change of compression level during backup to PBS (now it's locked to ZSTD, but in the past it allowed uncompressed). At this point forcing compressions can make CPU bottleneck and also increase load on the node that is not desirable (while not reaching note connectivity limit). This situation might get even worse when several nodes are dumping backups in parallel to PBS hammering PBS cpu down to a crawl. Some, are prepared to sacrifice those bottleneck at expense of storage (specially if they are aware that backups are not really compressible or don't care)
2. allow to change amount of threads used / max cpu load / "nice" for backup process, as on high thread count cpu's it seems to be sitting idling, while on low power cpu's it seems to hammer the node down to level on unusable.
3. cached on the storage block checksums. So, as far as it was explained to me, during a backup (specially CT) blocks are checksummed and compared between nodes before transferring. When several nodes are dumping their backups to PBS, underlying storage becomes a bottleneck, while having a cached (in file on disk) checksums of blocks that are compared, shall improve overall performance (since backups are not changing after hitting the PBS storage)

 

[Dunuin]

This situation might get even worse when several nodes are dumping backups in parallel to PBS hammering PBS cpu down to a crawl.

As far as I understand the compression and hashing is done client-side and PBS is just decompressing it when doing verify tasks. But yes, something less CPU intense like LZ4 would be a nice alternate option to ZSTD for PVE hosts that are using a way to slow CPU (like my Intel Atom).

2. allow to change amount of threads used / max cpu load / "nice" for backup process, as on high thread count cpu's it seems to be sitting idling, while on low power cpu's it seems to hammer the node down to level on unusable.

Jep. That would be nice. Workround would be to limit the backup bandwidth to reduce load on the clients.

 

[tomtom13]

As far as I understand the compression and hashing is done client-side and PBS is just decompressing it when doing verify tasks. But yes, something less CPU intense like LZ4 would be a nice alternate option to ZSTD for PVE hosts that are using a way to slow CPU (like my Intel Atom).

If people want different compressions - let’s give them that, BUT i would still strongly opt for NO Compression - since pbs can get hammered down with decompression tasks, and in many cases that significant slow down for maybe 5% space saving is pointless.

 

[tomtom13]

Jep. That would be nice. Workround would be to limit the backup bandwidth to reduce load on the clients.

That workaround is really suboptimal since fast storage nodes will be slow down by a slowest nodes in cluster. Why I would slow down backups to 50MBps if some nodes hapille can handle 4GBps ? and still have the slow nodes suffer.