Benutzer-Werkzeuge

Webseiten-Werkzeuge


 [[anwenderwiki:backup_restore:backup-rsnapshot]] 

Backup-Rsnapshot: Eine Backuplösung auf der Basis von Rsnapshot

Getestet mit den folgenden Versionen:
  • linuxmuster.net 6.1 (ab Backup-Rsnapshot Version 1.6)
  • linuxmuster.net 6.0 (ab Backup-Rsnapshot Version 1.2)
  • LML 5.1
  • LML 5.0

Mit der hier vorgestellten Backup-Strategie wird jede Nacht ein dateibasiertes Pseudo-Vollbackup auf einer gesonderten Partition erzeugt, idealerweise auf einer Wechselplatte.

„Vollbackup“ bedeutet, dass bei jedem Durchlauf der komplette Verzeichnisbaum gesichert wird. „Pseudo“ deshalb, weil Dateien, die schon im letzten Backup vorhanden sind, nicht erneut gesichert werden; vielmehr wird ein Hardlink angelegt. Aus der Sicht des Anwenders hat man also ein Vollbackup, tatsächlich neu gesichert werden aber nur neue oder veränderte Dateien, was den Speicherplatz und die Laufzeit deutlich reduziert (typisch sind 10-30 Minuten). Gleichzeitig ist aber von jeder Datei nur eine Kopie vorhanden, man sollte also auf mehrere Medien sichern.

Basierend auf dem Backupskript von Thomas Schmitt werden vor dem Backup kritische Dienste wie die Datenbanken heruntergefahren, sodass ein konsistentes Backup erzeugt wird.

In der Ausgangskonfiguration werden die letzten 60 täglichen Backups behalten (daily.0, daily.1, …) und dann noch für 12 Monate jeweils eines (monthly.0, monthly.1, …). Diese Werte können nach Wunsch angepasst werden.

Weshalb das Ganze:

  • Die Zeiten für die Sicherung mit Mondorescue sind auf großen Systemen problematisch
  • Das Zurückspielen einzelner Dateien ist bei Mondorescue recht umständlich
  • Ich benötigte eine Rundum-Sorglos-Backup-Lösung für meinen Server zu Hause ;-)

Aber:

  • Jede Datei wird physikalisch nur einmal gesichert. Für Redundanz muss also anderweitig gesorgt werden, etwa durch das verwenden mehrerer Backupplatten im Wechsel.
  • Es gibt keinen Support
  • Ein Desaster-Recovery ist (ein wenig) umständlicher, dafür vermutlich weniger fehleranfällig – siehe unten
  • Man kann das Backup nicht über die Schulkonsole einrichten

Features

  • Automatisches tägliches Vollbackup per Cronjob
  • Backup der Firewall-Einstellungen (IPCop/IPFire)
  • Extra-Sync-Option für minimale Downzeiten
  • Log-Datei per E-Mail bei fehlgeschlagenem Backup
  • Optional: Verschlüsselung des Backups mit TrueCrypt

Installation

Download: backup-rsnapshot-1.6.2.tgz

Man speichert die Datei auf dem Server und packt sie aus:

tar xzf backup-rsnapshot-1.6.2.tgz

Dabei wird ein Verzeichnis backup-rsnapshot erzeugt. In diesem Verzeichnis findet man eine Installations- und Konfigurationsanleitung.

Etwaige Cronjobs für das Linuxmuster-Backup sollte man vorher natürlich deaktivieren.

Neu ab Version 1.6.2

In Version 1.6.2 werden die Dienste schon vor dem Rotieren der Backups wieder hochgefahren, wodurch sich die Downtime deutlich reduziert, wenn man die maximale Anzahl an Backups hat. Außerdem wurden einige kleinere Fehler beseitigt, die aber nur auf anderen Systemen als linuxmuster.net auftreten. Wenn die Backupplatte zu 90 % belegt ist, dann wird eine entsprechende Mail an den Administrator versendet.

Update von 1.6

Ein Update von Version 1.6 geht am einfachsten so:

