Rsnapshot

Aus Arktur
(Weitergeleitet von Zusatzprogramme:rsnapshot)
Wechseln zu: Navigation, Suche

vielstufiges Backup mit rsnapshot

Inhaltsverzeichnis

Zweck

"rsnapshot" legt mit Hilfe von "rsync" und "hard links" ein vielstufiges Backup des Server in einem wählbaren Verzeichnis auf dem Server oder einem anderen Rechner (übers Netz) an.

Weil mit "hard links" gearbeitet wird, ist der tatsächliche Platzbedarf von (z.B.) 10 Backups i.a. nur ein wenig grösser als der eines einzigen Backups.

Die Backups werden nicht gepackt und sind deshalb sehr schnell und ohne zusätzlichen Lernaufwand erreichbar; eine einzelne Datei zu restaurieren dauert i.a. weniger als 2 Minuten.

Installation

Bei Arktur 3.4, 3.6 und 5.x wird "rsnapshot" automatisch mitinstalliert, aber nicht automatisch aktiviert: der Betreuer muss (je nach Platz und sonstigen Gegebenheiten) entscheiden, wohin gesichert werden soll. Und er muss mindestens bei den ersten zwei Durchläufen prüfen, ob die Sicherungen auch tatsächlich am gewünschten Ort landen; sonst kann es passieren, dass z.B. das Wurzelverzeichnis vollläuft und Arktur nicht mehr wie gewünscht arbeitet.

Mögliche Sicherungs-Verzeichnisse:

  1. Verzeichnis auf einer Partition des laufenden Systems, z.B. "/home/backup"
  2. Partition auf einer weiteren Festplatte (intern oder extern) des zu sichernden Rechners
  3. NFS-Freigabe auf einem anderen Rechner, Sicherung übers Netz

In der Datei "/etc/rsnapshot.conf" ist vor-eingestellt, dass nach "/srv/backup/Arktur" gesichert wird. Das ist im 1. obigen Fall nur ein "symlink" auf das tatsächliche Sicherungsverzeichnis, in den beiden anderen Fällen der Mountpunkt für die Partition oder die NFS-Freigabe.

Die Arktur-Version von "rsnapshot" verwaltet die Daten in Steuerungsdateien im Verzeichnis "/root/.mach-back", z.B. in "/root/.mach-back/Arktur".

Sie werden vom Skript "/root/bin/mach-back" verarbeitet, das u.a. auch prüft, ob das gewünschte Ziel auch tatsächlich erreichbar ist.

/root/bin/mach-back <Intervall> <Name der Steuerungsdatei>

z.B.

/root/bin/mach-back hourly Arktur

Wenn keine Steuerungsdatei angegeben oder gefunden wird, dann werden Ersatzwerte genommen (damit sich "rsnapshot" auch so benimmt, wie es in den allgemeinen Anleitungen steht).

Der Sicherungs-Cronjob muss freigegeben werden:

crontab -e -u root

Die Zeile mit "mach-back" ist vordefiniert als

# 20 6,16 * * * /root/bin/mach-back hourly Arktur

Wenn die Kontroll-Läufe keine Fehler angezeigt haben, dann reicht es, die Raute am Zeilenanfang zu entfernen, damit die täglichen Sicherungen (und darauf aufbauend alle weiteren Sicherungen) gestartet werden.

Backup in ein Unterverzeichnis von "/home"

In "/etc/rsnapshot.conf" ist als Ziel der Sicherung "/srv/backup" vor-eingestellt.

Der Linux-Standard sieht für solche Aufgaben das Startverzeichnis "/srv" vor, das sollte also nicht unbedingt geändert werden. Aber "/srv/backup" liegt im Wurzelverzeichnis, taugt also nicht als direktes Ziel einer Sicherung: die Partition läuft rasch voll.

Also: (als root; Annahme: Ziel ist "/home/backup")

rm -rf /srv/backup
mkdir -p /home/backup
ln -s /home/backup /srv/backup

Wesentlicher Nachteil dieser schnellen Lösung (die immer noch viel besser ist als gar keine Sicherung): wenn "userquota" eingeschaltet ist, dann werden auch die gesicherten Dateien jedes Users mitgezählt, und dann ist jede Quota-Grenze rasch erreicht.


Steuerdatei "/root/.mach-back/Arktur"

entweder alles ausgeblendet oder (mindestens)
Typ=dir

Backup auf eine andere Partition (oder Platte) im Server

Annahme: Arktur liegt auf "/dev/sda", gesichert werden soll nach "/dev/sdd4"

Die Partition "/dev/sdd4" muss natürlich existieren und formatiert sein (am besten mit dem Typ "ext3").

Steuerdatei "/root/.mach-back/Arktur"

Typ=disk
Ziel=/dev/sdd4

Wenn keine so definierte Partition gefunden wird (z.B. weil sie zu einem externen Laufwerk gehört, das nicht immer angeschlossen ist), dann wird nicht gesichert.

grosse Platte einrichten

