Limit PBS backup bandwith speed

ca_maer

Well-Known Member
Dec 5, 2017
181
14
58
44
Hello,

Is there a way to limit the speed at which PBS backups our servers ? I'm asking because it takes all our NIC bandwith which make our VM pretty much unreachable during the backup schedule.

I've tried to edit /etc/vzdump.conf but it seems to ignore it when using PBS.

Thanks
 
From the PVE go to the Datacenter -> Options -> Bandwidth Limits you can set the limit bandwidth
 
That would set a limit on the whole PVE right ? There is a backup restore limit option but what about a limit for the the actual backup job ?

Thanks
 
Maybe I don't understand correctly but this seems like the previous solution you proposed which is for when RESTORING a backup. What about limiting the backup when the datacenter backup job is running and WRITING to our backup storage ?
 
If you look in your log of the backup, can you see the line relating to the "dirty-bitmap"?

What does it say?

I ask because I also have a backup that seems to "ignore" or not use the dirty backup, and take about 4.5 hours, and another set of servers where the "dirty-bitmap" is used and the backup takes minutes. In both cases the VM has about 1gb data.
 
Hi Ca_Maer,

for Writing backups and being "nice" to your I/O you could use the IONICE variable inside the VZDUMP.conf.
this should help to not limit the bandwidth while writing the backup but helping the source PVE host to priotize the VZdump differently differently (lower/higher) and "be nice" to the other processes requesting I/O on the same PVE host...
1636453673938.png

result:
1636453656384.png


cheers
Stephan
 
Last edited:
@brian:
to my experience the dirty-bitmap is only used if a) the instance you like to backup was not rebooted from PVE since last backup and(!) b) not migrated from one to another cluster node since last backup.

...but i also like to learn if your issue might have another reason...

rgds
Stephan
 
the rate limits are applied already, >= 2.1.0-1, with some follow-ups up to 2.1.2-1
 
  • Like
Reactions: Tony
mind, that limiting network or disk io bandwith on the PBS will also limit i/o in the guests being backed up.

during PBS backup, i/o in a guest is being buffered in RAM and getting throttled in the guest when the PBS is slow.
 
Hi, in case this is helpful for other people, (or for me to find this hint in future :) )

I've got a basic client site config with
Proxmox server onsite at office
PBS server onsite at office
PBS server offsite in data centre in nearby city / for offsite data sync from PBS_onsite replication of backups

The challenge is that the office has a pretty mediocre ISP service (200meg down Cable modem with 10meg up as bandwidth)
which means at 100% throughput for upload from office>datacentre PBS data sync, it will use all the upload bandwidth
which is ~1Mb/second throughput upload on the 10Mbit connection

So, with some google fun digging, I learned about 'wondershaper' which is a small script available on debian

and I've setup a trivial cron config on my onsite PBS host

so that every day Monday-Friday at 7am it will throttle upload bandwidth to 4Mb or ~400Kb/s upload speed
and then Monday-Friday at 8pm it will relax things to allow full speed upload at ~10-11Mb or ~1Mb/s upload speed

So far this seems to do the trick, if I've got long-running PBS jobs that span multiple days, they don't care if things are throttled at the client site office side of things. The connections remain active-ongoing, they are just being throttled at the linux stack side of things on the client-site PBS box.

For clarity - the intent of this setup, is to allow staff at the office to work M-F during 'normal hours' and have limited impact on the day-to-day work people are doing. Most of what the staff want is download bandwidth constrained with some modest upload requirements (intermittent zoom - teams calls) plus of course any upload required for download to work smoothly (ie, ACK). The secondary goal here is to allow PBS backup jobs to just keep running if required for >24 hours and allow things to gently throttle down and up / so that we get better PBS bandwidth use outside of core office hours. Right now the office onsite PBS backups are 'not up to date' so need multiple days to get caught up. The expectation is that - with full weekend of full bandwidth, plus all week with ~night time full bandwidth and dayime ~half bandwidth - the PBS offsite server will get caught up at least once per week. But it might be playing catch-up for many other days of the week. Which is tolerable.

So. lots of fun. In perfect world we just get a bigger pipe outbound at this site, but that isn't going to happen anytime soon, so here we are.

So, in case this is helpful here is what my config looks like for reference -pasted below.

-Tim

Code:
CRON HINT
========================================================
Min  Hour Day  Mon  Weekday
*    *    *    *    *  command to be executed
┬    ┬    ┬    ┬    ┬
│    │    │    │    └─  Weekday  (0=Sun .. 6=Sat)
│    │    │    └──────  Month    (1..12)
│    │    └───────────  Day      (1..31)
│    └────────────────  Hour     (0..23)
└─────────────────────  Minute   (0..59)

BASELINE SPEED OBSERVED on the onsite PBS box with no throttle and active PBS job uploading:
============================================================================================
root@pbs:~# ifstat
      enp3s0              enp2s0
 KB/s in  KB/s out   KB/s in  KB/s out
    0.00      0.00     22.30   1156.94
    0.06      0.00     27.77   1096.26
  
  
CRONTAB ENTRIES FOR THROTTLE CONTROLS AUTOMATION:
=================================================

### MON-FRI we INCREASE speed for upload to ~11MB at 8pm
0 20 * * 1,2,3,4,5  wondershaper enp2s0 110000 11000
## MON FRI we drop speed upload to ~4MB at 7am
0 7 * * 1,2,3,4,5 wondershaper enp2s0 110000 4096




ONCE THROTTLE IS IN PLACE WE SEE BANDWIDTH
===========================================
root@pbs:~# ifstat
      enp3s0              enp2s0
 KB/s in  KB/s out   KB/s in  KB/s out
    0.06      0.00     11.81    533.66
    0.00      0.00     11.91    539.17
 
Last edited:
sync jobs come with built-in rate-limiting as well, but of course, that doesn't offer time-based control.

you could setup Traffic Control on the local PBS though, since it is the "server" in this scenario (the offsite PBS is the client pulling the backup data). it offers control over upload or download, including time-based rules and network based matching.
 
Hi Fabian, thank you for pointing this out. For sure the built-in traffic control is the clean way to do this. I realize now as I look, this client is setup on old not latest PBS version. I need to get them updated. Ugh. The version they are running lacks this traffic control. Definitely another good reason to move them up to current-latest version (!)

-Tim
 
  • Like
Reactions: fabian
Footnote, I realize that the wondershaper version available in debian via apt-get is old (v1.x not v2.x) and the flags are different between these versions / and some folks online suggest v1-older has 'issues' maybe. I did find today that after things were throttled - the inbound data rate to the PBS host for local proxmox>PBS backup - was behaving as if throttled, ie, not ideal.

so, I just (finally) pushed upgrades on PBS onsite and offsite hosts, got them up to latest.
now I've got the built-in throttle controls in the PBS gui
and
just reviewed it now as the evening jobs are running, and things look great

so

- in theory wondershaper might be ok, but maybe safer to use a more-current version (pulled manually via git from source repo...)
- or otherwise simpler to just keep PBS up to date, and use the built in awesome that is already there in PBS.

so, just small footnote on the thread..


Tim
 
  • Like
Reactions: fabian

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!