Mit einer vernünftigen Backup-Strategie wappnen sich Administratoren erfolgreich gegen Datenverluste und längere Systemausfälle. So zeigen wir Ihnen ... (mehr)

 Regelmäßige Snapshots

Das folgende Beispiel zeigt eine rsnap-shot-Konfiguration für ein stündliches, tägliches und wöchentliches Backup des etc-Verzeichnisses:

retain      hourly      6
retain      daily         7
retain      weekly     4

 

backup    /etc/        localhost/

Mit diesen Einstellungen müssen Sie noch dafür sorgen, dass rsnapshot regelmäßig aufgerufen wird. Denn rsnapshot kümmert sich darum, dass Daten synchronisiert und rotiert werden, nicht aber um die regelmäßige Ausführung. Für diese Aufgabe gibt es den cron-Dienst, der für kontinuierliche Backups sorgt:

# vi /etc/cron.d/rsnapshot
0 */4 * * * root /usr/bin/rsnapshot hourly
30 3 * * * root /usr/bin/rsnapshot daily
0 3 * * 1 root /usr/bin/rsnapshot weekly

Die Einträge sorgen dafür, dass alle vier Stunden ein hourly-Backup ausgeführt wird (sechs Snapshots werden aufgehoben), täglich um 03:30 ein daily-Backup läuft (sieben Snaphots bleiben erhalten) und jeden Montag um 03:00 ein weekly-Backup startet (vier Snapshots stehen zur Verfügung). Die regelmäßige Ausführung von Backups über cron eignet sich genau so gut für rdiff-backup. Erstellen Sie einfach einen Cronjob, der regelmäßig für den rdiff-backup-Aufruf sorgt.

Backups über SSH

Sicherungen von einem produktiven System auf einem Backup-Server übers Netzwerk per SSH durchzuführen, hat den Vorteil, dass die Datenkommunikation verschlüsselt wird. Nach der Sicherungsrichtung unterscheiden wir:

- Pull-Backups: der Backup-Server sichert einen remote Server lokal.

- Push-Backups: der Server überträgt seine Daten zum Backup-Server.

Die im ersten Abschnitt erwähnten Sicherheitsmaßnahmen betreffen vor allem Pull-Backups, schaden aber auch bei Push-Backups nicht. Eine wirksame »authorized_keys« -Konfiguration schränkt den Backup-Benutzer ein:

# cat .ssh/authorized_keys
command="/usr/bin/python /usr/bin/rdiff-backup --server",no-agent-forwarding,no-port-forwarding,no-user-rc,no-X11-forwarding,no-pty ssh-rsa AAAAB3NzaC1y[...]

Das richtige Kommando für den Parameter command zu finden, kann knifflig werden. Wie Sie bei der Analyse vorzugehen haben, finden Sie im Thomas-Krenn-Wiki [3].

Weitere Vor- und Nachteile von rdiff-backup und rsnapshot

rdiff-backup

rsnapshot

Vorteile

Increments speichern gesicherte Daten sehr effizient ab

Jeder Snapshot ist als herkömmliches Verzeichnis zugänglich

Detaillierte Logs und Statistik-Daten

Hard Link-Mechanismus funktioniert einfach und schnell

Nachteile

Increments verursachen Mehraufwand

Eignet sich nur bedingt für Dateien, die sich häufig ändern

Kein Löschen eines einzelnen Increments (vergleiche )

Push-Backups über SSH nur über Umweg

Der Backup-Benutzer benötigt auf dem zu sichernden Server Root-Rechte, um auch System-Daten zu sichern. Eine entsprechende sudo-Konfiguration vermeidet den Einsatz eines kompletten Root-Benutzers:

# vi /etc/sudoers.d/rdiff
rdiff ALL=(root)NOPASSWD:/usr/bin/rdiff-backup

Link-Codes

[1] Rdiff-backup Beispiele – File Selection: http://Rdiff-backup/

[2] Rsnaphot How-To: http://www.rsnapshot.org/howto/1.2/rsnapshot-HOWTO.en.html/

[3] Ausführbare SSH-Kommandos per authorized keys einschränken: https://www.thomas-krenn.com/de/wiki/Ausf%C3%BChrbare_SSH-Kommandos_per_authorized_keys_einschr%C3%A4nken/

[4] Pushing hard-linked Backups: https://lists.samba.org/archive/rsync/2007-December/019470.html/

Dem Benutzer rdiff wird mit der Konfiguration erlaubt, das Kommando »/usr/bin/rdiff-backup« mit Root-Rechten ohne Passwort aufzurufen. Einen anderen Befehl darf rdiff aber nicht mit sudo ausführen. Beim Sichern über SSH müssen Sie dann dafür sorgen, dass Sie sudo dem eigentlichen Backup-Befehl voranstellen:

# rdiff-backup --remote-schema 'ssh -C %s sudo rdiff-backup --server' rdiff@192.168.56.105::/etc /mnt/backup

Sicherungen über SSH gehören bei rdiff-backup zum Standard-Repertoire. Pull und Push-Backups unterstützt es gleichermaßen. Die erste Zeile zeigt die Pull-Variante, die zweite arbeitet im Push-Modus:

rdiff-backup rdiff@192.168.56.1::/etc /mnt/backup
rdiff-backup /etc/ rdiff@192.168.56.105::/mnt/backup

Rsnapshot erlaubt in seiner Konfigurationsdatei nur Pull-Backups:

backup rsnap@192.168.56.1:/etc remoteA/

Standardmäßig unterstützt es Push-Backups über SSH nicht. In manchen Situationen sind Push-Backups aber unumgänglich, zum Beispiel wenn aufgrund von Firewall-Regeln nur die Richtung Server zu Backup-Server erlaubt wird. In diesem Fall lassen sich mit rsync und geschickter Konfiguration sehr wohl Push-Backups mit rsnapshot konstruieren:

1. Am Backup-Server wird dem öffentlichen Schlüssel des Servers ein rsync-Daemon inklusive Konfiguration zugeordnet, das geschieht in der Datei »authorized_keys« .

2. Die Konfiguration des rsync-Daemons am Backup-Server gibt den Backup-Pfad an. Er ruft via »post-xfer exec« ein Script auf, das rsnapshot beinhaltet.

3. Um mehrere Server verwalten zu können, wird eine von »/etc/rsnapshot.conf« unabhängige Konfiguration erstellt, die das Backup-Schema vorgibt.

4. Möchte der Server ein Backup anstoßen, synchronisiert er über rsync und SSH die Daten mit dem Backup-Server.

In »authorized_keys« wird daraufhin der rsync-Daemon und sein Post-Exec (siehe oben Schritt 2) getriggert – es wird automatisch ein Snapshot erstellt.

Als Nachteil dieser Lösung erweist sich die Zwischenstation über rsync. Die Basis, die über rsync synchronisiert wird, dient als Quelle für rsnapshot. Zusätzlich zu den Snapshots sind die gesicherten Daten also noch ein weiteres Mal vorhanden, also nicht sehr platzeffizient. Lösungsansätze für diese Platz-Verschwendung werden unter anderem auf der Mailing-Liste diskutiert [4].

Ähnliche Artikel

comments powered by Disqus
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 /2023