Re: [Bacula-users] Limit Bandwidth of Incremental backups only

[Bill A. <wa...@pr...>]

On 2/27/25 10:53 AM, sc...@ri... wrote:
> Bill Arlofski via Bacula-users wrote on 2/13/25 3:22 PM:
>> Here's an idea. 💡
>> In your Job, configure two RunScripts sections. One before and one after.
>> Have a small script that takes the current jobid and the level.
>> If the level is "limit", set bandwidth to xxxx, if the level is
>> "unlimited", set the bandwidth on the jobid to 0.
> 
> Yee boy now you're thinking!  I had no idea we could run scripts and
> send console commands, this is great.  Sorry for the late reply, I've
> been busy.  My final results and observations:
> 
> I couldn't get the setup running as written, but only minor tweaks were
> needed after some trial and error.  Initially, I was getting results
> such as:
> 
> dir JobId 6203: BeforeJob: setbandwidth
> jobid=client.2025-02-27_06.54.34_12 limit=100
> dir JobId 6203: BeforeJob: Range end is not integer.
> dir JobId 6203: BeforeJob: You have messages.
> dir JobId 6203: BeforeJob: quit
> dir JobId 6203: Start Backup JobId 6203, Job=client.2025-02-27_06.54.34_12
> 
> I realized the value being used for jobid
> (client.2025-02-27_06.54.34_12) was actually the "unique job ID" and
> belonged with the ujobid parameter instead.  %i sends the jobID so I
> adjusted the RunScript to do that instead, but that yielded:
> 
> dir JobId 6204: BeforeJob: setbandwidth jobid=6204 limit=100
> dir JobId 6204: BeforeJob: Connecting to Client client-fd at client:9102
> dir JobId 0: Fatal error: Bad response to Bandwidth command: wanted 2000
> OK Bandwidth
> , got 2901 Job client.2025-02-27_06.56.56_15 not found.
> dir JobId 6204: BeforeJob: Failed to set bandwidth limit to Client.
> dir JobId 6204: BeforeJob: You have messages.
> dir JobId 6204: BeforeJob: quit
> 
> I tried going back to %j with ujobid but got the same error.  I realized
> it's trying to set the bandwidth on the job before the client even knows
> about it.  After reading more about setbandwidth, I saw it could be used
> for "Running and future Jobs for a Client".  I adjusted the setup so it
> sets the bandwidth on the whole client instead, and now this is the result:
> 
> dir JobId 6208: BeforeJob: setbandwidth limit=100k/s client=client-fd
> dir JobId 6208: BeforeJob: Connecting to Client client-fd at client:9102
> dir JobId 6208: BeforeJob: 2000 OK Limiting bandwidth to 102.4 KB/s on
> running and future jobs
> dir JobId 6208: BeforeJob: You have messages.
> dir JobId 6208: BeforeJob: quit
> 
> and here's my current config for it all:
> 
> bandwidth_control script:
> 
> bandwidth=100k/s
> bcbin=/usr/sbin/bconsole
> bccfg=/etc/bacula/bconsole.conf
> if [ $2 = "Incremental" ]; then
>    echo "Job level: $2. Limiting bandwidth to ${bandwidth}."
>    echo -e "setbandwidth limit=${bandwidth} client=${1}\nquit\n" |
> ${bcbin} -c ${bccfg}
> else
>    echo "Job level: $2. Setting bandwidth to unlimited."
>    echo -e "setbandwidth limit=0 client=${1}\nquit\n" | ${bcbin} -c ${bccfg}
> fi
> 
> and:
> 
>    RunScript {
>      RunsWhen = before
>      RunsOnClient = no
>      FailJobOnError = no
>      Command = "/etc/bacula/scripts/bandwidth_control %c %l"
>    }
> 
> I'm not sure what you had another RunScript for "after" for, so left
> that out for now since the bandwidth_control script will set the
> bandwidth to unlimited for all non-Incremental jobs, what were your
> thoughts for including it?
> 
> So far so good, though!
> 
> *status client=client-fd
> Connecting to Client client-fd at client:9102
> 
> client-fd Version: old
> Daemon started...
> ...
> ... bwlimit=100kB/s
> 
> Running Jobs:
> JobId 6208 Job client.2025-02-27_07.20.48_27 is running.
>      Incremental Backup Job started: ...
>      ...
>      Bwlimit=102,400 ...
>      ...
> 
> Great!
> 
> I noticed, though, in the beginning when the Accurate info is exchanged,
> that isn't limited by this mechanism, since I was watching the net
> meters on the client.  That was incoming data from the director it
> appeared (or storage).  Can that traffic be limited at all?  Once that
> was done several mins later, though, the client started uploading to the
> director, or storage technically i guess, steady at 100 k/s.  Thanks!
> 
> Best Regards
> 


-- 
Bill Arlofski
wa...@pr...