© kubais / 123RF.com

Ein Universitätsverbund suchte eine neue Backup-Lösung. Sie sollte in einer großen Umgebung funktionieren, mit vorhandener Hardware zurechtkommen und offene Schnittstellen bieten. Die Wahl fiel auf Bacula.

Verteilt sich eine Last auf viele Schultern, ist sie für den Einzelnen leichter zu tragen. Das sagte sich das Kommunikations- und Informationszentrum der Universität Ulm (KIZ [1]) und initiierte einen Backup-Verbund mit den Universitäten Konstanz und Tübingen. Später kamen noch die Hochschulen Albstadt-Sigmaringen, Rottenburg und Reutlingen sowie das Bibliotheksservicezentrum Baden-Württemberg dazu. Anfangs ging es vor allem darum, gemeinsam Hard- und Software zu beschaffen sowie Erfahrungen auszutauschen. Mit der Zeit entwickelte sich der Verbund jedoch immer mehr in Richtung eines gemeinsamen Betriebs. Das bot sich schon deswegen an, weil der Ausbau des Landeshochschulnetzes BelWü [2], das Hochschulstandorte mit Bandbreiten von bis zu 100 Gbit/s verbindet, die Voraussetzung dafür schuf, Hardware und Betrieb in wenigen Standorten zu konzentrieren.

Als Backup-Software war ursprünglich IBMs Tivoli Storage Manager [3] im Einsatz. Bei einer Überprüfung stellte sich jedoch heraus, dass die Lizenzkosten dafür schwer zu kalkulieren waren: Es gab keine zentrale Übersicht, wie viele CPUs mit welchem Datenvolumen in den einzelnen dezentralen Systemen in den Außenstellen ins Backup einbezogen wurden. Außerdem konnte sich das jederzeit ändern. Die Hardwaredaten zu erfassen und ständig auf den neuesten Stand zu bringen, erschien sehr personal- und zeitintensiv. Deshalb passten die angebotenen Lizenzmodelle nach Volumen oder Prozessorleistung schlecht zum universitären Betrieb.

Eine Ablösung musste her, die Anforderungen dafür waren jedoch sehr hoch. Die neue Backup-Lösung sollte ja nicht nur mit einem einfachen und planbaren Lizenzmodell aufwarten. Sie musste überdies mit Milliarden Dateien und Petabytes an Daten in allen möglichen internationalen Zeichensätzen auf Tausenden Rechnern mit allen möglichen Betriebssystemen an mehreren Standorten im Land zurechtkommen. Um dauerhaften, mindestens lesenden Zugriff auf die Daten zu gewährleisten, waren offengelegte und dokumentierte Formate und Schnittstellen unabdingbar. Außerdem sollte es möglich sein, die vorhandenen Bandlaufwerke inklusive einer größeren Tape-Library weiterzuverwenden.

Am Ende entschieden die Verantwortlichen sich für einen Proof of Concept auf Basis der Bacula Enterprise Edition [4] der Schweizer Firma Bacula Systems [5] – und damit für eine Kombination aus Open-Source-Software mit Erweiterungsmodulen und kommerziellem Support.

Ausgangspunkt

Die aktuelle Hardware besteht aus zwei x86-Servern unter Solaris 11.4, die Zugriff auf drei JBODs haben. Jedes Array umfasst 90 über mehrere Controller angebundene SAS2-Platten mit je 12 TByte Kapazität. Für die notwendige Redundanz sorgt ZFS als Filesystem. Jedes JBOD beherbergt einen Zpool, der für je eine der beteiligten Universitäten als Disk-Cache dient.

Eine Tape-Library mit mehr als 2000 Stellplätzen und acht Tape Drives des Typs IBM 3592-60 [6] ergänzt das Speichersystem. Jedes Laufwerk kann ein Band mit bis zu 20 TByte unkomprimierten Daten beschreiben. Die Anbindung von Hosts an die Bandlaufwerke erfolgt über zwei redundante Fibre-Channel-Pfade mit 32 GBit/s. Ein weiterer Storage Server dient am Standort Tübingen für ausgewählte Systeme als lokales Backup-to-Disk-Medium, ohne Anbindung an die Ulmer Bandlaufwerke. Allerdings wäre bei Bedarf eine Kopplung auf logischer Ebene durch Bacula einfach zu realisieren.

