Privatanwender und Unternehmen nutzen gleichermaßen Cloudspeicher zur Ablage von kleinen und großen Datenmengen. Diese sind in der Cloud gut aufgehoben, und auch der Transport dorthin ist verschlüsselt. Wer die eigenen Daten keinem Provider anvertrauen möchte, speichert eben in einer privaten Cloud – auch hybride Setups, die private und öffentliche Cloudstrategien kombinieren, sind inzwischen weit verbreitet.

Was aber ist mit den Speichern selbst: Sind sie der perfekte Ort für Backups? Datenverlust scheint zunächst einmal ausgeschlossen, solange der Cloudzugriff gelingt. Wenn ein Anbieter aber technische Probleme hat oder politische Entscheidungen den Zugang verhindern beziehungsweise ein Provider gleich ganz vom Markt verschwindet, kann ein zusätzliches lokales Backup hier Schlimmeres verhindern.

Apache Libcloud [1] ist eine Python-Bibliothek, die eine einheitliche, Provider-unabhängige API zum Anbinden von Clouddiensten zur Verfügung stellt. Die aktuelle Version unterteilt in die vier Bereiche Cloud Compute (Amazon EC2, Rackspace CloudServers, Openstack), Cloud Storage (Amazon S3, Rackspace CloudFiles), Loadbalancers-as-a-Service (LBaaS) und DNS-as-a-Service (DNSaaS). Das Bareos-Libcloud-Plug-in [2] nutzt die Apache Libcloud und kann Objekte aus S3-Speichern direkt über die S3-Schnittstelle herunterladen und sichern. Dieser Beitrag stellt nach einer kurzen Einführung die Installation des Plug-ins und die dazugehörigen Konfigurationsdateien vor. Danach zeigen wir, wie Sie Daten über S3 sichern.

Da die aktuelle Version des Bareos-Plug-ins das Wiederherstellen der Daten ausschließlich im Dateisystem und noch nicht über die S3-Schnittstelle im Cloudspeicher ermöglicht, zeigen wir, wie nach einem lokalen Restore die Objekte zurück in den S3-Speicher gelangen.

Als Testumgebung kam Ubuntu 18.04 mit Python 3.6.9 zum Einsatz. Bis zum Redaktionsschluss gab es Probleme mit dem Plug-in und einer Python-Umgebung höher als Version 3.7. Sollte der Fehler noch nicht behoben sein, sind Anwender mit Python 3.7 oder früher auf der sicheren Seite. Außer der aktuellen Bareos-Version 20.0.0 [3] installierten wir den aktuellen MinIO-Client [4]. Mit diesem steht im Handumdrehen ein eigener und privater Cloudspeicher zur Verfügung, der einen zu Amazon S3 kompatiblen Object Store bereitstellt. In der MinIO-Cloud hinterlegten wir drei Dateien mit 1, 20 und 100 KByte, um zu zeigen, wie das Plug-in mit unterschiedlich großen Objekten verfährt. Das Kommandozeilentool s3cmd [5] zur Kommunikation mit der Cloud installierten wir aus dem Repository der Distribution.

Bareos (Backup Archiving Recovery Open Sourced) [6] ist eine netzwerkübergreifende Open-Source-Software (AGPLv3), die Daten aller gängigen Betriebssysteme sichern, archivieren und wiederherstellen kann. Die Client-Server-Backupsoftware besteht aus mehreren Komponenten, die über das Netzwerk miteinander kommunizieren: dem Bareos Director, einem oder mehreren Storage Daemons und den File Daemons, die auf den zu sichernden Clients installiert sind. Der Director ist die Steuerzentrale und verwaltet unter anderem die Einstellungen der SQL-Datenbank (Katalog) und die angeschlossenen Clients, die FileSets (beschreiben, welche Dateien Bareos sichern soll), die Konfiguration der Plug-ins, Before- und After-Jobs (Programme, die vor oder nach einem Backupjob laufen sollen), den Storage- und Medien-Pool (Eigenschaften und Vorhaltezeiten), Zeitpläne (Schedules) und die Backupjobs selbst.

