Bandwidth limits seemingly ignored

28 views
Skip to first unread message

Slippy

unread,
Aug 31, 2020, 1:32:11 PM8/31/20
to bareos-users
Hello group,

I am trying to enforce bandwidth limits onto specific jobs/clients, and am finding no success. I add the following:
client .conf file:
   Maximum Bandwidth Per Job = 1024 k/s
job .conf file:
   Maximum Bandwidth = 1024 k/s

But neither seems to be limiting the bandwidth usage, which appears to be closer to 80mbps. I see a bug report from 6 years ago; my symptoms are the same: the service accepts my .conf edits, but the bandwidth never seems to change.

Is there a deeper understanding that I am missing, or is it possible that the bug still exists? Does anyone have bandwidth limits working in any capacity?

Thanks!
-Dave

Erich Eckner

unread,
Aug 31, 2020, 3:03:32 PM8/31/20
to bareos-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, 31 Aug 2020, Slippy wrote:

> Hello group,

Hi Dave,
I cannot comment on the bareos configuration part, but I *do* have
bandwidth limits working - I employ iptables and ip6tables on the
storagedaemon for that. The reason, why I never bothered with doing this
via bareos configuration, was, that I wanted to change the bandwidth of
already-running jobs, which is impossible by changing the config IIRC.

My configuration looks something like:

$ iptables -N bareos
$ iptables -A INPUT -p tcp -m tcp --dport 9103 -j bareos

then you can enforce the limit via

$ iptables -t filter -A bareos -m hashlimit --hashlimit-above 10kb/s --hashlimit-name bareos -j DROP

and remove it via

$ iptables -t filter -F bareos

Of course, you can think of more elaborate filtering, but I simply wanted
to reduce the total bandwidth.

>
> Thanks!
> -Dave

HTH,
Erich

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl9NSX8ACgkQCu7JB1Xa
e1ohRRAApf+maKau1nRErYFDhcF3XyXTCEnSR1dTnnOTEKKWxItviAbTWuWI7Mha
hnyBpQ6KiuWbYPoqeNNJ3nBYfaYlf430fqXWQZKpYs6i+nxTadMNLxul/prhDjii
5izytqdmxHzJGC97XeQ0ARLRyZW+bQ2AIDmh8Zz4iXFjLLAM3/9Tkiyudscar/qn
MlpUbr2L0EDSpH6WTT9++hPWjOgZcuToDl5lg2yQVnTpBR2sVXxsaeZ9kjwXOrfX
PSn00piTHW+CSWVGJNGhNGYOKT7yTqGvIgGPt/+YEfhtPJfeNWweDVuGVfUOPrD+
fi+p1dVF80kdpRPAX0SqYcISwUe3vYZoQVVNhM0LmZR5CD9hFzJUxYhs2W6UNbq6
GPPIVUkIuNKKawqBQA87CT8RtpIOddz9asKZT0a+nHK5LqeEcFzybE1BICcbfsfr
nyEJ3toJO1UJ9J0dXNRD+2Uo8r4aFENpvhkQttHcVIDagt5JzTBwXJNBONsOxiPg
pdsbtU0yXatWp6JnooQqQQMU+DPvBDM/1S/Ak+XJnxcVJAuybqd68G+JyQ8fMjs5
OJjaLeneD/+55GX02sRkokr4zr/lYDVr/0B/x6Dd6l47ebr+KoyVtWJFP47sQNp2
vBP/Tftwj8Nad3bE0xVf/zDfkpunJQEdF/bHRw7wyLgAnZqr0Sw=
=i1Y9
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages