Neue Features im Bacula-Fork Bareos

© Maxim Kazmin, 123RF

Besser sichern

,
Die auf fast allen Plattformen verfügbare Open-Source-Backup-Software Bacula ist bei vielen Administratoren beliebt – nun schickt sich der Fork Bareos an, die Vorreiterrolle noch auszubauen.
Der ADMIN 05/13 wirft einen Blick auf die frei verfügbaren Cloud-Frameworks von Eucalyptus über OpenNebula bis OpenStack. Gute Aussichten für skalierbare ... (mehr)

Bevor man sich mit Bacula oder Bareos näher befasst oder eine Testinstallation ins Auge fasst, ist ein Blick auf die Struktur der Anwendung nützlich ( Abbildung 1 ): Der grundsätzliche Aufbau besteht immer aus einer Steuerzentrale, dem Backup Director, ein oder mehreren Storage Daemons und den File Daemons auf den zu sichernden Clients.

Abbildung 1: Struktur einer einfachen Bacula-/Bareos-Installation.

Die File Daemons sind der Teil der Software, der auf möglichst vielen Plattformen laufen muss. Er ist dafür zuständig, die Daten vom Client zu sichern beziehungsweise sie bei einer Rücksicherung auch wieder dorthin zu bringen. Dieser Daemon läuft auf den Clients permanent und führt die Anweisungen des Directors aus.

Der Director ist die Steuereinheit: Er enthält die gesamte Logik und zu ihm gehören die meisten Einstellungen. Seine Konfigurationsdatei beschreibt

  • die Datenbank-Konfiguration,
  • alle Client-Systeme und wie diese anzusprechen sind,
  • welche Dateien gesichert werden sollen (File Sets),
  • die Plugin-Konfigurationen,
  • die Before- und After-Jobs: Programme, die vor oder nach einem Backup-Job gestartet werden sollen, um etwa Dienste zu stoppen und zu starten,
  • den Storage- und den Medien-Pool mit dessen Eigenschaften und Vorhaltezeiten,
  • die Zeitpläne für die Backups,
  • die Adressen für Meldungen,
  • Jobs und JobDefs.

Selbst wenn bereits ein Storage, ein File Set und ein Client definiert sind, passiert erst einmal gar nichts. Zusammengeführt werden diese Komponenten erst über Jobs. Sie definieren, was wann und wohin zu sichern ist.

Wichtig ist auch, wie lange gesicherte Daten aufzuheben sind. Das steuern File Retention, Job Retension und Volume Retention. Es ist sinnvoll, sich nur auf die Volume Retention zur Steuerung der Vorhaltezeiten zu beschränken, denn wenn sich mehrere Retention-Optionen überschneiden, kann es zu überraschenden Effekten kommen.

Die Volume Retention wird pro Pool definiert. Durch die Definition mehrerer Pools kann man auch mit unterschiedlichen Vorhaltezeiten arbeiten, zum Beispiel für verschiedene Systeme oder für unterschiedliche Sicherungsarten wie Voll-, differenzielle oder inkrementelle Sicherung. Die angegebenen Zeiten sind Mindestaufbewahrungsfristen.

Bessere Bedienbarkeit

Ein Schwerpunkt der Bareos-Entwicklung ist es, die Hürden für Anfänger möglichst niedrig zu halten. Weil Neulinge von den gebotenen Konfigurationsmöglichkeiten meist erschlagen werden, bietet das Bareos-Projekt unter [1] Paket-Repositories für die gängigen Linux-Distributionen und Windows an. Für Windows werden sogar zusätzliche Pakete für die Software-Management-Lösung OPSI [2] offeriert. Alle Versionen werden automatisiert durch eine projekteigene Instanz des Open Build Service gebaut. Im Vergleich dazu bietet Bacula.org nur den Quellcode an. Aktuelle Windows-Binaries stehen dort nur gegen Bezahlung zur Verfügung.

Unter Linux reicht es zur Installation eines Bareos-Servers aus, das entsprechende Repository einzubinden und das Paket »bareos« zu installieren. Bareos unterstützt drei Datenbank-Backends: MySQL, PostgreSQL und SQLite. SQLite sollte aber nur für Testinstallationen verwendet werden. Der meiste Optimierungsaufwand soll zukünftig in die PostgreSQL-Anbindung fließen. Um sicherzustellen, dass wirklich das gewünschte Backend installiert wird, sollte man die Pakete »bareos« und »bareos-database-postgresql« (oder eben »bareos-database-mysql« ) auswählen. Die Datenbank selbst muss separat installiert werden, da Bareos nur Abhängigkeiten zu den Datenbank-Clients beinhaltet. Dies ist sinnvoll, weil die Datenbank nicht unbedingt auf dem Bareos-Director-Rechner selbst laufen muss.

