Upgrading from CentOS 7 with Bacula Enterprise or Bacula Community

You will upgrade your CentOS 7 operating system, hosting any Bacula Enterprise version. It is key to prepare this process very well.

Operating System Choice

• If you don’t run any Bacula Enterprise plugins, please choose any new platform for your choice. We support Alma Linux, Rocky Linux or Oracle Linux as well as RHEL.
• If you are using any Bacula Enterprise plugins, please check the documentation or open a new ticket to know if there are any restrictions or limitations on the OS(es) supported.
• If you run the vSphere plugin, RHEL 8 and 9, Oracle Linux 8, and SLES 12.5 & 15.1 are supported from Bacula Enterprise 16.0 and up.

Upgrade Procedure

Installation/Upgrade instructions are below. It is preferred to start the migration process with two servers that share the same Bacula version. The procedure is similar to a disaster recovery procedure. You may use the documentation below as a reference for some steps: https://docs.baculasystems.com/BaculaInfrastructureRecovery/DisasterRecovery/index.html or for Bacula Community users: https://www.bacula.org/15.0.x-manuals/en/main/Disaster_Recovery_Using_Bac.html

Bacula Configuration File Backup

First, you will want to tar your /opt/bacula/etc and /opt/bacula/working directories to get all of your current configurations. Please look at the job/jobdefs parameter “WriteBootstrap” to see where the bootstrap files are stored and add this folder, if applicable, as well. If using bweb with Bacula Enterprise, /opt/bweb/etc must be included too.

Bacula Catalog Dump

Next, you will want to make sure you have a good ASCII dump of your Bacula catalog database. You can get a current copy by looking at your Catalog backup job, and just manually running the script in the RunScript {RunsWhen = Before} section as the bacula user like:

====8<—-

# sudo -u bacula /opt/bacula/scripts/make_catalog_backup.pl <YourCatalogName>

====8<—-

This will create a /opt/bacula/working/bacula.sql file to be imported into the new system.

Remember to copy any of the configs/customizations you may have done to the PostgreSQL server’s postgresql.conf file (max_connections, timezone, etc), pg_ident.conf and pg_hba.conf files (auth and permissions mappings mainly for BWeb).

NOTE 1: The PostgreSQL database server versions will be very different from CentOS 7 to the new O.S. The ASCII dump file that the above script generates should be compatible to be imported into the PostgreSQL server version on the new O.S. You may want to try a dry run of the import process on a VM or some other sandbox to make sure all will go well on the new production system. The PostgreSQL people will have some detailed information about this type of migration process, so we suggest starting there to make sure the database export and import process is as smooth and simple as possible.

NOTE 2: If the upgrade comprises wiping the server disks and then installing a fresh O.S. on the same server, please try to limit the wiping to the O.S.-related partitions, so that the bacula disk volumes are preserved. Ideally the volumes should be copied elsewhere along with the tar file, the database dump and some other PostgreSQL files, just in case, but if it is not possible, at least consider the feasibility of also storing the tar file and the database dump created in the previous steps elsewhere. In order to speed up recovery also copy them into a subfolder of the tree you know it is to be preserved through the upgrade. In order to minimize file reconfiguration, try to keep the same mount points for the disk volumes.

Bacula Enterprise Installation on the New Server

To perform the Bacula Enterprise installation on the new server, if it has Internet access, we recommend using our Bacula Installation Manager (BIM) script:

https://docs.baculasystems.com/BaculaEnterpriseInstallation/BEInstallationOnLinux/LinuxBEInstallationWithBIM/index.html

The Bacula Community installation instructions can be found here: https://www.bacula.org/15.0.x-manuals/en/main/Installing_Bacula.html

Once the Bacula packages are installed on the new system, and before starting the Director (if it is started automatically, just stop it), you will want to drop the Bacula database and import your old one.

At this point, the most important aspect to address is how to make the volumes available on the new server. It depends on what kind of volumes are used. The rsync command may be used to copy the storage over to the new server, or the old server may be ranked down to a storage daemon. If the O.S. was wiped and the new one was installed, mounting the partition where the volumes are and ensuring it persists through boots is very important. If you use NFS, you will need to mount the share into your new system. If appropriate, please dismount it for the previous server running CentOS 7, it is critical that only one Bacula SD instance has access to your volumes.

Once this is done, and the configs have been copied back (and all permissions adjusted because the uid for user bacula and the gid for bacula, disk and tape groups may be different), if using tape devices, please check if their device entries changed and adjust accordingly. Now it should be OK to start the Director and try connecting in bconsole and BWeb.

Restart the PostgreSQL server service (and Director) after any changes.

As a final test, please run some restores of critical servers.