Aus Linux-Magazin 04/2005

Aus dem Nähkästchen geplaudert: Backups

Jeder sorgfältige Admin erstellt Backups aller wichtigen Daten. Die Auswahl des richtigen Mediums ist nicht der einzige Knackpunkt. Benutzer wollen schließlich nach einem Crash so schnell wie möglich weiterarbeiten. Einige leicht verständliche Konzepte helfen bei der Strategiewahl.

Computerdaten gehen genau dann verloren, wenn man es am wenigsten gebrauchen kann. Doch mit der richtigen Backup-Strategie sind die verschwundenen Dateien schnell wieder auf die Festplatte zurückgespielt. Die Ursachen für Datenverluste sind vielfach. Häufiger Grund ist menschliches Versagen; ein »rm *« im falschen Verzeichnis passiert schnell. Gibt die Festplatte ihren Geist auf, droht gar ein Totalverlust. Ein Einbruch ins System stellt die Korrektheit der Daten zumindest so stark in Frage, dass der Admin die Maschine neu aufsetzen sollte.

Katastrophalen Datenverlusten durch Feuer- oder Wasserschäden ist nur durch offsite gelagerte Datenträger (in einem anderen Raum oder Gebäude) vorzubeugen, da solche Schäden oft größere Räumlichkeiten betreffen. Nicht zuletzt haben Backups eine wichtige Archivfunktion, gerade in Bereichen, in denen die Dokumentation des Arbeitsfortschritts nicht inhärent ist, etwa in Umgebungen ohne Versionskontrollsystem.

Vielfältige Auswahl

Bei der Strategie gibt es unterschiedliche Ansätze. Erste Alternative zur Vollsicherung ist das differenzielle Backup, bei dem stets der Unterschied zum vorherigen vollständigen Backup gespeichert wird. In den meisten Fällen setzen Admins jedoch auf inkrementelle Backups. Sie enthalten jeweils nur den Unterschied zum letzten inkrementellen oder vollständigen Backup. Das spart viel Platz auf den verwendeten Medien und somit Kosten, weshalb diese Strategie auch in fast allen Backup-Programmen vorgesehen ist.

Nachteil inkrementeller Backups: Der Restore, also die Rücksicherung der verlorenen Dateien, kostet erheblich mehr Zeit als bei der Vollsicherung. Außerdem muss der Admin eventuell die Medien wechseln, wenn kein entsprechender Roboter zur Verfügung steht. Abbildung 1 illustriert alle drei Methoden. Den völlig unterschiedlichen Anforderungen entsprechend haben sich mit der Zeit viele Arten von Backups entwickelt, die alle ihre Vor- und Nachteile haben. Tabelle 1 gibt einen kurzen Überblick über die gängigsten.

Klassisches und bei sehr großen Datenmengen bevorzugtes Medium ist das Magnetband, das bei niedrigen Basispreisen eine hohe Kapazität erreicht. Großer Nachteil ist die mäßige Geschwindigkeit. Bänder in Verbindung mit einem Bandwechselroboter sind ideal für vollautomatische Backups und Archivierung. Im Bereich von Heim- und kleinen Büroanwendungen sind Band-Lösungen aber meist zu teuer. Dort bieten sich Backups auf CD oder DVD, MO-Discs sowie internen oder externen Festplatten an. In größeren Umgebungen binden Administratoren ganze Festplattensammlungen übers Netzwerk an.

Offline, online, hot

Ein weiteres Kriterium für die passende Variante ist der Zugang zu den archivierten Dateien. Befindet sich die benötigte Datei auf einem Band im Wandschrank, ist das Medium offline. Jeder Zugriff erfordert menschliche Interaktion. Das hat auch Vorteile: Kompromittierung durch Angreifer übers Netzwerk ist ausgeschlossen. Ein Restore gerät allerdings zum Geduldspiel. Online-Backups hingegen befinden sich auf Medien, die ständig einen (auch automatisierten) Zugriff erlauben. Das spart Zeit und oft auch Geld, deckt aber einen viel geringeren Teil der Risiken ab.

So genannte Hot-Backups erzeugt ein System sehr oft oder ständig. Sie sichern allerdings nur gegen Schäden an der Hardware. Bedienungsfehler durch Nutzer und Admins finden ihren Weg auf das Backup-Medium ebenso schnell wie auf das zu sichernde Gerät selbst.

