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:
Aber:
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.
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.
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
Version 1.6 enthält nur minimale Anpassungen an Linuxmuster.net 6.1. Anstelle eines Upgrades pflegt man sie besser selbst ein (s. u.).
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.
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.
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:
/etc/backup-rsnapshot/backup-rsnapshot.conf
ersetzt man bei den zu stoppenden Diensten tftpd-hpa
durch atftpd
./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).Ein Upgrade von einer älteren Version geht am schnellsten so:
/etc/backup-rsnapshot
install.sh
/etc/backup-rsnapshot/backup-rshapshot.conf
und eventuell /etc/backup-rsnapshot/rshapshot.conf
, dann noch den Zeitpunkt des Cronjobs anpassen).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.
Es werden mehrere Log-Dateien im Verzeichnis /var/log/backup-rsnapshot
erzeugt. Ein Logrotate-Job sorgt für Ordnung.
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
.
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.
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.
Ab der Version 6.1 von Linuxmuster.net werden die Zugriffsrechte für die Tauschverzeichnisse mit ACLs gesteuert.
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
).
Wenn man die ACLs nicht sichern kann, so ist das auch kein Problem. Die Stategie hängt hier davon ab, was man nutzt:
import_workstations
nach einem Restore die Standardrechte wieder her.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.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.