Der ADMIN 05/13 wirft einen Blick auf die frei verfügbaren Cloud-Frameworks von Eucalyptus über OpenNebula bis OpenStack. Gute Aussichten für skalierbare ... (mehr)

Komplexe Umgebungen

Manchmal ist für den Administrator schwer kalkulierbar, wie groß ein Backup wird. Ein erster Ansatz, damit umzugehen, besteht darin, bestimmte Verzeichnisse und Datentypen in den die Sicherung beschreibenden Dateilisten auszuschließen. Alternativ lassen sich auch Dateien ab einer bestimmten Größe ausschließen.

Dies garantiert aber nicht, dass auf einem Client nicht trotzdem große Datenmengen anfallen. Mit einer Client-Quota kann man bei Bareos daher die Gesamtmenge der zu sichernden Daten eines Clients festlegen. Zudem kann man sich mittels Soft-Quotas und Grace-Periode auch frühzeitig informieren lassen, wenn die Quotierung erschöpft ist.

Außerdem sollte man im Blick behalten, dass bei einer Vollsicherung große Datenmengen durch das Netz zu transportieren sind. Da ist es von Vorteil, dass Bareos auch die maximal genutzte Netzwerkbandbreite pro Client einschränken kann. Hierfür dient die Direktive »Maximum Bandwidth Per Job« , die zu dem entsprechenden Client-Eintrag in »/etc/bareos/bareos-dir.conf« hinzuzufügen ist:

Client {
 Name = client2-fd
 Address = client2
 Password = "secret"
 Maximum Bandwidth Per Job = 512 k/s
}

Als grundlegende Neuerung ist die direkte Unterstützung von NDMP (Network Data Management Protocol) hinzugekommen. NDMP ist das native Backup-Protokoll großer NAS-Geräte wie etwa von NetApp. Mit der Version 12.4 werden Vollsicherungen und Rücksicherungen unterstützt. Die Wiederherstellung von Einzeldateien ist bei Bareos noch in der Erprobungsphase.

Zudem wurde ein neues Plugin zur Sicherung von Microsoft-SQL-Server-Datenbanken geschrieben. Es beherrscht neben Voll- auch inkrementelle und differenzielle Sicherungen und befindet sich ebenfalls in der Erprobungsphase.

Das nächste Projekt geht die Sicherung virtueller Maschinen von VMware über die VStorage-API an. Hier wurden bereits die ersten Gehversuche unternommen.

Copy-Jobs

Backup-Bänder sind immer noch das Mittel der Wahl für das Sichern von Daten, aber auch Sicherungen auf Festplatte haben ihre Vorteile. Deshalb werden häufig beide Ansätze verknüpft: Üblich sind Disk-To-Disk-To-Tape-Sicherungen (D2D2T). Dabei wird zuerst auf Festplatte gesichert, danach werden die Daten über einen Migrations- oder Copy-Job auf ein Band übertragen.

Vor Bareos 13.2 konnten Migrations- und Copy-Jobs nur innerhalb eines Storage Daemons durchgeführt werden (Abbildung 2). Diese Einschränkung ist mit Bareos 13.2 aufgehoben – Daten lassen sich nun zwischen Storage Daemons transportieren (Abbildung 3).

Abbildung 2: Bisher: Kopieren ist nur innerhalb eines Storage Daemons möglich.
Abbildung 3: Neu: Kopieren ist zwischen verschiedenen Storage Daemons über das Netzwerk möglich.

Damit ist es möglich, Daten beispielsweise in unterschiedlichen Brandschutzabschnitten, zu sichern. Ein entsprechender Copy-Job kann Daten periodisch auch zu einem anderen Storage Daemon kopieren. Dabei lassen sich die Eigenschaften der Daten anpassen, sodass zum Beispiel die Daten auf dem ersten Storage Daemon unkomprimiert abgelegt sind, für den zweiten aber komprimiert werden. Auch Szenarien wie Backup-to-Disk-to-Cloud sind so abbildbar.

Ä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