Actions to Avoid

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

Naming 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.

The best way to avoid problems in this respect is to start with a well designed and strictly adhered to naming scheme.

Read this article about resource naming.

Permissions for Starting Bacula Daemons

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 bootstrap files. If they cannot be accessed/created/removed, it will create unexpected behavior.

Be sure to start your Director or Storage Daemon with user and group bacula.

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

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

Note

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

Modifying Scripts from 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, modified scripts may be overwritten with default files from the package maintainer and your changes would be lost.

Media Types for Different Storage Locations

You need to use unique Media Types for different Storage Daemons (SDs) and storage locations (Archive Device file paths) on the same SD. 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 be shared with the Media Type for non-deduplicating volumes.

For further reading, see Disk Backup Design (especially the conclusions at the end).

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 in the Storage Device definition 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 avoid renaming “Media Type” values in the Storage definition and use either the Storage or the Storage Group directives in your pool resources, so Bacula is aware of the Storage to be used for all the media types in the Pool resource.

Note

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 a 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.

Block Size of Tape Devices

You must test your tape device with btape before you go into production (See section Performing a Writing/Reading Device Check). 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 incompatible 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
  ...
}

Using Tape Libraries with a Barcode Reader

If you are using a Tape Autochangers with barcode reader please see Labelling tapes.

Handle Multiple Catalogs

Multiple Catalogs can be configured with Bacula Enterprise, however we strongly recommend not to do so, nor do we support it.

Maintaining a Valid Bootstrap File

By using a WriteBootstrap record in each of your Director’s Job resources, you can constantly maintain a file that will enable you to recover the state of your system as of the last backup without having the Bacula catalog. This permits you to more easily recover from a disaster that destroys your Bacula catalog.

When a Job resource has a WriteBootstrap record, Bacula will maintain the designated file (normally on another system but mounted by NFS) with up to date information necessary to restore your system. For example, in my Director’s configuration file, I have the following record:

Write Bootstrap = "/mnt/deuter/files/backup/client-name.bsr"

where I replace client-name by the actual name of the client that is being backed up. Thus, Bacula automatically maintains one file for each of my clients. The necessary bootstrap information is appended to this file during each Incremental backup, and the file is totally rewritten during each Full backup.

If you are starting off in the middle of a cycle (i.e. with Incremental backups) rather than at the beginning (with a Full backup), the bootstrap file will not be immediately valid as it must always have the information from a Full backup as the first record. If you wish to synchronize your bootstrap file immediately, you can do so by running a restore command for the client and selecting a full restore, but when the restore command asks for confirmation to run the restore Job, you simply reply no, then copy the bootstrap file that was written to the location specified on the Write Bootstrap record. The restore bootstrap file can be found in restore.bsr in the working directory that you defined. In the example given below for the client rufus, my input is shown in bold. Note, the JobId output has been partially truncated to fit on the page here:

(in the Console program)
*restore
First you select one or more JobIds that contain files
to be restored. You will then be presented several methods
of specifying the JobIds. Then you will be allowed to
select which files from those JobIds are to be restored.
To select the JobIds, you have the following choices:
     1: List last 20 Jobs run
     2: List Jobs where a given File is saved
     3: Enter list of JobIds to select
     4: Enter SQL list command
     5: Select the most recent backup for a client
     6: Cancel
Select item: (1-6): 5
The defined Client resources are:
     1: Minimatou
     2: Rufus
     3: Timmy
Select Client (File daemon) resource (1-3): 2
The defined FileSet resources are:
     1: Other Files
Item 1 selected automatically.
 +-------+------+-------+---------+---------+------+-------+------------+
 | JobId | Levl | Files | StrtTim | VolName | File | SesId | VolSesTime |
 +-------+------+-------+---------+---------+------+-------+------------+
 | 2     | F    | 84    | ...     | test1   | 0    | 1     | 1035645259 |
 +-------+------+-------+---------+---------+------+-------+------------+
 You have selected the following JobId: 2
 Building directory tree for JobId 2 ...
 The defined Storage resources are:
      1: File
 Item 1 selected automatically.
 You are now entering file selection mode where you add and
 remove files to be restored. All files are initially added.
 Enter "done" to leave this mode.
 cwd is: /
 $ done
 84 files selected to restore.
 Run Restore job
 JobName: kernsrestore
 Bootstrap: /home/user1/bacula/working/restore.bsr
 Where: /tmp/bacula-restores
 FileSet: Other Files
 Client: Rufus
 Storage: File
 JobId: *None*
 OK to run? (yes/mod/no): no
 quit
 (in a shell window)
 cp ../working/restore.bsr /mnt/deuter/files/backup/rufus.bsr

Go back to the Best Practices chapter.

Go back to the main Bacula Enterprise Configuration page.