Der File Daemon (FD) läuft auf dem jeweiligen Client und führt die Anweisungen des Bareos Directors aus. Dazu gehört auch, die zu sichernden Daten an den Bareos Storage Daemon (SD) zu schicken. Der SD nimmt Daten von einem File Daemon an und speichert sie zusammen mit ihren Attributen auf den konfigurierten Sicherungsmedien. Im Fall einer Restore-Anfrage findet der SD die richtigen Daten und schickt sie an den File Daemon zurück. Generell lassen sich alle Bareos-Dienste (Director, Storage Daemon und File Daemons) über Plug-ins erweitern. Das Bareos-Handbuch beschreibt in einem eigenen Kapitel [7], welche Erweiterungen zur Verfügung stehen und wie Sie diese einrichten.

Bild 2 zeigt, wie die internen Komponenten des Bareos-Libcloud-Plug-ins zusammenarbeiten. Die Erweiterung ist auf einem Bareos-Client, also auf dem File Daemon, installiert. Genau genommen besteht das Plug-in aus zwei Komponenten: einem eingebetteten Python-Interpreter und dem Libcloud-Modul, das die Libcloud-Bibliothek importiert. Der File Daemon startet zuerst den Embedded Interpreter, der dann wiederum den Python-Code aufruft. Der Einfachheit halber reden wir in diesem Beitrag aber weiterhin vom Libcloud-Plug-in.

Das Plug-in startet zunächst den Bucket-Explorer-Prozess, der dann zusätzlich 1 bis n Worker-Prozesse initiiert. Alle Prozesse nutzen die Apache-Libcloud-API, um auf das S3-Backend zuzugreifen – je nach Konfiguration über HTTP oder HTTPS. Die Prozesse kommunizieren über Queues: Q1 ist für die Kommunikation zwischen Bucket Explorer und Worker vorgesehen, Q2 für Objekte kleiner als 10 KByte beziehungsweise Informationen zu temporären Dateien und Streams, die ein Worker zum Sichern an den File Daemon schickt. Eine dritte, in Bild 2 nicht dargestellte Message-Queue ist für Fehlernachrichten vorgesehen.

Das Aufteilen in Bucket Explorer und Worker dient der Kompensation von Download-Latenzen, die bei S3-Schnittstellen üblich sind. Daher haben die Bareos-Entwickler das Plug-in so implementiert, dass es mit mehreren Prozessen arbeitet. Der Bucket Explorer schaut nach, was es zu tun gibt, und die Worker arbeiten das ab. Die Worker können also parallel arbeiten, und sie sind ausschließlich für das Herunterladen aus dem S3-Speicher zuständig.

Dabei gibt es unterschiedliche Download-Methoden, um die größtmögliche I/O-Bandbreite auszunutzen. Bis zu einer definierten Größe (prefetch_size) lädt ein Worker das Objekt herunter und schreibt es direkt in eine temporäre Datei. Alles, was größer als die prefetch_size ist, geht als Auftrag an den File Daemon selbst, der das Objekt per Stream herunterlädt. Das verhindert, dass ein mehrere GByte großes Objekt vom S3-Storage im temporären Dateisystem des Backup-Clients landet.

Bevor es an die Installation und die Einrichtung geht, noch ein Hinweis: Objekte aus dem S3-Speicher entsprechen in der Bareos-Welt Dateien.

Zusätzlich zu den Bareos-Paketen selbst brauchen Sie eine Python-Umgebung; wir empfehlen Python 3, aber wegen der eingangs erwähnten Inkompatibilitäten eine Version kleiner als 3.8. Das Plug-in finden Sie im Paket "bareos-filedaemon-libcloud-python-Plug-in" und die Apache-Libcloud-API heißt je nach Distribution python3-libcloud, python-apache-libcloud oder auch apache-libcloud. Als Erstes möchten wir einen Blick auf die Konfigurationsdatei des Plug-ins "/etc/bareos/libcloud_config.ini" werfen (Listing 1).

