New features in the Bareos Bacula fork

Better Backups


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.


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.

The Author

Jörg Steffens has been working with Linux since 1995 as a consultant at SUSE Linux AG and since 2004 as the director of an open source consulting company dass IT GmbH in Cologne, Germany. In 2012, he joined forces with other long-term Bacula users to initiate the Bareos project and founded Bareos GmbH & Co KG.

Philipp Storz has focused on Linux since 1998 and on Bacula since 2007. He has worked professionally with Linux since 2001, first as a consultant with SUSE Linux AG and since 2004 as a co-founder of dass IT GmbH in Cologne. His book on Bacula was published by Open Source Press in 2012. Since the founding of the Bareos project and the company of the same name, he has pushed forward with the technical development of Bareos together with Marco van Wieringen.

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=