Hi Rui (@Plural)
For your question, both the bytes_sec and readbytes_sec come from the status client output. As we know, this status client output can work in two modes:
In case raw client status output we display output from the standard status client command:
status client=xxxx
In case json client status output we use Bacula API 2 interface. This API 2 interface consists of two commands:
- first command that turns on the API 2 mode
- second command that uses this API 2 mode
For Bacula status client, they will be the following two Bconsole commands executed one after another:
.api 2 api_opts=o
.status client=xxxxxx running
The main advantage of this API 2 interface is that it returns output in key=value form that is much easier to parse and much less "unexpected" than output in raw format. For example, the API 2 output for status client can be as below:
running:
jobid=51745
job=BSR.2025-09-02_19.08.25_28
vss=0
level=F
type=B
status=R
starttime_epoch=1756832907
starttime=2025-09-02 19:08:27
jobfiles=534
jobbytes=466221
bytes_sec=11100
errors=0
bwlimit=7000
readbytes=466438
readbytes_sec=11105
files_examined=534
processing_file=/mnt/backup/bsr/darkstar-fd-logi-2015-11-24 21:20:02-Backup.bsr
sdreadseqno=8
fd=6
sdtls=1
dirtls=1
directorconnected_epoch=1756832949
directorconnected=2025-09-02 19:09:09
dirtls=1
error=0
errmsg=
We use this API 2 to parse output and build the JSON for Bacularis API component status endpoints.
For LastBytes/sec, this value is available in the raw output format, but it is not available in the json output format. This is the reason why we do not display the last bytes speed in the graphical client status.
I am not sure what exactly is the readbytes_sec value. I guess that this expresses speed with which Bacula File Daemon reads data from the source file system at a moment, but I am not 100% sure. This could require to dive into the Bacula source code to check it.
Best regards,
Marcin Haba (gani)