- Die Datei /usr/local/sbin/backup-rsnapshot durch die aus dem tgz ersetzen
- In /etc/backup-rsnapshot/rsnapshot.conf bei den Zeilen mit den Excludes Folgendes ergänzen:
    exclude /run/**
    exclude *.gvfs

Neu ab Version 1.6

Version 1.6 enthält nur minimale Anpassungen an Linuxmuster.net 6.1. Anstelle eines Upgrades pflegt man sie besser selbst ein (s. u.).

Neu ab Version 1.5

Bei Version 1.5 werden optional sämtliche Bind-Mounts vor dem Backup gelöst. Unterbleibt dies, so landet für jeden User, der während des Backups angemeldet ist, eine Kopie der Tauschverzeichnisse im Backup.

Außerdem funktioniert das Backup wieder mit NFS – das war in 1.4 vermurkst.

Neu ab Version 1.4

Mehrere Anwender von linuxmuster.net berichten, dass beim Booten die Zuordnung der Festplatten zu den Gerätenamen unvorhersehbar wechselt. Dies kann man abfangen, indem man mit Dateisystemlabeln arbeitet.

Verwendet man jedoch TrueCrypt, so ist dies leider nicht möglich, da etwaige Label ja erst nach dem Mounten im Klartext vorliegen. Ab Version 1.4 kann man deshalb eine Liste von Partitionen angeben, und die erste, die im System gefunden wird, wird genommen. Verschlüsselte Partitionen kann man über die Links in /dev/disk/by-id eindeutig benennen.

Upgrade

Upgrade von 1.5 auf 1.6 / Anpassungen für Linuxmuster.net 6.1

Die Version 1.6 bringt nur zwei kleine Anpassungen an die LML 6.1. Anstatt die neue Version herunterzuladen führt man die Änerungen schneller selbst durch:

  • In der Datei /etc/backup-rsnapshot/backup-rsnapshot.conf ersetzt man bei den zu stoppenden Diensten tftpd-hpa durch atftpd.
  • In der Datei /etc/backup-rsnapshot/rsnapshot.conf ergänzt man bei rsync_short_args ein A, also: rsync_short_args -aAX (siehe auch den Abschnitt zu den ACLs).

Upgrade von älteren Versionen

Ein Upgrade von einer älteren Version geht am schnellsten so:

  • Sichern von /etc/backup-rsnapshot
  • Installieren der neuen Version mit install.sh
  • Manuelle Neukonfiguration (Dateien /etc/backup-rsnapshot/backup-rshapshot.conf und eventuell /etc/backup-rsnapshot/rshapshot.conf, dann noch den Zeitpunkt des Cronjobs anpassen).

Verwendung

Backup-Rsnapshot stellt drei Befehle bereit:

  • mount-backup
  • umount-backup
  • backup-rsnapshot

Die ersten beiden sind eine Abkürzung für das Ein- und Aushängen der Backuppartition – praktisch vor allem, wenn TrueCrypt zum Einsatz kommt.

Man kann das Backup jederzeit mit backup-rsnapshot anstoßen. Es wird die Backupplatte gemountet, dann werden die konfigurierten Dienste heruntergefahren, das eigentliche Backup erzeugt, die Dienste wieder hochgefahren und die Backupplatte wieder ausgehängt.

Im Dauerbetrieb wird das Backup durch einen Cronjob gestartet. Der Cronjob ist schon vorkonfiguriert und aktiviert, die Uhrzeit kann man in der Datei /etc/cron.d/backup-rsnapshot ändern. Im Fehlerfall wird eine Mail an den administrator versandt.

Vor dem ersten Durchlauf (oder bei sehr großen Veränderungen) kann man die Platte manuell einbinden und mit rsnapshot sync das erste Backup im laufenden Betrieb durchführen. Da nun alle Dateien einmal kopiert werden, dauert das eine ganze Weile. Bei diesem Backup sind eventuell die Datenbanken etc. nicht korrekt gesichert, weshalb man mit backup-rsnapshot einen echten Durchlauf startet. Der und auch alle weiteren sollte nur wenige Minuten dauern, da nur die seit dem letzten Backup geänderten Dateien kopiert werden.

Es ist zu empfehlen, die Backupplatte regelmäßig zu wechseln. Dies kann man jederzeit tun, wenn nicht gerade das Backup läuft. Wenn man eine ganz neue Platte nimmt, muss man natürlich vorher partitionieren, formatieren und einen Ordner backup-rsnapshot anlegen.

Log-Dateien

Es werden mehrere Log-Dateien im Verzeichnis /var/log/backup-rsnapshot erzeugt. Ein Logrotate-Job sorgt für Ordnung.

Zurückspielen einzelner Dateien

Für jedes Backup wird auf der Backupplatte ein kompletter Dateibaum des Servers angelegt, aus dem man einzelne Dateien oder auch ganze Ordner bequem zurückkopieren kann. Wann das Backup erzeugt wurde erkennt man am Datum des jeweiligen Backupverzeichnisses (daily.0, daily.1, …).

Beim Zurückkopieren einzelner Dateien odert Ordner verwendet man am besten die Befehle cp -a oder rsync -aAX.

Komplettrestore

Für ein Komplettrestore bootet man den Server (oder auch einen neuen) von einer Live-Umgebung (CD/DVD/USB-Stick). Dann partitioniert man die neue Platte nach demselben Schema wie im alten Server und legt die Dateisysteme an. Nun mountet man das Backup sowie die neue Platte.

Angenommen, die Backupplatte ist im Live-System nach /mnt/backup gemounted und die Root-Partition der neuen Platte nach /mnt/neu (hat man weitere Partitionen eingerichtet, muss man diese noch in entsprechende Unterverzeichnisse von /mnt/neu mounten).

Dann kopiert man die Dateien aus dem letzten Backup auf die neue Platte:

cp -a /mnt/backup/backup-rsnapshot/daily.0/server/* /mnt/neu

Nun muss man noch die neue Platte (im Beispiel sda) bootbar machen:

mount -o bind /dev /mnt/neu/dev
mount -o bind /proc /mnt/neu/proc
mount -o bind /sys /mnt/neu/sys
chroot /mnt/neu
cat /proc/mounts > /etc/mtab
grub-install /dev/sda
update-grub
exit

Zuletzt muss man noch die Datei /etc/fstab (derzeit also /mnt/neu/etc/fstab) an die neuen Verhältnisse anpassen. Hier stehen vermutlich noch die UUIDs der alten Platte, die ersetzt man durch die UUIDs der neuen - oder auch einfach durch die Gerätedateien wie /dev/sda1. Hat man ein von der alten Situation abweichendes Partitionierungsschema gewählt, so muss auch dieses nachbilden.

root@s004hp08:~# blkid /dev/sda*
/dev/sda1: UUID="ec56ca54-f362-4028-b0f3-065273983a02" TYPE="ext4" 
/dev/sda5: UUID="c8f7e21a-8816-4b0b-a902-d3c9f235dda3" TYPE="swap" 

Jetzt sollte der Server von der neuen Platte booten.

IPCop/IPFire

Optional kann man die Einstellungen der externen Firewall mitsichern. Sie werden in einem Verzeichnis unterhalb von /var/backup/linuxmuster auf dem Server abgelegt.

Eine Sicherung des IPCop kann man mithilfe der dafür vorgesehenen Skripte zurückspielen.

Bei IPFire wird der eingebaute Sicherungsmechanismus verwendet. Möchte man ein Sicherung zurückspielen, so lädt man die Datei im Webfrontend auf den Firewallrechner hoch und spielt sie dann von dort aus zurück; gegebenenfalls kann man vorher eine Neuinstallation durchführen (sicherheitshalber mit derselben Version wie vorher vorhanden).

Inzwischen ist ein Skript zum Backup des IPFire offizieller Bestandteil von linuxmuster.net. Deshalb sollte man das Backup des IPFire hier höchstens zusätzlich aktivieren.

ACLs

Ab der Version 6.1 von Linuxmuster.net werden die Zugriffsrechte für die Tauschverzeichnisse mit ACLs gesteuert.

Dateisystem des Backups unterstützt ACLs

Wenn das Dateisystem des Backups ACLs unterstützt - wie etwa Ext4 mit den Standardeinstellungen – so werden die automatisch ACLs mitgesichert. Bei einem Restore sollte man darauf achten, die entsprechenden Schalter zu verwenden (cp -a bzw. rsync -aA).

Dateisystem des Backups unterstützt ACLs nicht

Wenn man die ACLs nicht sichern kann, so ist das auch kein Problem. Die Stategie hängt hier davon ab, was man nutzt:

  • ACLs zur raumweisen Steuerung des Zuugriffs auf die Tauschverzeichnisse: hier stellt ein import_workstations nach einem Restore die Standardrechte wieder her.
  • Eigenhändig eingerichtete ACLs (z. B. mit sophomorix-teacher): Möchte man diese sichern, so richtet man einen Cronjob ein, der die ACLs in eine Datei schreibt. Der entsprechende Befehl heißt etwa getfacl -R /home/share > /home/share.acl. Die Datei share.acl enthält nun alle ACLs und landet im Backup. Ein Restore der ACLs geht mit setfacl --restore=/home/share.acl – die Datei share.acl muss man natürlich vorher aus dem Backup wiederherstellen.

Backup auf einem weiteren Linux-Rechner im LAN:

Installation von NFS auf dem Ziel-Rechner

apt-get install nfs-kernel-server nfs-common portmap

Anlegen des Freigabeverzeichnisses und setzten der Benutzerrechte:

mkdir /var/nfs
chown nobody:nogroup /var/nfs

Bearbeiten der exports Datei:

vi /etc/exports
/var/nfs           10.16.1.1(rw,sync,no_root_squash)

Bekanntgeben der Freigabe:

exportfs -a

Am zu sichernden Server:

aptitude install nfs-common portmap
vi /etc/backup-rsanpshot/backup-rsnapshot.conf

Dabei: backupdevice=ip-des-zielechners:/var/nfs

Da NFS keine erweiterten Dateiattribute unterstützt (gemeint sind user_xargs – die ACLs in den Tauschverzeichnissen sind kein Problem), muss man in /etc/backup-rsnapshot/rsnapshot.conf bei den rsync_short_args das X entfernen.

 [[anwenderwiki:backup_restore:backup-rsnapshot]] anwenderwiki/backup_restore/backup-rsnapshot.txt · Zuletzt geändert: 2016/02/10 16:29 von 127.0.0.1