Administratorhandbuch:Backup-Systeme

Diese Seite sollte nochmals überarbeitet werden. Eine Begründung befindet sich in der Regel unter Diskussion (oben).

Backup-Systeme

Notwendigkeit eines Backups

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.).

Forderungen an ein Backup

• Vollback versus inkrementelles Backup

...

Backupverfahren

Kopieren der Dateien auf eine andere Partition

Das einfachste Verfahren, das Sie zur Datensicherung anwenden können ist, einfach alle Dateien auf eine zweite Partition einer (USB-) Festplatte zu kopieren.

Kopieren der Serverfestplatte mit "dd"

Wenn es nur um das Absichern gegen Festplattenschäden geht, reicht u.U. das Kopieren auf eine zweite identische Festplatte.

Bandsicherung auf ein Streamerlaufwerk

Eine übliche Möglichkeit der Absicherung gegen Festplattenschäden oder Hacker ebenso wie Verlust des Servers durch Diebstahl, Feuer, etc. stellt eine regelmäßige Bandsicherung mit Verwahrung der Sicherungen an einem sicheren Ort (Tresor) dar.

"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

---

Alternativ:

   http://hullen.de/helmut/Arktur/rsnapshot.zip

Benutzt ebenfalls "rsnapshot" von Mike Rubel. Erlaubt die Sicherung auf

• Backup-Verzeichnis z.B. auf "/home"
• weitere Platte im Server
• per NFS angebundenes Verzeichnis auf einem anderen Rechner

Erlaubt auch die Sicherung von Windows-Freigaben, die per "smbfs" angebunden werden. (Helmut Hullen)

Synchronisation mit einen zweiten Server

Dieses Kapitel beschreibt "rsync" auf einen anderen Server bzw. das Klonen auf demselben Server per "rsync".

---

zurück | Hauptseite