Administratorhandbuch:Backup-Systeme
|
Diese Seite sollte nochmals überarbeitet werden. Eine Begründung befindet sich in der Regel unter Diskussion (oben). |
Backup-Systeme
Ein Schulnetz unterscheidet sich häufig von einem professionell betreuten Firmennetz auch dadurch, dass beim Schulnetz kein aktuelles Backup zur Verfügung steht. Aber durch die immer stärker geforderte Medienkompetenz, den wachsenden Umfang an planmäßigen Unterricht in den Computerkabinetten (Informatik, Medienkunde, ITG, usw.), den immer häufigeren Einsatz der PC-Technik im Fachunterricht sowie den selbstverständlichen Einsatz der Computer bei der Erstellung und Präsentation von Projekten, Hausarbeiten, Schülerzeitungen, usw. wird die ständige Verfügbarkeit des Schulnetzes einschließlich der bereitgestellten Daten erwartet bzw. vorausgesetzt.
Demzufolge sollte man schon bei der Einrichtung eines Schulnetzes sich Gedanken über die Anforderungen und Möglichkeiten der Erstellung bzw. Einrichtung von Backups machen.
Deshalb sollte man gut abwägen, welche Probleme man durch ein Backup in den Griff bekommen will und für welche Probleme man das Risiko in Kauf nimmt. Solche Aspekte können Festplattenschäden, Blitzschlag, Diebstahl, Hochwasser, Feuer, Viren, Rootkits, Hackerangriff, usw. sein. Ebenso ist vorher zu überlegen, welcher Aufwand für die Bereitstellung eines aktuellen Backups notwendig ist bzw. was für Probleme vorher geklärt werden müssen (welche Hardware, welche Datenträger, tagesaktuell, notwendige Arbeiten wie Bänderwechsel oder verschließen im Tresor, wie bekommt man einen Havariefall möglichst schnell mit, wie können die gesicherten Daten bzw. Teile davon schnell bereitgestellt werden, usw.).
Sicherung bestimmter Verzeichnisse (/etc, /home) in eine Datei
Mit der folgenden Anweisung auf der Kommandozeile wird der Inhalt von /etc in die Datei Arktur-etc.tar.gz gesichert. Analog geht das natürlich auch für /home.
tar cvzf /pfad/zum/Verzeichnis/Arktur-etc.tar.gz /etc
Kopieren der Serverfestplatte mit "dd"
Wenn es nur um das Absichern gegen Festplattenschäden geht, reicht u.U. das Kopieren auf identische Festplatten. Mit
dd if=/dev/hda of=/dev/hdc
wird von hda nach hdc kopiert. 20 Gigabyte in ca. 2 Stunden. Diesen Befehl kann man mit dem mc in etc/crontab mit der Uhrzeit eintragen. Falls mal ein Absturz mit Datenverlust vorkommt oder der Rechner lässt sich nicht mehr starten, werden die beiden Festplattenkabel getauscht und der Rechner mit der Kopie der letzten Nacht hochgefahren. Dann ist die alte Festplatte künftig die Sicherung.
Beispiel für eine Bandsicherung
Eine übliche Möglichkeit der Absicherung gegen Festplattenschäden bzw. Hacker ebenso wie Verlust des Server durch Diebstahl, Feuer, etc. stellt eine regelmäßige Bandsicherung mit Verwahrung der Sicherungen an einem sicheren Ort (Tresor) dar. Hier eine Beschreibung mit Hewlett-Packard DDS1 HP 35480a Bandlaufwerk i.V.m. Adaptec 2940 UA SCSI 2 Adapter in einem Arktur V3.0t. Dabei wird einmal pro Tag das Band getauscht. meine Lösung:
Das Bandlaufwerk wird in unserem Arktur mit /dev/nst0 angesprochen. Mit dem Befehl mt -f /dev/nst0 rewind (oder forward) kann es zurück- oder vorgespult werden.
Das Bandlaufwerk wird mit dem folgenden Eintrag in /etc/profile fest eingebunden:
TAPE=/dev/nst0 TAPE export
Dann muss bei mt oder tar nicht mehr das -f /dev/nst0 angegeben werden. Konfiguration der Datensicherung
Es sollen die Verzeichnisse /etc und /home gesichert werden.
Die Sicherung von /etc erfolgt mit dem Befehl
tar czf /home/etc.tgz /etc/* # Hier nicht aufs Band, sondern in das Archiv
# etc.tgz im Verzeichnis /home
Die Sicherung von /home erfolgt mit dem Befehl
tar cz /home/* #direkt aufs Band
Zur automatischen Datensicherung über den cron-daemon sind die Befehle mit crontab -e einzutragen. Ich benutze eine Masterdatei 'crontext' und die mit "crontab crontext" aktiviert wird. In der 'crontext' editiere ich
TAPE=/dev/nst0 # gibt den Pfad für den cron-daemon zum
# Bandlaufwerk, weil der m.E. mit
# /etc/profile nichts anfangen kann
58 22 * * 1-5 tar czf /home/etc.tgz /etc/* # sichert um 22:58 Uhr mo-fr /etc nach /home/etc.tgz mit gzip komprimiert 28 4 * * 1-5 tar cz /home/* # sichert um 4:28 Uhr mo-fr /home aufs Band mit gzip kompimiert 55 6 * * 1-5 mt rewind # spult um 6:55 Uhr mo-fr das Band an den Anfang zurück
mit crontab crontext wird das Ganze aktiviert.
Die Uhrzeiten sind vom Datenumfang abhängig. 1GB = 1h Rücksicherung/Restaurierung
Diese Syntax geht davon aus, dass im Verzeichnis /home das auf dem Band gesicherte /home als Unterverzeichnis angelegt wird.
cd /home tar xvpz # restauriert vom Band das Verzeichnis /home in /home/home cp -a /home/home/* # kopiert den Inhalt von /home/home nach /home cd .. cd /etc # wechselt nach /etc
tar xvzpf /home/etc.tgz # restauriert /etc aus dem Archiv /home/etc.tgz
Damit kann Arktur nach einem Totalausfall i.V.m. der Originalsoftware im vorigen Zustand wiederhergestellt werden.
"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.
Alternativ:
http://hullen.de/helmut/Arktur/rsnapshot.zip
Helmut Hullen)
Originaldokumentation im PDF-Format
restore_v1.0.tar.gz, das Script zur Wiederherstellung
rsync
Prima Anleitung: Hier können wir uns belesen...
http://www.linux-schulserver.de/Sections-article9-p3.phtml
root auf Server A platziert seinen key auf Server B => Fortan kann root von Server A sich bei Server B ohne Passwort einloggen. Rsync nutzt mit der Option "-e ssh" SSH als "Transportschicht". Wenn du auf Server A den ssh-agent einrichtest, dann cached der das Passwort für den SSH-Key und du bist auch innerhalb deines Netzes auf der sicheren Seite. Aber richte SSH erst mal ohne Passwort ein und setze - wenn alles klappt - mit dem Befehl "ssh-keygen -p" ein Passwort für den SSH-Schlüssel und richte den SSH-Agent ein.