Nicht erst die stetigen Ransomware-Angriffe verdeutlichen den enormen Stellenwert von Backups im Unternehmen: Ein falscher Klick genügt und schon steht die ... (mehr)

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.

Link-Codes

[1] Bareos-Homepage: https://www.bareos.com/de/

[2] Always Incremental Backup Scheme: https://docs.bareos.org/TasksAndConcepts/AlwaysIncrementalBackupScheme.html/

[3] "Erstkontakt", IT-Administrator Ausgabe 03/2019: https://www.it-administrator.de/magazin/heftarchiv/artikel/294088.html/

[4] Bareos-Handbuch: https://docs.bareos.org/index.html/

[5] Google-Gruppe "bareos-users": https://groups.google.com/forum/#!forum/bareos-users/

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)

Ähnliche Artikel

comments powered by Disqus
Mehr zum Thema

Workshop: Aufbau und Inbetriebnahme von Bareos

Bareos ist als Fork des Backup-Klassikers Bacula ein vollständig quelloffenes und freies Werkzeug zur Datensicherung. Neben zusätzlichen Features verschlankt Bareos vor allem die Konfigurations-Dateien und vereinfacht so die Konfiguration. Dieser Workshop führt durch die Inbetriebnahme und Einrichtung des Sicherungstools und zeigt darauf aufbauend ein erstes Backup.

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

Google+

Ausgabe /2020