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

01 su postgres -c /usr/lib/bareos/scripts/create_bareos_database
02 su postgres -c /usr/lib/bareos/scripts/make_bareos_tables
03 su postgres -c /usr/lib/bareos/scripts/grant_bareos_privileges
04
05 service bareos-dir start
06 service bareos-sd start
07 service bareos-fd start

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

01 *label
02 Automatically selected Storage: File
03 Enter new Volume name: file1
04 Defined Pools:
05  1: Default
06  2: File
07  3: Scratch
08 Select the Pool (1-3): 2
09 Connecting to Storage daemon File at bareos:9103 ...
10 Sending label command for Volume "file1" Slot 0 ...
11 3000 OK label. VolBytes=186 Volume="file1" Device="FileStorage" (/var/lib/bareos/storage)
12 Catalog record for Volume "file1", Slot 0 successfully created.
13 Requesting to mount FileStorage ...
14 3001 OK mount requested. Device="FileStorage" (/var/lib/bareos/storage)
15 *

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

Listing 3

Statusanzeige

01 *status director
02 Scheduled Jobs:
03 Level  Type Pri Scheduled  Name  Volume
04 =====================================================
05 Incremental     Backup 10 18-Jul-13 23:05 BackupClient1 file1
06 Full            Backup 11 18-Jul-13 23:10 BackupCatalog file1
07 ...

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

01 *status director
02 ...
03 Terminated Jobs:
04  JobId Level Files Bytes Status Finished Name
05 =====================================================
06  1 Full 135 6.679 M OK 18-Jul-13 16:00 BackupClient1
07  2 Incr  0  0       OK 18-Jul-13 16:01 BackupClient1
08
09 ...

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

Artikel der Woche

Skalierbares Monitoring mit Prometheus

Klassischen Monitoring-Lösungen geht die Puste aus, wenn sie mit den Anforderungen moderner, skalierbarer Setups konfrontiert sind. Prometheus tritt an, in solchen Umgebungen Monitoring, Alerting und Trending zu verwirklichen. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Linux-Backup

Welche Backup-Lösung setzen Sie für Linux im professionellen Umfeld ein?

  • keine
  • eigene Scripts
  • rsnapshot
  • rdiff-backup
  • Bacula
  • Bareos
  • Borg
  • Duplicity
  • Amanda
  • Burp
  • Clonezilla
  • Acronis
  • Arkeia
  • SEP sesam
  • Veeam
  • Redo Backup
  • Relax-and-Recover
  • andere kommerzielle Software
  • andere Open-Source-Software

Google+

Ausgabe /2017

Microsite