Administratorhandbuch:Backup-Systeme: Unterschied zwischen den Versionen

Aus Delixs
Zur Navigation springen Zur Suche springen
(Teile ausgelagert)
(Strukturvorschlag fertig)
Zeile 1: Zeile 1:
__NOTOC__
__NOTOC__
{{Uberarbeiten}}
{{Uberarbeiten}}


== Backup-Systeme ==
== Backup-Systeme ==
Zeile 14: Zeile 15:
=== Forderungen an ein Backup ===
=== Forderungen an ein Backup ===


* Vollback versus inkrementelles Backup
* es werden täglich die Änderungen gesichert, das bedeutet, es lässt sich immer der Stand des Vortages rekonstruieren.
...
* die Sicherung erfolgt "vollautomatisch", sodass 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ück gespielt 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.
     


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


=== [[Administratorhandbuch:BackupClonen|Kopieren der Serverfestplatte mit "dd"]] ===
==== [[Administratorhandbuch:BackupClonen|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.
Wenn es nur um das Absichern gegen Festplattenschäden geht, reicht u.U. das Kopieren auf eine zweite identische Festplatte.
Zeile 31: Zeile 40:
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.
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 ===
=== [[Administratorhandbuch:BackupSnapshot|"Vollautomatisches" Backup]] ===
 
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.
 
=== [[Administratorhandbuch:BackupSnapshot|"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.
* "Vollautomatisches" Backup nach dem 3-Generationen-Prinzip mit zusätzlich täglichen differentiellen Backups
 
* "Vollautomatisches" Backup nach dem Snapshot-Verfahren
    * 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
<hr width="80%">
 
Alternativ:
    http://hullen.de/helmut/Arktur/rsnapshot.zip
Benutzt ebenfalls "rsnapshot" von Mike Rubel.
Erlaubt die Sicherung auf
<ul>
<li>Backup-Verzeichnis z.B. auf "/home"
<li>weitere Platte im Server
<li>per NFS angebundenes Verzeichnis auf einem anderen Rechner
</ul>
Erlaubt auch die Sicherung von Windows-Freigaben, die per "smbfs" angebunden werden.
(Helmut Hullen)


==== [[Administratorhandbuch:Backup_rsync|Synchronisation mit einen zweiten Server]] ====
==== [[Administratorhandbuch:Backup_rsync|Synchronisation mit einen zweiten Server]] ====


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


----
----
<div align="right">[[Administratorhandbuch|zurück]] | [[Hauptseite]]</div>
<div align="right">[[Administratorhandbuch|zurück]] | [[Hauptseite]]</div>

Version vom 3. Januar 2006, 20:59 Uhr

Uberarbeiten 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

  • es werden täglich die Änderungen gesichert, das bedeutet, es lässt sich immer der Stand des Vortages rekonstruieren.
  • die Sicherung erfolgt "vollautomatisch", sodass 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ück gespielt 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.


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

  • "Vollautomatisches" Backup nach dem 3-Generationen-Prinzip mit zusätzlich täglichen differentiellen Backups
  • "Vollautomatisches" Backup nach dem Snapshot-Verfahren

Synchronisation mit einen zweiten Server

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



zurück | Hauptseite