Fürs Backup auf eine andere Platte muss meistens erst mal diese Zielplatte eingerichtet werden; die Anleitung ist bei Installation:Platte und bei Texte:partitionieren zu finden.

Backup übers Netz auf einen anderen Rechner

Annahme: von Arktur (192.168.0.1) auf Capella (192.168.0.3)

       ping -c3 Capella

muss funktionieren; sonst: IP-Adresse statt des Namens

Annahme: auf Capella soll nach "/home/backup/Arktur" gesichert werden.

auf Capella

Datei "/etc/exports"

       /home/backup/Arktur      192.168.0.1(rw,sync,no_root_squash)

evtl. sonstige Zeilen mit "/home" ausblenden

Änderung übernehmen:

               exportfs -av

muss auch die geänderte Zeile anzeigen

auf Arktur

               showmount -e Capella

muss die gleichen Freigaben zeigen, insbesondere die Freigabe von "/home/backup/Arktur"

Datei "/etc/rsnapshot.conf"

       snapshot_root /srv/backup/
       # wichtig: "/" am Ende!

Steuerdatei "/root/.mach-back/Arktur"

Typ=nfs
Ziel=Capella:/home/backup/Arktur

Wenn keine so definierte Partition gefunden wird (z.B. weil der Zielrechner nicht erreichbar ist), dann wird nicht gesichert.

Backup übers Netz per "rsync"

Die Quelle kann nicht nur (wie gerade beschrieben) per NFS eingebunden werden, sondern auch per "rsync".

Dazu ist allerdings nötig, dass "root" sich per "Key" auf dem anderen Rechner einloggen kann, wie beispielsweise bei http://www.escape.de/~hullen/Arktur/Hullen/ipput.html im Abschnitt "sftp mit automatischer Einwahl" beschrieben ist.

Wer (wie auf dieser Seite im Abschnitt 8 beschrieben) die SSH-Einwahl für "root" grundsätzlich blockiert hat, der muss sie für die Übermittlung des "Key" kurzzeitig aufheben.

Quelle per rsync adressieren

Am Ende der Konfigurationsdatei ist beispielsweise einzutragen:

backup    root@192.168.0.1:/       ./Wurzel
backup    root@192.168.0.1:/var    ./var
backup    root@192.168.0.1:/home   ./home

(die Spalten sind nach wie vor per Tabulator abzutrennen)

wenn von einem anderen Rechner aus die Arktur-Partitionen gesichert werden sollen, wenn also dieser Rechner sich die Daten von einem anderen Rechner holen soll.

Ziel per rsync adressieren

Das Ziel (das in "snapshot_root" zu definieren ist) kann nicht auf ähnlich einfache Weise per "rsync" adressiert werden, wenn es auf einem anderen Rechner liegt; in der Mailingliste ist ein Skript beschrieben, das die nötigen Arbeiten erledigen kann; das ist bestenfalls etwas für Linux-Profis.

Wenn also die zu sichernden Daten auf einem anderen Rechner abgelegt werden sollen, dann ist die Anbindung per NFS zu bevorzugen.

Sicherung auf ein Unterverzeichnis einer anderen Partition

(Variante der Sicherung auf andere Partition)

Wenn als Ziel eine andere Partition genommen wird, dann ist die Ansteuerung von Unterverzeichnissen etwas kompliziert, und vor allem können diese Unterverzeichnisse nicht einzeln "read only" gesetzt werden.

Für solche Fälle lohnt es sich, das gewünschte Unterverzeichnis als NFS-Freigabe in "/etc/exports" einzutragen, und es als NFS-Freigabe (auch vom eigenen Rechner aus) zu mounten; dann kann einzig dieses Verzeichnis auf "read only" gesetzt werden.

weitere Sicherungen

Das Programm erlaubt auch, Freigaben anderer Rechner zu sichern, die z.B. per "smbmount" oder NFS gemountet sind.

Dann ist es sehr sinnvoll, eine weitere Konfigurationsdatei in "/etc" anzulegen, bei der insbesondere eine eigene Log-Datei sowie eine eigene PID-Datei definiert wird. Sonst kann es passieren, dass der eine Sicherungsjob noch läuft, wenn der andere gestartet werden soll, und da verweigert "rsnapshot" (mit Recht) die Arbeit.

Wenn beispielsweise der Laptop "Thinkpad" gesichert werden soll, dann ist es sinnvoll,

/etc/rsnapthink.conf
/root/.mach-back/Think

anzulegen (überwiegend durch Kopieren der bisherigen Dateien) und die Cronjobs entsprechend der Arktur-Vorlage mit dem "mach-back"-Parameter "Think" aufzurufen.

 crontab -e -u root
40 6,16 * * *  /root/bin/mach-back hourly Think

sowie die "mach-back"-Dateien in

  • /etc/cron.daily
  • /etc/cron.weekly
  • /etc/cron.monthly
  • /etc/cron.yearly

ebenfalls passend zu ändern.

Kontrollen

Sobald mehr als 1 Sicherung angelegt ist, lassen sich die "hard links" mit "ls" oder dem "midnight commander" prüfen:

Beispiel: Datei "/srv/backup/Arktur/hourly.0/Wurzel/version"

ls -l /srv/backup/Arktur/hourly.0/Wurzel/version

zeigt im 2. Feld (nach den 10 Zeichen mit den Dateirechten) die Anzahl der "hard links". Dieser Wert ist nur bei Dateien interessant, bei Verzeichnissen hat er eine andere Bedeutung.

Weil die Datei "/version" sehr wahrscheinlich nur sehr selten geändert wird, sollte die dort angezeigte Zahl auch die Anzahl der Sicherungen sein.

Detailkontrollen

1. Probelauf:

       rsnapshot -t hourly

muss ohne Fehler (abgesehen von Sprachproblemen) durchlaufen

2. Probelauf:

in "/root/bin/mach-back" ganz am Ende

               rsnapshot $Intervall
               ->
               echo rsnapshot $Intervall

evtl. ganz oben: "# set -x" entkommentieren

               Start:
               /root/bin/mach-back hourly Arktur

muss ohne Fehlermeldungen (oder "exit") durchlaufen.

Wenn ok:

       in "/root/bin/mach-back" die Zeile "echo rsnapshot $Intervall"

zurückbauen,
ggfs. "set -x" wieder auskommentieren

Zeit- und Platzbedarf

Beispiel: Sicherung von etwa 40 GByte auf einem Rechner mit 500 MHz und 256 MB RAM:

Ausgabe von "rsnapshot du":

38G	/srv/backup/Arktur/hourly.0/
209M	/srv/backup/Arktur/hourly.1/
208M	/srv/backup/Arktur/daily.0/
226M	/srv/backup/Arktur/daily.1/
873M	/srv/backup/Arktur/daily.2/
256M	/srv/backup/Arktur/daily.3/
239M	/srv/backup/Arktur/daily.4/
204M	/srv/backup/Arktur/daily.5/
1,1G	/srv/backup/Arktur/daily.6/
791M	/srv/backup/Arktur/weekly.0/
1,1G	/srv/backup/Arktur/weekly.1/
538M	/srv/backup/Arktur/weekly.2/
485M	/srv/backup/Arktur/weekly.3/
1,7G	/srv/backup/Arktur/monthly.0/
4,0G	/srv/backup/Arktur/monthly.1/
3,2G	/srv/backup/Arktur/monthly.2/
488M	/srv/backup/Arktur/monthly.3/
838M	/srv/backup/Arktur/monthly.4/
2,3G	/srv/backup/Arktur/monthly.5/
503M	/srv/backup/Arktur/monthly.6/
341M	/srv/backup/Arktur/monthly.8/
2,9G	/srv/backup/Arktur/monthly.9/
3,8G	/srv/backup/Arktur/monthly.10/
1,7G	/srv/backup/Arktur/monthly.11/
2,1G	/srv/backup/Arktur/yearly.0/
68G	total

Zeitbedarf für 1 Sicherung: ca. 22 Minuten.
Das betrifft nur die "hourly.0"-Sicherung; alle anderen Versionen werden durch Umbenennen erzeugt.


Weitere Beispiele:

Pentium MMX 233 MHz 48 MB RAM 4 GB dauern 15 Minuten
Pentium III 1,1 GHz 512 MB RAM 18 GB dauern 8 Minuten

Sicherung kopieren

Es kann nötig sein, die bisherigen Sicherungen auf eine andere Platte oder eine andere Partition zu kopieren.

rsync

Oft reicht bereits

 Quelle=/srv/backup
 Ziel=/Pfad/zu/neuem/Backup
 mkdir -p $Ziel
 rsync -axH ${Quelle}/. $Ziel

cp

Eben habe ich mal wieder mit dem simplen "cp -a" gearbeitet, versuchsweise, und dabei gesehen, dass dieser Befehl jetzt (seit irgendeiner "cp"-Version) die Hardlinks brav mitnimmt, auch von einer Partition auf eine andere.

Und anscheinend funktioniert das inzwischen sogar beim Kopieren per "midnight commander".

Download

für Arktur angepasste Version von rsnapshot-noarch-*.tgz

Weblinks


Nachputzen

hardlink

Das bei Arktur mitgelieferte Programm "hardlink" reicht oft aus, um Lücken in der Hardlink-Kette zu schliessen; simpelster Aufruf:

cd /srv/backup
hardlink *

Das dauert natürlich eine ganze Weile; in dieser Zeit sollte kein weiteres Backup eingespielt werden.

Nutzen

Der obige Ablauf hat bei meiner Linux-Sicherung von etwa 40 GByte Rohdaten die vielen Backups von ca. 120 GByte auf ca. 80 GByte reduziert.

Wenn Windows-Rechner gesichert werden (was mit Hilfe von cifs oder smbfs geht), dann kann es sich bei den "monthly"-Sicherungen lohnen, die Option "-D 3600" hinzuzufügen, damit Datumsschwankungen wegen der Umstellung von Sommer- auf Winterzeit (oder zurück) aufgefangen werden.