This chapter covers a few common mistakes that we have seen users making in our many years of experience in Customer Support. Please read everything carefully and adapt your own Bacula usage according to your environment. It will save you a lot of trouble down the road.


1. Naming of Bacula Resources

Do not rename resources after you have started production or tests. Renaming will cause side effects, and you will incur a lot of manual Catalog maintenance. This is because renamed resources will get new IDs in the database, new jobs will use those new IDs and will mix them up with older and previous used IDs for Volumes, Storage, Pools, Media Type, etc. To correct this you will need to adapt and replace the IDs inside the Catalog to prevent a mismatch.
For instance: if you change characters in names from lower to upper case while keeping the same resource names, the resource selection can become unpredictable and older resources (with the previous ID) might be used instead. So please carefully name and make modifications to resources.

2. Copy/Migration/VirtualFull jobs

Plugins are not compatible with Copy/Migration/VirtualFull jobs by default. Side effects or errors can occur if you use plugins with these special job types. If you make use of Copy Jobs, Migration Jobs, or have Virtual Fulls in addition to the classical backup levels (Full, Diff, Incr), please read carefully the plugin white paper regarding the possibility to use the plugin in combination with Copy/Migration and VirtualFulls.

3. Starting Bacula Daemons with correct permissions

When you start daemon processes with incorrect permissions the output files that are created will have the wrong permissions. Side effects include files that cannot be accessed any more the next time you start up the daemons. The same is true for the PID files that are used by the processes, Catalog dumps, log files, or BSR files. If they cannot be accessed/created/removed, it will create unexpected behavior.
Please be sure to start your Director or Storage Daemon with user and group “bacula”.

Best practice is to use the provided services scripts to start and stop Bacula Daemons:

/opt/bacula/bin/bacula-dir -t -u bacula -g bacula service bacula-dir start
systemctl start bacula-dir # on systems that use systemd

Note: it is recommended to always test the configuration syntax with the -t parameter prior to launch a daemon.

4. Modifying scripts provided with Bacula installation packages

You are free to adapt your settings for your Bacula installation and improve scripts. You should copy existing scripts or configuration parts and choose a different name. When you update your Bacula installation packages, your modified scripts may be overwritten with default files from the package maintainer and your changes may get lost.

5. Media Types for different storage locations

You need to use unique Media Types for different Storage Daemons (SDs) or storage locations (archive device file path). Please use a distinct “Archive Device” that will not be used by any other device. Exceptions are AutoChanger devices that will point to the same Archive Device. In
particular for Global Endpoint Deduplication (GED) the Media Type of volumes should never coincide with the Media Type for non-dedup volumes.
For Further reading see the whitepaper: DiskBackupDesign.pdf (especially the conclusions at the end).

6. Using Media Types in Pools

The Storage Device will be identified internally via the “Media Type” when a job is processed. The Media Type needs to match, so renaming it will mix up newly created volumes with volumes that were created with the old settings. Strong side effects will show up, as you will not be able to recycle, prune, truncate older volumes any more. A storage device might refuse to work or a backup job will request new or different volumes. Best practice is to use the Storage directive in your pool resources, so there will be only one storage (and Media Type) that can be selected.
Never rename a Media-Type for a storage device after you have already created and labeled volumes in a pool. Alternatively create a new Pool and use storage with a new Media-Type. Add new volumes and reconfigure your jobs to use the new Pool instead. After volume retention time has passed for the old pool, those volumes can be removed, step by step. Finally remove the old pool, when no volumes remain inside.

7. Block size of tape devices

You must test your tape device with btape before you go into production (See section 5.3.3 on page 20). The “Minimum Block Size” should almost never be used. It will just waste tape space.
However, to avoid Kernel problems handling the massive request for memory, a “Maximum Block Size” of 512 KiB is the maximum we advise to use.
Do not change those settings afterwards, otherwise your media will become incom- patible and you will encounter many read- and write-errors.
Example for 512k:

Device {
Name = ParisTapeLibrary1-LTO6-Drive01
MaximumBlockSize = 524288 # 512k to be tested with 64,128,256k before


8. Using Tape Libraries with a barcode reader

If you are using a Tape Autochangers with barcode reader please see 6.2.1

9. Handle multiple catalogs

Multiple Catalogs can be configured with Bacula Enterprise Edition, however we strongly recommend
not to do so, nor do we support it. It may be a good idea to set it while migrating your Director
to a new server.

Previous section Next section