Archiv oder Einzeldateien

Ein alter Streit dreht sich um die Frage, ob Backups lieber aus Einzeldateien bestehen sollten oder ob komplexere Archivdateien besser geeignet sind, die eine Vielzahl von Dateien (oder alle auf dem gesicherten Medium enthaltenen) mit Metadaten und Prüfsummen kombinieren. Einzeldateien sind notfalls rasch wiederherstellbar. Hat das Backup-Medium nur einen Teildefekt, betrifft dies auch nur eine einzige Datei. Ist ein komplettes Archiv nicht mehr lesbar, sind viele Dateien auf einmal verloren.

Archivdateien enthalten dafür allerdings Features, die mit der Archivierung von Einzeldateien nicht erreichbar sind. Sie sichern neben dem bloßen Inhalt einer Datei auch Eigentums- und Zugriffsrechte sowie Zugriffszeiten. Selbst ein Backup von Gerätedateien aus »/dev/« ist möglich. Obendrein eignen sich Magnetbänder nur schlecht für das Archivieren massenhafter Einzeldateien; sie kommen besser mit wenigen sehr großen Files zurecht.

Manche Programme – darunter Tar und Cpio – bemühen sich um einen Mittelweg. Wird beispielsweise eine »cpio«-Datei beschädigt, betrifft der Schaden nur jene Datei, die an der entsprechenden Stelle gespeichert ist. Beim nächsten Datei-Ende-Marker synchronisiert sich das Programm wieder; die nachfolgenden Dateien lassen sich problemlos zurücksichern.

Komprimieren und verschlüsseln

Bei der Frage Einzeldatei oder Archiv ist auch zu entscheiden, ob die Backups komprimiert oder verschlüsselt abzuspeichern sind. Eine Resynchronisation funktioniert bei »cpio«-Dateien nur, wenn sie unkomprimiert sind. Verhindert ein Lesefehler die Dekompression des kompletten Archivs, streckt auch Cpio die Waffen.

Abbildung 1: Die drei gängigen Backup-Methoden. Der Admin benötigt beim Vollbackup zum Zurückspielen der Daten lediglich ein Image, bei der differenziellen Sicherung das letzte sowie das Vollbackup und bei der inkrementellen alle vorigen.

Abbildung 1: Die drei gängigen Backup-Methoden. Der Admin benötigt beim Vollbackup zum Zurückspielen der Daten lediglich ein Image, bei der differenziellen Sicherung das letzte sowie das Vollbackup und bei der inkrementellen alle vorigen.

Als Kompressionsverfahren für Backups ist das populäre Gzip daher nicht optimal. Es bricht bei Lesefehlern ab und hinterlässt damit potenziell einen größeren Flurschaden. Zcat dekomprimiert das Backup immerhin bis zum Lesefehler. Die Alternative Bzip2 komprimiert und dekomprimiert Files in Blöcke à maximal 900 KByte. Bei Lesefehlern geht nur ein einzelner Block verloren. Alle vorigen und nachfolgenden sind nicht von dem Fehler betroffen.

Verschlüsselung stellt den Admin vor ein ähnliches Dilemma. Abhängig vom angewandten Verfahren lassen sich bei einem kleinen Lesefehler große Teile des gesicherten Archivs nicht mehr entschlüsseln. Mögliche Abhilfe besteht darin, jede Datei des Backups einzeln zu komprimieren und zu verschlüsseln, was natürlich Ressourcen kostet. Das Werkzeug Afio als Ersatz für Cpio etwa beherrscht separate Verschlüsselung je archivierter Datei.

Beispiel Tape-Backup

Tapes sind beliebte und weit verbreitete Backup-Medien, die freilich mit einiger Vorsicht zu genießen sind. Vor allem billige DAT-Bänder haben oft isolierte Lesefehler, denen es durch geschickte Wahl der Software zu begegnen gilt. Gravierender ist aber, dass viele Kerneltreiber für Streamer die Bänder mit fertig formatierten Blöcken voraussetzen. Nicht jedes Bandgerät lässt sich also einfach als Ziel für »tar cpf« angeben.

