Integration

It must be possible to distribute a backup client as efficiently as possible to the client systems and to run it there with as little maintenance is possible, especially if many different platforms are connected. Thus, Bareos also works with old client versions and supports Bacula File daemon versions from 2.0 (from 2007).

Univention Corporate environments also have a Bareos version for the Univention App Center. Through the UCS interface, you can specify whether or not to back up a computer. The Bareos server configuration is automatically generated from this and then prepares the client configuration.

Bareos also directly provides packages for the open source Windows software management solution OPSI. These packages can be installed on the OPSI server, assigned the appropriate settings, and then distributed to all connected Windows systems. A script then uses the OPSI JSON-RPC interface to create the appropriate Bareos Director configuration.

To complete the basic configuration of the software, Bareos offers a native installer for Windows that sets passwords and even opens the Windows Firewall. The File daemon and tray monitor are configured so that they work immediately.

A very good system for disaster recovery of Linux machines is available from the Relax-and-Recover (REAR) [6] project. This project's approach is twofold. Installed on the system to be backed up, the command

sudo /usr/sbin/rear -v mkrescue

creates a rescue system ISO file of about 60MB, including the active kernel, required driver modules, information on the hard disk setup, and network configuration. In the second step, the complete system is backed up using

sudo /usr/sbin/rear -v mkbackup

(e.g., to a shared NFS directory).

You could do without this second step if you use Bareos for your backups. Instead, a Bareos recovery module is built into the Rescue System so that, after booting the recovery system, you see an option for completely deleting the system and replacing it with the backup.

Quality Assurance

The entire development of Bareos occurs openly on GitHub [7]. Communication is handled via mailing lists. Feature requests and bugs can be posted on the bug tracking system [8]. You can find more information at the Bareos Community page [9].

Three different systems are used for automated quality assurance:

• Build tests based on Travis [10]
• Regression tests based on CDASH
• Tests of the various platforms based on Jenkins and virtual machines

Every commit in GitHub automatically triggers a build process on the Travis CI Bareos repository [11]. The respository is where the source code is compiled, the daemons are started, and a backup and restore is performed, and it basically checks after each commit whether Bareos is still functional. Further tests are carried out on a CDASH regression-based test system [12]. Currently, about 130 different tests check specific Bareos functions.

The development workflow in Bareos envisages that a ticket should not be closed until a regression test has been created for a new property. This is then noted on the ticket.

A new release is only created when packages built for Bareos on an Open Build Server have also successfully passed a test based on Jenkins. In this test, the packages for the various platforms are tested on the corresponding virtual machines. On each platform, the package installation, data backup, and restore are checked automatically.

The Windows packages are built using OBS and cross-compilation. The result is the Windows Installer, and the OPSI packages.

Future

The path taken thus far has earned the Bareos project much encouragement. The decision to build the infrastructure for largely automated packet generation and testing at the start of the project has proven successful. More platforms can now be added with little effort, with the certainty that problems are detected very quickly by continuous testing.

Another positive aspect is that Bareos is developed in a fully open environment. Although Bareos GmbH & Co KG offer commercial subscriptions and support, all additions and new features are developed in an open GitHub project.

The roadmap envisions keeping to the present course for future developments to provide easy access and improved usability for administrators, integration with other projects and distributions, and functional enhancements. Plans to improve the default configuration should make it even easier to get started, and whitepapers will better illuminate certain issues.

A subproject is working hard on developing a configuration API to ensure that certain configuration changes can be carried out at run time without problems (e.g., adding clients). Front ends like Webacula [13] will then be able to expand their functionality easily.