Administratorhandbuch:BackupSnapshot
|
Archiv: Dieser Artikel beschreibt nicht die Funktionalität des derzeit aktuellen delixs-Servers. Er beschreibt ältere Schulserver-Funktionen und dient dem Zweck der Archivierung. |
"Vollautomatisches" Backup nach dem Snapshot-Verfahren
"Vollautomatisches" Backup nach dem 3-Generationen-Prinzip mit zusätzlich täglichen differentiellen Backups
Folgende Forderungen sollen mit der anschließend beschriebenen Lösung realisiert werden:
* es werden täglich die Änderungen gesichert, das bedeutet, es läßt sich immer der Stand des Vortages
rekonstruieren.
* die Sicherung erfolgt "vollautomatisch", sodaß solche Arbeiten wie Kassetten- oder CD-Wechsel entfallen.
* Der Administrator erhält nach jeder erfolgreichen Sicherung eine Mail, falls nicht ging etwas schief.
* Falls das Backup durch fehlerhafte Dateien (Viren, Würmer, Manipulationen) nicht mehr verwendbar ist,
kann auf eine ältere Version zurückgegriffen werden (3-Generationen-Prinzip)
* Die Backupzeiten sollten sich nicht mit Unterrichtszeiten überschneiden. Um akzeptable Zeiten und
Größen der Backups zu gewährleisten, sollte eine sinnvolle Kombination von Voll- und Differenzbackups
erfolgen
* Um bei Problemen wie Diebstahl, Feuer, Blitzschlag, Wasserschaden usw. das Backup nicht zu gefährden
besteht die Möglichkeit, das Backup an einen weit entfernten Ort abzulegen.
* Das Backup-System sollte möglichst unabhängig von einem speziellen Gerätetyp sein (Streamer),
damit das Backup auch auf einen anderen gleichwertig ausgestatteten PC relativ problemlos zurückgespielt
werden kann.
* zum Zwecke der Archivierung (kleine Systeme) sollte das Sichern auf CDs unterstützt werden.
* Die Backupmedien sollten auch bei täglicher Nutzung keinen spürbaren Verschleiß unterliegen.
Vorbereitung
* Arktur erhält eine weitere Festplatte (oder zumindest eine große Partition) * ein (weit entfernter) Windwos-PC erhält eine weitere sehr große Festplatte. * Dann werden die Scripte auf Arktur und der Windows-Client eingerichtet.
Die Scripte machen dann folgendes:
* automatisch jeden 1. eines Monats wird ein Backup der Ordner /etc /home /var/spool erstellt;
* auf Grund der 2GB-Begrenzung von Dateigrößen ist die Archivegröße auf jeweils 1,8 GB voreingestellt.
* vom 2. bis zum 31. eines jeden Monats werden die Daten gesichert, die sich geändert haben.
* diese Archive werden gezippt und übers LAN auf einen Windows-Client kopiert.
* auf dem Windows-Client werden drei Generationen (die letzten 3 Monate) von Backups aufbewahrt.
Im vierten Monat wird die älteste Sicherung gelöscht und durch eine neue ersetzt.
Installation:
1. Falls in Arktur noch nicht genügend Platz ist, eine Festplatte einbauen.
(ca. 2-3 mal so groß wie die ursprüngliche Arkturfestplatte.)
2. Mounten der Backupfestplatte an /bkup_ark (Achtung: Ordner muss genau /bkup_ark genannt werden)
und in die /etc/fstab einbinden.
3. die Scripte nach /bkup_ark/scripts kopieren
4. das Script "install.bkup" ausführen.
Hinweise zum Zurückspielen der Sicherungen
* Mounten der Backupfestplatte an /bkup_ark * Script 'entpackenvoll' (entpackt das letzte Vollbackup) * Script 'entpackendiff' (dort muss man angeben, bis zu welchen Tag man das dann entpacken möchte)
In Einzelfällen kann es sinnvoll sein, die Differenzbackup von einem bestimmten Zeitraum einzuspielen. Dazu kann das Script 'entpackendiff _von_bis' genutzt werden.
"Vollautomatisches" Backup nach dem Snapshot-Verfahren
Diese soeben beschriebene Lösung war mehrere Jahre im Einsatz und erfüllten die gestellten Forderungen, aber es ergaben sich durchaus Situationen, denen diese Konstruktion nicht bzw. nur schlecht gerecht wurde.
* falls ein Anwender mal auf eine Datei zugreifen wollte, die vor 25 Tagen in dem Zustand war,
den er jetzt brauchte, war der Aufwand für den Zugriff einfach extrem groß. Außerdem konnte
dieser Zugriff nur vom Admin geleistet werden. Damit fiel die Nutzung für diesen Zweck komplett
aus, obwohl er theoretisch möglich war.
* Eine Kontrolle auf Korrektheit der Daten war nur möglich, wenn man einen Server oder zumindest Teile davon neu aufbaute.
Wenn man nicht einen entsprechenden Rechner zur Hand hat, mußte man demzufolge den Server
plattmachen - ein Irrsinn. Oder man hatte ein ungetestetes Backup - ein Himmelfahrtskommando.
Demzufolge gab es zwei neue zusätzliche Forderungen:
* Der Anwender sollte jederzeit selbst auf seine Daten Zugriff haben. * Man sollte über die Korrektheit/Brauchbarkeit des Backups keine Zweifel haben müssen.
Dadurch, das jeder Anwender praktisch zu jeder Zeit selbst Zugriff auf seine alten Daten erhält, muß eine sonst kaum beachtete weitere Eigenschaft eines Backups bewußt erfüllt werden:
* Die Backupdaten dürfen auch nicht versehentlich durch den Anwender geändert werden können,
müssen also "readonly" bereitgestellt werden.
Diese Forderungen von der Variante nach dem 3-Generationen-Prinzip und diesen neuen Forderungen werden durch eine auf "rsync" basierende Lösung nach dem Snapshot-Prinzip erfüllt. Grundlage einer speziellen Lösung für Arktur war ein Hinweis auf http://linuxwiki.de/rsync_2fSnapshotBackups.
Das für Arktur bereitgestellte Script wurde zusätzlich dahingehend modifiziert, das sich entsprechend des zur Verfügung stehenden Speicherplatzes die Anzahl der Vollbackups "dynamisch" anpaßt.
Das bedeutet, wenn man eine Festplatte von 30 GB hat und die Backupplatte hat 80 GB, dann werden beispielsweise für 30 Tage Vollbackups oder wenn die geänderten Datenmengen pro Tag größer sind, vielleicht nur 25 komplette Vollbackups auf dieser 80 GB-Platte bereitgestellt (bei fast voller 30 GB Platte). Weiter: durch diese Lösung ist gewährleistet, das jeder Nutzer für jeden beliebigen Tag (entsprechend der Anzahl der Backups) auf seine Daten zugreifen kann, natürlich readonly und nur auf _seine_ Daten - natürlich ohne den Admin zu behelligen. Installation:
1. Backupplatte einbauen und formatieren 2. Backupplatte nach /root/snapshot mounten 3. in /etc/fstab folgende Zeile eintragen: /dev/hda1 /root/snapshot ext3 1 2 4. Die Variablen unter ## ---Vom User zu editierende Variablen:--- anpassen. 5. neu booten
Anmerkung: Bei diesem Verfahren werden auch das gesamte "/proc"-Verzeichnis, das "/tmp"-Verzeichnis, der Squid-Cache, alle Backup-Dateien usw. gesichert. Das dürfte nicht sonderlich sinnvoll sein.
Wenn schon die mögliche - und sehr sinnvolle - Option "nur 1 Dateisystem" nicht genutzt wird, dann sollte eine ausführliche "exclude"-Datei angefertigt werden.
Sonst läuft - vor allem wegen "core" und Squid-Cache - recht schnell die Sicherungs-Platte voll.
Originaldokumentation im PDF-Format
restore_v1.0.tar.gz, das Script zur Wiederherstellung