Einfachste Abhilfe ist die Verwendung eines fertigen Backup-Systems wie Amanda[2], das unter einer BSD-Lizenz steht. Es übernimmt die Datensammlung von einer (fast) beliebigen Menge an Hosts und schreibt die Backups auf Magnetband. Amanda unterstützt eine Vielzahl von Unix-Varianten und es gibt entsprechende Clients für Microsoft Windows[3].

Sicherung übers Netzwerk

Das System basiert auf dem Client-Server-Modell (siehe Abbildung 2). Der Admin installiert auf jedem Host einen Amanda-Client. Der benötigt Leserechte für alle Dateien, die er an den Amanda-Server (Master) übertragen soll. Stellt der Master per UDP eine Anfrage an die Clients, schicken diese ihre Backups per TCP-Protokoll. Wahlweise nutzt Amanda die Programme Dump oder Tar, um die Archive zu erstellen.

Amanda beherrscht eine ausgefeilte Technik für das Scheduling aller Backups. Anhand von Informationen über verfügbare Bänder sowie über die gewünschte Frequenz vollständiger Backups teilt das Master-Programm die Sicherungen in komplette und inkrementelle Backups auf. Jeder Host wird so oft wie möglich gesichert, wobei mindestens die konfigurierte Anzahl der Backups vollständig ist. Die freien Plätze auf den Bändern füllt Amanda mit inkrementellen Sicherungen. Die Konfiguration des Systems ist wegen der ausgefeilten Möglichkeiten nicht ganz trivial. Zur Illustration sei hier auf eine Beispielkonfiguration verwiesen[4]. Obwohl Amanda auch bei kleineren Umgebungen sehr gut skaliert, eignet es sich vor allem für größere.

Abbildung 2: Das Backup-Programm Amanda sichert die Dateien von mehreren Rechnern. Dazu überträgt es die Daten per TCP, lagert sie gegebenenfalls auf der lokalen Platte des Masters zwischen und schreibt sie dann auf ein Magnetband.

Abbildung 2: Das Backup-Programm Amanda sichert die Dateien von mehreren Rechnern. Dazu überträgt es die Daten per TCP, lagert sie gegebenenfalls auf der lokalen Platte des Masters zwischen und schreibt sie dann auf ein Magnetband.

Tabelle 1:
Verschiedene Backup-Möglichkeiten

 
 

langlebig

zuverlässig

offsite

schnell

Verfügbarkeit

Magnetband

++

++

++

offline

CD/DVD

+

+

++

+

offline

MO

++

+

++

+

offline

Festplatte (intern)

++

online/hot

Festplatte (extern)

++

o

online

++: trifft voll zu; +: trifft zu; o: trifft bedingt zu, etwa
abhängig vom Medium; – : trifft nicht zu

CD-Backup

Privatanwender oder kleine Unternehmen sind möglicherweise mit einem einfachen Backup auf CD oder DVD besser bedient. Im Vergleich zu Magnetbändern sind die Medien äußerst günstig und haben eine relativ lange Lebensdauer. Ein Wermutstropfen ist die geringe Kapazität, die bei angestrebten Komplett- Backups Verrenkungen erfordert. Es bietet sich daher an, nur die wichtigsten Teile einer Installation zu sichern. Der Rest des Systems muss im Falle eines Schadens vom Distributionsmedium restaurierbar sein.

Listing 1 zeigt ein einfaches Backup-Skript, das alle Dateien zusätzlich durch einen Aufruf von »gpg« verschlüsselt und zudem eine einfache MD5-Prüfsumme abspeichert. Falls eine CD verloren geht, muss der Admin sich keine großen Sorgen machen, dass Unbefugte Zugriff auf die Daten bekommen. Varianten dieses Skripts lassen sich auch für den Einsatz auf MO-Medien oder externen Festplatten nutzen.

Listing 1: Einfaches
Backup-Skript

01 #!/bin/sh
02 
03 [ `id -u` -eq 0 ] || { echo 'Must be root to write a CD/DVD!'; exit; }
04 
05 TODAY=`date +%Y%m%d.%H%M`
06 MYKEY='0x598342d9'
07 
08 umask 022
09 mkdir -p /tmp/root/backup-$TODAY
10 
11 cd /
12 tar cf - etc home usr/local | 
13  gpg -v --homedir $HOME/.gnupg -e -r $MYKEY | 
14  tee /tmp/root/backup-$TODAY/backup-$TODAY.tar.gpg | 
15  md5sum -b >/tmp/root/backup-$TODAY/backup-$TODAY.tar.gpg.md5
16 
17 cd /tmp/root
18 mkisofs -r -pad -o backup.iso backup-$TODAY
19 cdrecord -v -eject -multi dev=0,0,0 -driveropts=burnproof -speed=24 -pad backup.iso
20 
21 rm -rf backup-$TODAY backup.iso

