Tuning parameters
EnterpriseBacula Enterprise Only
This solution is only available for Bacula Enterprise. For subscription inquiries, please reach out to sales@baculasystems.com.
These set of parameters are common to all modules and they are advanced ones. They should not be modified in general. They can be used to tune the behavior of the plugin to be more flexible in particular bad network environments or when significant job concurrency is happening, etc.
Option |
Required |
Default |
Values |
Example |
Description |
|---|---|---|---|---|---|
backup_queue_size |
No |
100 |
0-500 |
1 |
Number of maximum enqueued internal operations between service static internal threads (there are 3 communicating through queues with the set size: service fetcher, service opener and general publisher to bacula core). This could potentially affect graph api concurrent requests and consequently, Graph throttling. It is only needed to modify this parameter, in general, if you are going to run different jobs in parallel |
concurrent_threads |
No |
10 |
0-100 |
1 |
Number of maximum concurrent backup threads running in parallel in order to fetch or open data for running download actions. This means every service fetcher and service opener will open this number of child concurrent threads. This will affect graph api concurrent requests. Graph API can throttle requests depending on a variety of circumstances, but this parameter impacts it directly. It is only needed to modify this parameter, in general, if you are going to run different jobs in parallel. If you want to have a precise control of your parallelization through different jobs, please set up this value to 1. Please be careful also with the memory requirements, multi-threaded increases very significantly memory consumption per job |
concurrent_listing_threads |
No |
5 |
0-20 |
1 |
Number of maximum concurrent backup page listing threads running in parallel in order to fetch sets of data for some modules. Currently it’s only used in the email module. This parameter will also affect graph api concurrent requests. Graph API can throttle requests depending on a variety of circumstances, but this parameter impacts it directly. It is only needed to modify this parameter, in general, if you are going to run different jobs in parallel. If you want to have a precise control of your parallelization through different jobs, please set up this value to 1. Please be careful also with the memory requirements, multi-threaded increases very significantly memory consumption per job |
graph_list_page_size |
No |
200 |
1-500 |
350 |
Number of maximum elements got from Graph API for each page of objects. Higher number implies less requests, but more memory and more time for each request |
graph_timeout |
No |
9000 |
Positive integer (milliseconds) |
60000 |
Graph call timeout inside HttpClient |
graph_read_timeout |
No |
300 |
Positive integer (milliseconds) |
30000 |
Graph read timeout inside HttpClient |
graph_retries |
No |
5 |
Positive integer (number of retries) |
10 |
Graph number of retries for retry-candidate requestsInclude some stats information in the joblog. Useful to measure task times |
graph_retry_delay |
No |
5 |
Positive integer (seconds) |
10 |
Graph delay between retries |
general_network_retries |
No |
5 |
Positive integer (number of retries) |
10 |
Number of retries for the general M365 external retry mechanism |
general_network_delay |
No |
50 |
Positive integer (seconds) |
100 |
General M365 Plugin delay between retries |
throttled_wait_time |
No |
300 |
Positive integer (seconds) |
600 |
Extra wait time for throttled situations where the timeout is not provided or not got from MS API. In onenote module this is multiplied by 2. Once MS throttles a request is better to not retry too soon or the changes to continue with rejected requests will increase significantly |
stats |
No |
No |
No, Yes |
Yes |
Include some stats information in the joblog. Useful to measure task times |
spool_free_space_check |
No |
Yes |
No, Yes |
No |
Enable/Disable to check the free space of the underlying filesystem before downloading a file that is going to be spooled in the “path” directory. The behavior is controlled by the next parameters on this table |
spool_free_space_min_bytes |
No |
104857600 |
Positive integer (bytes) |
524288000 |
Controls the minimum space that must reamin free of the underlying filesystem when spool_free_space_check is enabled. This parameters helps to not fill the filesystem when there is high concurrency and big files in the backup process |
spool_free_space_wait_seconds |
No |
20 |
Positive integer (seconds) |
100 |
Seconds to wait between retries on failed spooling operations because of not enough free disk space |
spool_free_space_retries |
No |
100 |
Positive integer (number of retries) |
10 |
If not enough free space is found when spooling, the operation will be retried a number of times controlled by this parameter |
spool_max_file_size_bytes |
No |
0 |
Positive integer (bytes) |
104857600 |
Establish a limit on the maximum filesize that any file implied in the backup process can present. Files with a bigger size will be discarded and not included in the backup |
Note
graph_list_page_size had default value 500 before version 14.0.7. A higher value for this parameter can improve the performance at it reduces the number of API calls done to M365 service. However, the service can also be overloaded and return more HTTP 503 errors (Bad Gateway), especially for the email module.
Starting from version 16.0.3, default values for backup_queue_size and concurrent_threads have been increased, also the allowed ranges.
All spool_* parameters are available since version 18.2.1
See also
Previous articles:
Next articles:
Go back to: Fileset Configuration.