Auf dem Testrechner läuft eine lokale MinIO-Instanz, die auf dem Standardport 9000 S3-Anfragen erwartet. Für einen externen Cloudspeicher empfiehlt sich die Anweisung "tls=true". Nach dem Benutzernamen und dem Kennwort wird es im Abschnitt "[misc]" interessant: Hier tragen Sie die Anzahl der Worker ein und definieren die Größe der Queue. Auf dem Testsystem ist diese auf 1000 gesetzt und definiert damit die maximale Anzahl der temporären Objekte, die auf dem Client zwischengespeichert werden dürfen.

Tipp: Wenn Sie einen S3-Speicher mit sehr vielen kleinen Dateien haben, dann setzen Sie eine ausreichend große Queue, damit die Worker dort ständig reinschreiben können. Die Worker warten im Zweifelsfall, bis der Backupprozess die Queue wieder geleert hat, wenn diese voll ist – so verhindern Sie eventuell Wartezeiten. Die prefetch_size haben wir für unseren Test angepasst. Die Anzahl der Nachrichten hinter "job_message_after_each_number_of_objects" haben wir auf 1 heruntergesetzt, um mehr Ausgaben zu produzieren.

Legen Sie ein neues FileSet an; die Datei beschreibt, welche Dateien Bareos sichern soll. Auf dem Testrechner ist das die Datei "/etc/bareos/bareos-dir.d/fileset/plug-inTest.conf" (Listing 2).

Beachten Sie, dass die Optionen hinter der Plug-in-Anweisung zwingend in einer einzigen Zeile stehen müssen. Hier ist unter anderem Folgendes definiert: der Modulpfad (kann auch "/usr/lib64/bareos/ Plug-ins" sein, je nach Distribution), der Name des Moduls und seine Konfigurationsdatei /etc/bareos/libcloud_config.ini". Außerdem ist hier beschrieben, welche Buckets gesichert werden sollen (buckets_include); über buckets_exclude lassen sich optional Buckets ausschließen. Außerdem richten Sie einen neuen Backupjob ein; auf unserem Rechner ist das die Datei "/etc/bareos/bareos-dir.d/backup-bareos-fd.conf":

Abschließend starten Sie alle drei Bareos-Dienste neu:

Bevor Sie einen Zeitplan für den neuen Backupjob unter "/etc/bareos/bareos-dir.d/schedule" einrichten, starten Sie ihn manuell. Rufen Sie dazu das Kommandozeilentool bconsole auf und schauen Sie als Erstes mit dem Befehl status nach, ob alle Bareos-Dienste laufen (status dir, status storage und status client). Sie sollten hier eine Bestätigung sehen, dass der File Daemon das Plug-in korrekt geladen hat.

Als Nächstes können Sie den Job über das Kommando run starten. Die bconsole listet verfügbare Jobs auf; wählen Sie die Nummer für den Job "backup-bareos-fd". Warten Sie ein paar Sekunden und geben Sie dann messages (oder kürzer: m) ein, um die Meldungen zu lesen. In diesen Protokollen finden Sie außer dem Namen des Daemons, der die Meldung erzeugt hat, immer Informationen zum Job, zum Pool, zur Art des Backups, zur Performance et cetera. Abschließend sollten Sie bei einer erfolgreichen Sicherung stets die Meldung "Termination: Backup OK" sehen.

Weiterhin zeigt das Protokoll Ausgaben zum Plug-in "bareos-fd-libcloud" an. Zunächst versucht es, zum S3-Speicher zu verbinden, dann initialisiert es den Bucket Explorer (immer mit der ID 0) und startet die Worker (IDs größer als 0). Auf dem Testsystem hat Bareos drei Dateien gesichert; danach folgen die Meldungen zum Aufräumen. Sämtliche Meldungen landen auch immer in den Logdateien unterhalb von "/var/log/bareos", sodass Sie diese auch zu einem späteren Zeitpunkt betrachten können. Im nächsten Abschnitt erklären wir, wie Sie temporär den Debug-Level in der bconsole erhöhen und noch aussagekräftigere Meldungen in einer Trace-Datei erzeugen.