Bacula-Architektur

Das Bacula-System besteht unter anderem aus einem sogenannten Director, dem die komplette Steuerung aller Abläufe obliegt. Er steuert die Tape-Library, initiiert Backups von Clients und erledigt Datenmigrationen von Disk auf Tapes sowie Datenwiederherstellungen.

Um diese Aufgabe erfüllen zu können, muss der Director stets wissen, welche Dateien welcher Clients in welcher Version gespeichert wurden und wo im Disk-Cache beziehungsweise auf welchem Tape an welcher Stelle sie lagern. Diese Information speichert eine PostgreSQL-Datenbank, die zurzeit eine Größe von 1,4 TByte erreicht und aus Gründen der Performance NVMe-Devices benutzt. Die Erfahrung hat gezeigt, dass zudem der DB-Server ausreichend RAM vorhalten sollte, im konkreten Fall sind es 512 GByte.

Nahezu alle Abläufe innerhalb des Bacula-Systems (Abbildung 1) bestimmen der Director und seine Konfiguration. Ausgenommen davon bleibt lediglich das Verschlüsseln der Sicherungen – das übernehmen die Clients selbst. Alle Bacula-Komponenten lassen sich durch einfache Textdateien konfigurieren, die sämtliche Informationen über Objekte und Parameter enthalten. Die erste Kategorie von Objekten sind die Client-Systeme, für die es Adressen, Backup-Jobs und Filesets zu definieren gilt. Dabei ist es sinnvoll, die Systeme nach ihrer Größe einzuteilen und abhängig davon verschiedene Backup-Strategien zu verfolgen.

Abbildung 1: Die Bacula-Installation des Ulmer Backup-Verbunds in der Übersicht. Quelle: Harald Däubler / Universität Ulm

Auf einigen Systemen verbietet eine zu hohe Dateianzahl oder ein zu großes Datenvolumen ein herkömmliches Backup. Die initiale Sicherung eines Mail-Systems mit mehr als 100 Millionen Dateien würde sich parallel zum laufenden Betrieb über mehr als drei Wochen hinziehen. Vor allem aber fiele für eine Wiederherstellung im Ernstfall ein ähnlicher Zeitbedarf an, sie würde mindestens aber mehrere Tage dauern. Daher erzwingen solche Clients alternative Strategien.

Die nächste Kategorie von Clients bilden Systeme, die so groß oder langsam sind, dass ein Voll-Backup mehrere Tage dauern würde, auf denen ein inkrementelles Backup aber in einer Nacht durchläuft. Aufgrund von Erfahrungswerten wurden die Grenzen dieser Kategorie in der Ulmer Installation wie folgt festgelegt: Die Größe einer Vollsicherung liegt zwischen 500 GByte und 25 TByte, eine inkrementelle Sicherung dauert weniger als acht Stunden. Solche Systeme lassen sich erfahrungsgemäß innerhalb von drei bis fünf Tagen wiederherstellen. Es ist jedoch ratsam, das regelmäßig zu testen, da die Flaschenhälse dabei meist außerhalb des Backup-Systems liegen.

Beim Backup solcher Clients hilft ein Leistungsmerkmal von Bacula, das sich Virtual Full Backups nennt. Nach einem initialen Backup laufen auf solchen Systemen nie wieder tatsächliche Vollsicherungen, sondern nur noch tägliche inkrementelle Backups. Zusätzlich erfolgen alle zwei Monate virtuelle Voll-Backups, die Bacula ohne Zutun des Clients nur aus den auf dem Server vorhandenen Daten erzeugt. Sie beziehen das letzte (virtuelle) Voll-Backup sowie die seitdem vom Client erstellten inkrementellen beziehungsweise differenziellen Sicherungen ein. Ein solches virtuelles Virtual Full Backup ist um einen Faktor Sieben und mehr schneller als eine tatsächliche Vollsicherung.

