Beispiel aus der Praxis

Im Folgenden möchten wir kurz beschreiben, wie die Autoren das Konzept Always Incremental in einem Kundenprojekt praktisch umgesetzt haben. Bareos sichert rund 200 Clients, die sich an sechs verschiedenen Standorten weltweit befinden. Der Bareos Director steht in einem Rechenzentrum in Deutschland. In Bild 3 sehen Sie ein Ablaufdiagramm mit den wichtigsten Auszügen aus den Konfigurationsdateien.

Bild 3: So könnte ein Plan für Always Incremental mit Konsolidierung und Langzeitarchiv aussehen.

Für die AI-Jobs gibt es für die jeweiligen Hostgruppen eine gemeinsame Definition, die als "ai-job-<hostgroup>" im Ordner "/etc/bareos/bareos-dir.d/jobdefs" hinterlegt ist. Sie setzt die schon erwähnten Direktiven Accurate, Always Incremental, Always Incremental Job Retention et cetera ein. Außerdem bestimmt sie einen Zeitplan ("schedule-<hostgroup>"). Für jeden der 200 Clients gibt es einen eigenen AI-Job ("ai-backup-<clientname>"), der die meisten Eigenschaften aus der JobDefs-Datei erbt. Nach Möglichkeit ist für Clients aus einer Hostgruppe auch ein

gemeinsames FileSet definiert, das bestimmt, welche Daten im Backup landen. In Sonderfällen kann aber ein Client sein eigenes FileSet verwenden und die Direktive aus der JobDefs-Datei überschreiben.

Der Storage Daemon ist so konfiguriert, dass es einmal Backups auf Festplatte ("Media Type = File") und einmal auf Tapes ("LTO-6") gibt. Letztere kommen nur für die Langzeitarchivierung im Pool "ai-longterm" zum Einsatz.

Der Datenfluss sieht so aus: Es gibt ein initiales Vollbackup im Pool "ai-consolidated-<hostgroup>". Danach folgen kontinuierlich inkrementelle Backups im Pool "ai-inc-<hostgroup>". Deren Aufbewahrungszeit bestimmen die Parameter "Always Incremental Job Retention" und "Always Incremental Keep Number" (in der Jobdefinition), da Bareos nicht mehr benötigte Volumes nach der Konsolidierung zum Recycling freigibt. Die Retention-Parameter im Pool sollten deutlich größer sein als die des Jobs, um zu verhindern, dass ein Recycling vor einer Konsolidierung stattfindet. Wenn etwa ein Client nur alle ein bis zwei Wochen gesichert wird, die Anweisung aber "Always Incremental Keep Number = 10" lautet, kann es sein, dass "Volume Retention = 90" nicht ausreicht.

Der Konsolidierungsjob speichert zwischendurch neue Vollsicherungen im Pool "ai-consolidated-<hostgroup>". Ein Copy Job kopiert dann die Daten aus "ai-consolidated" in den Langzeit-Pool "ai-longterm", wo sie zehn Jahre lang auf Tape archiviert werden. Es gibt jeweils eigene Zeitpläne in den Schedule-Konfigurationsdateien für die inkrementellen Backups (verschiedene Zeitpunkte für die einzelnen Hostgruppen), für die Konsolidierung (jeden Mittag um 12 Uhr) und für den Copy Job, der jeden ersten Sonntag im Monat um 1 Uhr startet.

Fazit

Always Incremental überzeugt nicht nur in großen Umgebungen mit vielen hundert Maschinen, die über das Netzwerk mit einem Bareos Director verbunden sind, sondern auch in kleineren Settings. Die Autoren nutzen eine AI-Konfiguration beispielsweise im privaten Umfeld, um einen externen vServer ins Backup einzubinden. Da nur ein initiales Vollbackup notwendig ist, spart Always Incremental viel Bandbreite. Der größte Vorteil ist aber sicherlich die Entlastung der Clients, denn AI benötigt deutlich weniger CPU- und Festplatten-Ressourcen. Die Hauptarbeit findet nicht länger auf den zu sichernden Maschinen, sondern auf dem Backupserver während der Konsolidierung statt.

Nicht verschweigen wollen wir die Kehrseite der Medaille: Temporär benötigt das AI-Backup mehr Platz, das heißt, auf dem Zielmedium ist ein gewisser Overhead erforderlich, bevor das Recycling beginnt. Überdies ist es nicht ganz trivial, ein Konzept mit unterschiedlichen Zeitplänen und mehreren Pools zu erstellen. Der Ablaufplan aus unserem Beispiel mit 200 Clients kann vielleicht als Inspiration dienen, und Fragen zu Always Incremental sind auf der Bareos-Users-Mailingliste [5] gut aufgehoben.

(ln)