Das bconsole-Kommando setdebug setzt das Debug-Level: Je höher die Zahl, desto detaillierter die Ausgabe. Zusätzlich können Sie das Tracing aktivieren, um alle Ausgaben des Daemons in einer Trace-Datei abzulegen. Mit solchen ausführlichen Diagnose-Informationen spüren Sie eventuelle Fehler besser auf:

Nachdem Sie den Befehl ausgeführt haben, verrät die bconsole den Namen der Trace-Datei (Listing 3). Auf unserem Testrechner ist das "/var/lib/bareos/bareos-ci-ubuntu-18-fd.trace". Hier finden Sie viele interessante Meldungen des Plug-ins, Informationen zur Verbindung zwischen den Bareos-Diensten, Angaben zur TLS-Verbindung und zum Start des

Backupjobs. Sie können ebenfalls das Sichern der Objekte beobachten.

Die letzten drei Meldungen in Listing 3 zeigen, dass der Bucket Explorer die Dateien "file20k", "file1k" und "file100k" gefunden hat und was damit passiert: "Prefetch object to temp file" bedeutet, dass ein Worker damit beauftragt wurde, die Datei herunterzuladen und im temporären Verzeichnis abzulegen. "Put complete file" zeigt an, dass die Datei "file1k" komplett in die Queue geschoben wurde – am temporären Dateisystem vorbei. Die Datei "file100k" ist nach unserer Konfiguration zu groß, daher wird ein Stream-Objekt an den FD-Prozess geschickt "Prepare object as stream for download" und dieser lädt das Objekt als Stream direkt aus dem S3-Speicher herunter.

Vor dem Wiederherstellen gilt es, in der bconsole mittels list jobs gelaufene Backupjobs anzuzeigen. Auf unserem Testsystem identifizieren wir "Job 17" und tippen zum Wiederherstellen entsprechend restore job-id=17 select all done. In der derzeitigen Plug-in-Version findet ein Restore wie erwähnt im Dateisystem und nicht im S3-Speicher statt. Bareos zeigt in der bconsole an, wohin die Dateien wiederhergestellt werden sollen. Nach Bestätigung durch "Yes" stellt Bareos die Daten im Verzeichnis "/tmp/bareos-restores" wieder her. Dort finden Sie dann einen Ordner mit dem Namen des S3-Buckets. Für Produktivumgebungen sollten Sie stets darauf achten, dass an dieser Stelle genug Platz vorhanden ist. Zum anschließenden Zurückspielen der Dateien in den S3-Speicher können Sie beispielsweise das Kommandozeilentool s3cmd verwenden (Listing 4).

Nachdem Sie den Befehl aus Listing 4 ausgeführt haben, überprüfen Sie, dass alle Objekte im S3-Speicher angekommen sind:

Eine abschließende Bemerkung zum Sichern von Objekten aus einem S3-Speicher: Bareos beachtet keine Metadaten. Die Backupsoftware sieht nur, dass es ein Objekt gibt, auf das sie zugreifen darf, sichert aber keine S3-Attribute. Zugriffsrechte beachtet Bareos selbstverständlich. Im Zweifelsfall kann das Kommandozeilentool s3cmd die Attribute wieder so setzen, wie sie waren (s3cmd modify, s3cmd setacl, s3cmd setpolicy et cetera).

Die Bareos-Entwickler kennzeichnen das neue Libcloud-Plug-in derzeit noch als experimentell. Bei Erscheinen dieses Beitrags dürfte die Inkompatibilität zu Python-Versionen höher als 3.7 behoben sein und auch das Restore direkt in den S3-Speicher steht auf der To-do-Liste. Auch wenn das Bareos-Libcloud-Plug-in bisher lediglich mit S3 zusammenarbeitet – die Apache Libcloud als flexible Grundlage dürfte eine Erweiterung auf andere Speicher-Backends möglich machen.