Damit ergeben sich zwei Scheduling-Klassen. Große Server machen nur tägliche inkrementelle Backups vom Client, alle zwei Monate ein Virtual Full Backup und dazwischen noch eine differenzielle Sicherung. Auf kleineren Systemen erfolgen zusätzlich zu den täglichen inkrementellen Sicherungen monatliche Voll-Backups.

Alle Sicherungsdaten, egal ob vom Client oder durch virtuelle Backups erzeugt, landen zuerst im Platten-Cache. Vollsicherungen, die älter als einen Monat oder größer als 32 GByte sind, werden danach auf Band migriert. Dagegen verbleiben inkrementelle und differenzielle Sicherungen auf den Platten. Dieses Vorgehen reduziert die Restore-Zeiten, da eine Wiederherstellung in der Regel Daten betrifft, mit denen gearbeitet wird und die deshalb in den letzten inkrementellen Sicherungen vorhanden sind. Bei kompletten Wiederherstellungen lassen sich die dazu nötigen Vollsicherungen mit maximaler Geschwindigkeit vom Band lesen, da sie bei der Migration am Stück und nicht fragmentiert geschrieben wurden.

Konfiguration

Wie bereits erwähnt, steuert der Director als zentrale Instanz alle Abläufe. Ein Großteil der Konfigurationsdateien liegt deshalb dort. Als Storage Daemon bezeichnet man den Server, der für das Verschieben sämtlicher Daten zuständig ist, vom Client zum Platten-Cache, vom Platten-Cache auf Tape und umgekehrt. Das Abholen der Daten vom Client ermöglicht ein dort laufender Agent, der File Daemon, den der Director kontaktiert.

Der gesamte Verzeichnisbaum der Konfiguration könnte unter »/opt/bacula/etc/conf.d« liegen und beispielsweise so aussehen wie in Listing 1. Die Definitionen der Objekte lassen sich übersichtlich nach Clients, Jobs, Daten-Pools, Backup-Schedules und so weiter unterteilen. Diese Kategorien lassen sich noch weiter gliedern, indem man beispielsweise die Clients leicht nach Organisationseinheiten gruppiert. Der Fantasie sind dabei wenig Grenzen gesetzt.

# ls /opt/bacula/etc/conf.d/
clients.d           pools.d
filesets.d          schedules.d
jobs.d              storage.d
macos_excludes.inc  unix_excludes.inc
messages.d          windows_excludes.inc
[...]

In der Definition eines Clients lässt sich angeben, welche Eigenschaften der zugehörige Backup-Job hat, nach welchem Zeitplan er läuft und ob es gilt, vor und nach dem Backup auf dem Client Skripte auszuführen. Außerdem legt man hier fest, welche Dateien im Backup gesichert und welche weggelassen werden. Das Beispiel aus Listing 2 zeigt die Definition für das Backup eines PostgreSQL-Servers, bei dem Bacula die eigentlichen Datenbankdateien weglässt und nur Dump Files der Datenbank abholt.

Client {
  Name     = dbserv
  Address  = dbserv.rz.uni-ulm.de
  Password = "XXXXXXXXXXXXXXXXXX"
  @/opt/bacula/etc/conf.d/clients.d/client_defaults.inc
}
Job {
  Name     = dbserv-bck
  Client   = dbserv
  JobDefs  = kiz-job
  FileSet  = dbserv-fileset
  Schedule = daily-0500-sched
  Messages = dbserv-msg
  Client Run Before Job = "/pgsql/scripts/preschedule"
  Client Run After Job  = "/pgsql/scripts/postschedule"
}
Messages {
  Name     = dbserv-msg
  @/opt/bacula/etc/conf.d/messages.d/default_message.inc
  MailOnError = hostadm@uni-ulm.de = all, !skipped
}
FileSet {
  Name     = dbserv-fileset
  Ignore FileSet Changes = yes
  Include {
    Options {
      exclude  = yes
      @/opt/bacula/etc/conf.d/unix_excludes-exclude_cache_dir_too.inc
      WildFile = "/pgsql/log/*"
      WildFile = "/pgsql/logs/*"
      WildFile = "/pgsql/sw/logs/*"
      WildFile = "/pgsql/tmp/*"
    }
    Options {
      @/opt/bacula/etc/conf.d/filesets.d/default_fileset_options.inc
    }
    File = /pg_backup
    File = /pg_journal
    File = /pgsql
  }
  Exclude {
    @/opt/bacula/etc/conf.d/kiz_unix_file-excludes.inc
    File = /pgsql/sw/tapes/build
    File = /pgsql/data
    File = /pgsql/xlog
    File = /pgsql/tsm
  }
}

