Zusatzprogramme:rsnapshot
Aus Arktur
vielstufiges Backup mit rsnapshot
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 und Arktur 3.6 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:
- Verzeichnis auf einer Partition des laufenden Systems, z.B. "/home/backup"
- Partition auf einer weiteren Festplatte (intern oder extern) des zu sichernden Rechners
- 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/hda", gesichert werden soll nach "/dev/hdd4"
Die Partition "/dev/hdd4" muss natürlich existieren und formatiert sein (am besten mit dem Typ "ext3").
Steuerdatei "/root/.mach-back/Arktur"
-
Typ=disk
-
Ziel=/dev/hdd4
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.
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.
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/Arkturwurzel/version"
ls -l /srv/backup/Arktur/hourly.0/Arkturwurzel/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. Dann ist der pure "cp"-Befehl oder das Kopieren mit dem "midnight commander" mehr als unzweckmässig: alle "hard links" werden ignoriert, jede Sicherung wird in voller Grösse kopiert (und dann ist die Zielpartition rasch vollgelaufen).
rsnapshot-copy
"rsnapshot-copy" ist ein Skript von Matt McCutchen, das beim Arktur-rsnapshot-Paket sowie in den neueren "rsnapshot"-Paketen mitgeliefert wird.
Wenn eine Sicherung auf "/srv/backup/Arktur" liegt und nach "/mnt/Kopie/Arktur" kopiert werden soll:
cd /srv/backup mkdir -p /mnt/Kopie/Arktur rsnapshot-copy -a Arktur /mnt/Kopie/Arktur
Die Sicherungen liegen bei diesem Beispiel in "srv/backup/Arktur/hourly.0" usw.
Das dauert natürlich eine Weile. Insbesondere die "hourly"-Sicherung sollte in dieser Zeit nicht geändert werden.
rsync
Oft reicht bereits
Quelle=/srv/backup
Ziel=/Pfad/zu/neuem/Backup
mkdir -p $Ziel
rsync -axH ${Quelle}/. $Ziel
snapcopy
Das Programm stammt aus dem "Snapback2"-Paket von Mike Heins, funktioniert aber auch unter "rsnapshot".
Wenn die Sicherungen z.B. in "/srv/backup/hourly.0" usw. liegen und nach "/mnt/Platte2/backup" kopiert werden sollen, dann lautet der Aufruf
cd /srv mkdir -p /mnt/Platte2 snapcopy -v backup /mnt/Platte2
Dann dauert es eine Weile, bis "snapcopy" sich die nötigen Informationen geholt hat; Geduld!
Es kann sein, dass der Rechner sich bei diesem Programm bei zu grossen Datenmengen verschluckt.
Download
für Arktur angepasste Version von rsnapshot-noarch-*.tgz
Weblinks
freedup
freedup kann mit "rsnapshot" angelegte Sicherungen weiter komprimieren, indem es weitere identische Dateien sucht und ggfs. ebenfalls per "hard link" verknüpft.
Ablauf
Annahme: die Sicherungen hourly.*, daily.* usw. liegen unterhalb von "/srv/backup"
kurz nach Abschluss einer "hourly"-Sicherung:
cd /srv/backup freedup -0Tfalk# hourly.?
Das dauert eine Weile; wenn die Konsole wieder freigegeben werden soll: (stattdessen)
freedup -0Tfalk# hourly.? & disown
oder
echo "freedup -0Tfalk# hourly.?" | at now + 1 minutes
Nach mindestens 24 Stunden (wenn mindestens eine der ehemals "hourly"-Sicherungen nach "daily.0" umbenannt worden ist)
freedup -0Tfalk# daily.?
In der folgenden Woche (wenn mindestens eine der "daily"-Sicherungen nach "weekly.0" umbenannt worden ist)
freedup -0Tfalk# weekly.?
Beim Komprimieren der "monthly"-Sicherungen (bis zu 12 Pakete) kann es sein, dass "freedup" Speicherprobleme bekommt. Dann sollte eine Einschränkung auf Dateien mit (z.B.) mindestens 5 kByte helfen:
freedup -0Tfalk# -o "-size +5000" monthly.*
Jährliche Sicherung: es mag zu lange dauern, bis "monthly.12" nach "yearly.0" umbenannt worden ist, deshalb dürfte sich dafür lohnen,
freedup -0Tfalk# monthly.12 yearly.?
aufzurufen - damit wird definiert, dass sich die "yearly"-Sicherungen an "monthly.12" zu orientieren haben.
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.