Alternativen

Bei den bislang geschilderten Backups handelt es sich um Offline-Backups, das heißt, der Admin entfernt das Medium aus dem Rechner und verwahrt es an einem sicheren Ort. Online-Backups speichern alle Daten auf einem separaten Rechner oder einem NAS-Gerät. Dazu bietet sich besonders Rsync an, das in Verbindung mit einer SSH-Installation als schnelle und bequeme Backup-Lösung dient.

Freilich ist das damit erstellte Backup nur so sicher wie das Netzwerk. Der bequeme Einsatz von Rsync setzt eigene SSH-Schlüssel oder einen Agent voraus. Mehr dazu in einer späteren Folge dieser Reihe. Die bereits erwähnten Hot-Backups zählen streng genommen gar nicht zu den echten Backup-Methoden. Da Kopien der Arbeitsdateien dabei live auf ein anderes Medium kopiert werden, landen auch sämtliche Fehler sofort darauf. Löscht ein Benutzer eines seiner Verzeichnisse, hat er kaum eine Chance, es wiederzubekommen.

Offensichtlich eignen sich Hot-Backups also nur dafür, vor Hardware-Ausfällen zu schützen. Sie ersetzen keinesfalls eine der oben genannten Backup-Strategien. Raid-Level 1 erzeugt ein solches Hot-Backup. Von jeder benutzten Festplattenpartition existiert eine identische Kopie auf einer anderen Festplatte im System. Die Daten landen nach jedem Schreibvorgang im System direkt auf beiden Platten. Ein Nebeneffekt von Raid 1 ist der Geschwindigkeitsgewinn beim Lesen, da die Daten von beiden Platten parallel kommen.

Kontrolle ist besser

Ob ein Backup-System gut ist, zeigt erst die Kontrolle der Daten, die auf dem Medium gelandet sind. Und die sind nicht immer identisch mit denen, die das Backup-Programm geschrieben hat. Dringend empfehlenswert ist daher, regelmäßig zu prüfen, ob die Sicherungen tatsächlich lesbar und korrekt sind. Schlimmste annehmbare Situation ist der Totalausfall eines Systems. Damit alle Mitarbeiter bald weiterarbeiten können, sollte der Restore schnell ablaufen. Die nötige Routine trainieren Admins mit regelmäßigen Übungen.

Im Vergleich zum Wiederherstellen einzelner Dateien treten beim Totalverlust zusätzliche Schwierigkeiten auf. Da das Betriebssystem selbst in diesem Fall nicht mehr funktionstüchtig ist, eignet sich dafür ein Rettungssystem. Es startet von CD oder einem externen Laufwerk, der Admin restauriert alle Daten von dort aus. Zu guter Letzt sei auf Sonderfälle verwiesen, die vom Admin zu beachten sind. So lassen sich permanent geöffnete Dateien, beispielsweise von Datenbanken, im laufenden Betrieb nur mit speziellen Techniken sichern, einen Überblick gibt[5]. (mwe)

Infos

[1] Afio: [http://directory.fsf.org/sysadmin/backup/afio.html]

[2] Amanda: [http://www.amanda.org]

[3] Amanda-Client für Windows: [http://sourceforge.net/projects/amanda-win32/]

[4] Vollständige Amanda-Konfiguration: [https://www.linux-magazin.de/Service/Listings/2005/04/Admin-Workshop/]

[5] Jens-Christoph Brendel, “Ohne Stillstand”: Linux-Magazin 03/05 , S. 40

LINUX-MAGAZIN KAUFEN
EINZELNE AUSGABE Print-Ausgaben Digitale Ausgaben
ABONNEMENTS Print-Abos Digitales Abo
TABLET & SMARTPHONE APPS Readly Logo
E-Mail Benachrichtigung
Benachrichtige mich zu:
0 Kommentare
Älteste
Neuste Beste Bewertung
Inline Feedbacks
Alle Kommentare anzeigen
Nach oben