Das Gegenstück zu dieser Konfigurationsdatei auf dem Director bildet die Konfiguration des File Daemons auf dem Client (Listing 3). Sie muss im Wesentlichen das richtige Passwort enthalten und gibt noch Spezifikationen zum Logging an. Bei Bedarf lässt sich hier auch eine Verschlüsselung konfigurieren. Der Director hat dabei keinen Zugriff auf die Daten oder die Schlüssel. Allerdings liegen Metadaten, also etwa Dateinamen, im Klartext vor, da diese Informationen für die Funktion des Systems unerlässlich sind.

FileDaemon {
  Name                  = "dbserv"
  FDAddress             = dbserv-fl-m.rz.uni-ulm.de
  FDport                = 9102
  WorkingDirectory      = /opt/bacula/working
  Pid Directory         = /opt/bacula/working
  Maximum Concurrent Jobs = 4
}
Director {
  Name     = uniulm-dir
  Password = "XXXXXXXXXXXXXXXXXX"
}
Messages {
  Name     = Standard
  director = uniulm-dir = all, !skipped, !restored
}

Restore

Der eigentliche Existenzzweck von Backups besteht in der Wiederherstellung von Daten – seien es einzelne, versehentlich gelöschte Dateien oder ganze Dateisysteme, die wegen Systemversagens oder auch wegen eines Ransomware-Angriffs verloren gegangen sind.

Um im Bacula-System Wiederherstellungen anzustoßen, muss man Zugriff auf den Director haben. Entweder startet ein Administrator den Restore, nachdem ein Benutzer via Helpdesk eine entsprechende Anforderung gestellt hat, oder der Client bietet die Möglichkeit, über das Bacula-Dienstprogramm »bconsole« auf den Director zuzugreifen und dort die erforderlichen Kommandos abzusetzen. Dabei lässt sich über ACLs festlegen, welche Kommandos über Bconsole zugänglich sein sollen.

Es empfiehlt sich in diesem Zusammenhang, Clients das Anstoßen von Backups zu verbieten und nur Restores zuzulassen. Das verhindert, dass die auf dem Server vorgehaltenen Backups durch “wilde” Sicherungen überschrieben werden, die beispielsweise ein von Malware befallenes System initiieren könnte.

Reporting

Zu den großen Stärken von Bacula zählt das Reporting. Neben vordefinierten Reports ergeben sich dank dokumentierter Datenbankstrukturen weiterführende Möglichkeiten. Zudem kann man mit »bdirjson« lesend auf die aktive Konfiguration zugreifen oder Skripte von Bconsole ausführen lassen. Die SQL-Query aus Listing 4 liefert, eingebettet in die Skriptsprache der Wahl, eine Übersicht über die Clients, die insgesamt den größten Platzbedarf haben und optional einem Namensmuster genügen.

SELECT
  Client.Name,
  sum(JobFiles) AS Files,
  sum(JobBytes) AS Bytes
FROM
  Job, Client, Pool
WHERE
      Client.Name ~* '$pattern'
  AND Client.ClientId = Job.ClientId
  AND Job.PoolID = Pool.PoolID
  AND Job.Type = 'B'
  AND JobStatus IN ('T', 'W')
