Ein Backup-Client sollte sich möglichst effizient auf Client-Systeme verteilen lassen und dort pflegeleicht laufen. Dies gilt insbesondere, wenn viele verschiedene Plattformen angeschlossen sind. Deshalb arbeitet Bareos auch mit alten Client-Versionen zusammen und unterstützt Bacula-File-Daemons ab Version 2.0 (aus dem Jahr 2007).
Für Univention-Corporate-Umgebungen gibt es eine Bareos-Version für das Univention App Center. Dort kann man über die UCS-Oberfläche für jeden Rechner angeben, ob er gesichert werden soll. Die Bareos-Server-Konfiguration wird daraus automatisch erstellt, die Client-Konfiguration vorbereitet.
Bareos stellt auch direkt Pakete für die Open-Source-Windows-Software-Managementlösung OPSI zur Verfügung. Sie können auf dem OPSI-Server installiert, mit den passenden Voreinstellungen belegt und dann auf alle angeschlossenen Windows-Systeme verteilt werden. Ein Skript erstellt dann mit Hilfe der OPSI-JSON-RPC-Schnittstelle die passende Bareos-Director-Konfiguration.
Für Windows bietet Bareos einen nativen Installer, der die Grundkonfiguration der Software durchführt, Passwörter setzt und sogar die Windows-Firewall öffnet. File Daemon und Tray-Monitor werden so konfiguriert, dass sie sofort zusammenarbeiten.
Ein sehr gut funktionierendes System für das Desaster Recovery von Linux-Maschinen stellt das Projekt Relax And Recover (REAR) [3] bereit. Der Ansatz dieses Projektes ist zweigeteilt. Installiert auf dem zu sichernden System, erzeugt der Aufruf
sudo /usr/sbin/rear -v mkrescue
eine Rettungssystem-ISO-Datei von etwa 60 MByte Größe, inklusive des laufenden Kernels, der benötigten Treibermodule, der Informationen zur Festplattenanbindung und der Netzwerkkonfiguration.
In einem zweiten Schritt kann das Komplettsystem mittels
sudo /usr/sbin/rear -v mkbackup
gesichert werden, etwa auf ein freigegebenes NFS-Verzeichnis.
Auf diesen zweiten Schritt kann man bei einer Sicherung mit Bareos verzichten. Stattdessen wird in das Rescue-System ein Bareos-Recovery-Modul integriert, sodass man nach dem Booten des Recovery-Systems die Option präsentiert bekommt, das System komplett zu löschen und durch das Backup zu ersetzen. Das entsprechende Bareos-Modul befindet sich gerade in der Testphase.
Die gesamte Entwicklung von Bareos findet offen auf Github [4] statt. Die Kommunikation erfolgt über Mailing-Listen. Feature Requests und Bugs können im Bug-Tracking-System [5] eingetragen werden. Details gibt es hierzu unter [6] .
Für die automatisierte Qualitätssicherung werden drei unterschiedliche Systeme eingesetzt:
Jeder in Github durchgeführte Commit stößt automatisch einen Build-Prozess auf https://travis-ci.org/bareos/bareos an. Dort wird der Quellcode kompiliert, die Daemons gestartet, eine Sicherung und Rücksicherung durchgeführt. Damit wird für jeden Commit geprüft, ob Bareos danach noch grundsätzlich funktionstüchtig ist.
Weitergehende Tests werden auf einem auf CDASH basierenden Regression-Test-system unter [8] durchgeführt. Gegenwärtig existieren etwa 130 unterschiedliche Tests, die jeweils bestimmte Funktionen in Bareos überprüfen.
Der Entwicklungs-Workflow bei Bareos sieht vor, dass ein Ticket erst geschlossen werden soll, wenn für eine neue Eigenschaft auch ein Regression-Test erstellt wurde. Das wird dann im Ticket vermerkt.
Ein neues Release wird erst erstellt, wenn die für Bareos mittels eines Open-Build-Servers gebauten Pakete zusätzlich einen auf Jenkins basierenden Test erfolgreich durchlaufen haben. Bei diesem Test werden die Pakete für die verschiedenen Plattformen auf entsprechenden virtuellen Maschinen getestet. Auf jeder Plattform werden automatisiert die Paketinstallation sowie Datensicherung und Rücksicherung überprüft.
Auch die Windows-Pakete werden mithilfe des OBS und Cross-Kompilierung erstellt. Als Ergebnis entstehen dann auch die Windows-Installer und die OPSI-Pakete.