Always Incremental mit Bareos

E pluribus unum

,
Der Backupklassiker "Vollsicherung, danach inkrementell und differenziell" bewährt sich in vielen Umgebungen. Bei dateibasierten Backups will das Konzept "Always Incremental" die Nachfolge antreten, denn es spart Bandbreite und die Ressourcen der zu sichernden Rechner. Wir haben uns angesehen, wie das Open-Source-Tool Bareos hier arbeitet und wie die dazugehörigen Konfigurationsdateien aussehen müssen.
Nicht erst die stetigen Ransomware-Angriffe verdeutlichen den enormen Stellenwert von Backups im Unternehmen: Ein falscher Klick genügt und schon steht die ... (mehr)

Einige kommerzielle Backuplösungen wie etwa IBM Spectrum Protect oder Veeam unterstützen das Konzept "Incremental Forever", das den letzten Stand eines kompletten Dateisystems ausschließlich aus fortlaufenden inkrementellen Sicherungen wiederherstellt. Ein Vollbackup findet nur noch einmal ganz zu Anfang statt. Als einziges Open-Source-Backupwerkzeug beherrscht Bareos [1] diese Technik seit Version 16.2.4.

Bei Bareos heißt das Feature "Always Incremental" [2]. Der Vorteil gegenüber einem Backupkonzept, das stattdessen Vollsicherung, differenzielle und inkrementelle Sicherungen miteinander kombiniert: Always Incremental reduziert die Datenmenge, die über das Netzwerk wandert, erheblich. Damit eignet sich das Konzept vor allem für schmalbandig angebundene Rechner in größeren dezentralen Umgebungen, zum Beispiel für BaaS-Anbieter (Backup-as-a-Service), punktet aber auch in kleinen Netzen mit externen Clients.

Im Folgenden stellen wir Always Incremental und die dazugehörigen Bareos-Konfigurationsdateien vor. Dabei geht es auch um Konsolidierung und die Langzeitspeicherung mit Copy Jobs oder Virtual Full Jobs. Ein Beispiel aus der Praxis mit rund 200 Clients zeigt zudem, wie sich das Konzept in großen Umgebungen implementieren lässt.

Modularer Aufbau

Bei Bareos (Backup Archiving Recovery Open Sourced) handelt es sich um eine netzwerkübergreifende Open-Source-Software (AGPLv3), die Daten aller gängigen Betriebssysteme sichern, archivieren und wiederherstellen kann. Die Software unterstützt viele verschiedene Speicher-Backends, darunter Festplatten und Tape Libraries sowie eine Reihe von Cloud-Storages. Bareos ist als Client-Server-Software implementiert und 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 (Bild 1).

Bild 1: Bareos ist als Client-Server-Software implementiert und besteht aus mehreren Komponenten, die über das Netzwerk miteinander kommunizieren.

Der Director ist die Steuerzentrale. Er verwaltet unter anderem die Einstellungen der SQL-Datenbank (Katalog) und die angeschlossenen Clients, die FileSets (die 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. Mehr zur Installation und Einrichtung von Bareos lesen Sie im IT-Administrator-Artikel "Erstkontakt" in der Ausgabe 03/2019 [3]. Informationen zum Einrichten der File Daemons, Backupjobs und Zeitpläne finden Sie im Bareos-Handbuch [4].

Voll, differenziell, inkrementell

Grundsätzlich unterscheiden Bareos und andere Backuptools zwischen verschiedenen Sicherungsstrategien. Eine Vollsicherung kopiert einfach alle zu sichernden Daten vollständig auf die Sicherungsmedien. Das Vollbackup erzielt damit die höchste Redundanz, hat aber auch einige Nachteile: Der Platz auf den Sicherungsmedien beträgt ein Vielfaches der gesicherten Daten, Backups dauern länger und beanspruchen viele System- und Netzwerkressourcen.

In der Praxis sind reine Vollsicherungen daher kaum zu finden. Stattdessen kombinieren viele das vollständige Backup mit einer differenziellen Sicherung, die nur die Unterschiede zur letzten Vollsicherung sichert. Der Referenzzeitpunkt, um die Differenz zu bestimmen, ist der Zeitpunkt der letzten Vollsicherung. Differenzielle Backups benötigen weniger Platz, weniger Zeit, weniger System- und Netzwerkressourcen; allerdings ist auch die Redundanz geringer. Während der Rücksicherung ist der Zugriff auf beide Backups erforderlich: Vollsicherung und differenzielle Sicherung.

Technisch gesehen entspricht die inkrementelle Sicherung der differenziellen – allerdings unterscheidet sich der Referenzzeitpunkt, der in diesem Fall jede beliebige zuletzt durchgeführte Sicherung sein kann. Ein inkrementelles Backup sichert immer nur Änderungen, was die Datenmenge reduziert und die Ressourcen schont. Die Redundanz ist minimal, denn bis zur nächsten Vollsicherung existiert immer nur eine Kopie auf den Sicherungsmedien. Beim Restore sind wegen der Verkettungen mehrere Medien notwendig, und der Verlust eines einzigen macht eine vollständige Rücksicherung unmöglich.

Wegen der erwähnten Vor- und Nachteile sind alle drei Sicherungsarten isoliert betrachtet keine ideale Strategie – die Kombination jedoch schon. Die Konfigurationsdateien der Zeitpläne finden Sie im Verzeichnis "/etc/bareos/bareos-dir.d/ schedule". Die mit der Bareos-Installation ausgelieferte Datei "WeeklyCycle.conf" (Listing 1) definiert eine Vollsicherung (Full) an jedem ersten Samstag eines Monats um 21 Uhr. Am zweiten bis fünften Samstag laufen entsprechend differenzielle Sicherungen um 21 Uhr. Montag bis Freitag läuft um 21 Uhr eine inkrementelle Sicherung.

Um alle konfigurierten Zeitpläne aufzulisten, führen Sie in der Bareos-Konsole (bconsole) das Kommando »show schedules« aus (Bild 2). Sie können diese CONF-Datei als Vorlage für eigene Konfigurationsdateien heranziehen.

Listing 1: WeeklyCycle.conf



Schedule {
      Name = "WeeklyCycle"
      Run = Full 1st sat at 21:00
      # (#04)
      Run = Differential 2nd-5th sat at 21:00
      # (#07)
      Run = Incremental mon-fri at 21:00
     # (#10)
}
Bild 2: In der Voreinstellung sind für Bareos zwei Zeitpläne eingerichtet: "WeeklyCycle" und "WeeklyCycleAfterBackup" für die Datenbank.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
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 /2020