GROUP by Client.Name
ORDER by Bytes DESC
LIMIT $number;

Ein selbst entwickeltes Tool nutzt die Abfragen, um Anomalien zu erkennen. Eines der ärgerlichsten Probleme tritt auf, wenn auf dem Client externe Devices oder Filesysteme gesichert werden sollen, die aber zum Zeitpunkt des Backups nicht gemountet sind. Bacula interpretiert das als Löschung der Daten und markiert sie entsprechend für diesen Zeitpunkt in der Datenbank als gelöscht. Lassen sich die Daten beim nächsten Backup auf dem Client wieder erreichen, werden alle erneut gesichert. Das kann lange dauern und auch spürbare Last auf dem Client erzeugen.

Mit entsprechenden Plausibilitätsprüfungen kann man derartigen Problemen entgegenwirken. Wurden beispielsweise mehr als 5000 Dateien gelöscht und weniger als 500 KByte Daten gesichert, stimmt aller Wahrscheinlichkeit nach etwas nicht. Das Problem lässt sich im Übrigen durch frühzeitige Erkennung einfach lösen: Der Backup-Job, der die Dateien als gelöscht markiert hat, wird selbst gelöscht, und damit der vorhergehende Zustand wiederhergestellt.

Dieser Test dient dem Schutz der Clients, andere beugen einem unnötigen Ressourcenverbrauch und gegebenenfalls Restore-Problemen vor. So werden gelegentlich versehentlich die zu einer Datenbank gehörigen Dateien oder das von einer VM als virtuelle Festplatte genutzte File gesichert. Beide können sich, je nach Last des DBMS oder der virtuellen Maschine, über die Laufzeit des Backup-Jobs erheblich ändern und damit inkonsistent sein. Für den Betrieb des Systems ist es zudem wichtig, frühzeitig zu erkennen, ob Systeme bestimmte Thresholds überschreiten. Listing 5 zeigt ein Beispiel für die Ausgabe einer solchen Prüfung.

Job   Level Jobs    Avg.Time   Avg.Files  Avg.Bytes
===================================================
job-1     I   32    02:40:51     343,351   351.6 GB
job-1     F    1  4-18:50:41  30,734,592    34.2 TB
job-1    VF    1  1-05:54:54  28,946,254    35.2 TB
(C001) latest/average full-backup size is above acceptable limit of 25TB
(C101) latest/average VFull-backup size is above acceptable limit of 25TB
(W102) last VFull runtime is longer then acceptable limit of 22h
(C301) average incremental-backup size is above acceptable limit of 200GB
(W302) at least one incremental-backup size is above threshold of 200GB

Weitere Informationen lassen sich wie bereits erwähnt via Bconsole gewinnen. Nennenswert ist hier vor allem das wenig dokumentierte Kommando ».status storage running«, das auch Daten zum Datendurchsatz einzelner Jobs zeigt. Das ist auf Systemebene sonst nur aggregiert möglich. Diese Daten lassen sich mit den anderen Mechanismen kombinieren und visualisieren. Abbildung 2 und Abbildung 3 zeigen entsprechende Beispiele.

Abbildung 2: Die Grafik zeigt die Anzahl der Backup-Prozesse und ihren Status im Verlauf der Zeit.

Abbildung 3: Dieses Diagramm bereitet den Lese- und Schreibdurchsatz grafisch auf.

Fazit

Bacula erweist sich als leistungsfähige Backup-Lösung, die auch große Umgebungen effizient sichern kann. Dank Open Source liegen Formate und Schnittstellen offen. Das bedeutet unter anderem, dass sich anders als bei proprietärer Backup-Software die gesicherten Bänder jederzeit lesen lassen, auch wenn der Lizenzvertrag irgendwann gekündigt werden sollte. Zudem bietet Bacula viele Möglichkeiten, Prozesse zu automatisieren und alle Arten nützlicher Informationen abzufragen. Bei der Entscheidung für eine neue Backup-Lösung sollten Sie es auf jeden Fall in die engere Wahl ziehen. (jcb/jlu)