Im Gegensatz zu Bacula wird bei Bareos die zu verwendende Datenbank in der Konfigurationsdatei definiert. Bei Bacula war es noch notwendig, eine speziell gegen die jeweilige Datenbank kompilierte Version einzusetzen.

Bei der Erstinstallation wird Bareos die Konfigurationsdateien im Verzeichnis »/etc/bareos« mit sinnvollen Werten belegen. Nach der Installation muss der Admin die Datenbank initialisieren und die Dienste starten ( Listing 1 ).

Listing 1

Dienste starten

 

Bei der automatischen Konfiguration ist die Sicherung auf Festplatte (nach »/var/lib/bareos/storage« ) voreingestellt. Bei der Sicherung auf Festplatte verhält sich Bareos genau so wie bei einer Sicherung auf eine Tape Library. Das bedeutet, dass unterhalb von »/var/lib/bareos/storage« Dateien angelegt werden, die jeweils einem Band entsprechen. Das hat den Vorteil, dass einheitliche Regeln gelten und zum Beispiel Vorhaltezeiten auf Bändern und auf Festplatten gleich gehandhabt werden. Die maximale Größe der Dateien und die maximale Anzahl wird im Director Daemon in der Pool Ressource definiert, das heißt in der Datei »/etc/bareos/bareos-dir.conf« .

Um ein solches virtuelles Band anzulegen, startet man das Programm »bconsole« , das einem mit dem Prompt »*« empfängt. Dort gibt man dann »label« , einen Namen (hier: »file1« ) und danach »2« für den Pool »File« an ( Listing 2 ).

Listing 2

Virtuelles Band labeln

 

Mittels »status director« kann man sich die nächsten geplanten Jobs anzeigen lassen ( Listing 3 ).

Listing 3

Statusanzeige

 

Die Sicherungen sind in der Konfigurationsdatei auf 23:05 Uhr (BackupClient1: Dateisystem) beziehungsweise. 23:10 Uhr (BackupCatalog: Datenbank-Eigensicherung) voreingestellt.

Möchte man eine Testsicherung durchführen, kann man sie mit dem Kommando »run« starten. Dann muss der Admin nur noch angeben, welchen Client er sichern möchte und schon beginnt die Sicherung. Das Ergebnis zeigt dann ein Aufruf des Kommandos »status director« an ( Listing 4 ).

Listing 4

Status Director

 

Mittels »status scheduler« kann man sich anzeigen lassen, wann Jobs geplant sind, mittels »status scheduler days=365« auch für ein ganzes Jahr im Voraus.

Verbesserungen

Außer bei der Installation gibt es eine Reihe weiterer Verbesserungen, die das Leben des Bareos-Administrators einfacher machen: Wer schon einmal mit Baculas Konfigurationsdateien gearbeitet hat, wird sich freuen, dass bei Bareos fast alles mit sinnvollen Default-Werten vorbelegt ist. Bareos kennt nämlich im Gegensatz zu Bacula auch Voreinstellungen für String-Werte. So muss man sich zum Beispiel keine Gedanken mehr um die Angabe von »Pid Directory« und »Working Directory« in der File-Daemon-Konfiguration auf dem Client machen. Bareos setzt sinnvolle Werte für die entsprechende Plattform, wenn es die Pakete erstellt.

Bei Windows-Systemen ist es jetzt möglich, ohne großen Aufwand nicht nur ein einzelnes, sondern alle angebundenen Laufwerke zu sichern (Windows Drive Discovery). Bei Bacula ist dies nur in der kommerziellen Version möglich. Dafür wurde auch der Aufruf des Volume Shadow Copy Service (VSS) intelligenter gestaltet.

Die Handhabung von Tape Libraries wurde vereinfacht. So können Bänder jetzt innerhalb der Bconsole von einem Slot zum anderen bewegt werden. Auch kann ein eventuell vorhandener Import-/Export-Slot bequem mit dem Kommando »import« beziehungsweise »export« angesprochen werden.

Der Tray-Monitor (ein kleines Icon im Systembereich der Taskleiste) läuft auf Windows- und auf Linux-Systemen. Das Blinken des Icons zeigt an, dass auf dem System gerade eine Sicherung stattfindet.

Wenn ein Backup-Job doch mal fehlschlägt, ist es jetzt einfach möglich, einen Job mit genau den gleichen Parametern nochmals zu starten:

*rerun jobid=id

Der Backup-Administrator muss sicherstellen, dass alle relevanten Daten eine gewisse Zeit lang aufgehoben werden. Für steuerrelevante Daten ist eine Aufbewahrungsfrist von 10 Jahren vorgeschrieben, die man sorgfältig planen muss. Will man die Daten nach verschiedenen Eigenschaften trennen, nutzt man in Bareos dafür Pools. Für sie lassen sich unter anderem Größen und Aufbewahrungszeiten definieren.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023