Datenbackup per Shellscript
Autor: Johannes Pössinger
Backup ist was für Weicheier und Schattenparker - solange alles gut geht. Jeder, dessen IDE-Platte im Server den Dauerbetrieb mal nicht mehr ausgehalten hat und der miterleben musste, wie sämtliche mühsam zusammengetragenen Bits ins Nirvana geschickt wurden, hat aber auch schon allen nicht gemachten Backups laut nachgeweint.
Aber auch die kleinen Unbilden des Userlebens können einen Backup-Einsetzer nicht mehr allzu schwer schockieren. Wer hat sich nicht schon mal unbeabsichtigt eine Datei überschrieben, gelöscht, zerstört, wer hat nicht schon einmal festgestellt, dass die vorletzte Version der Diplom-, Haus- oder Projektarbeit eigentlich viel besser war als die aktuelle... Mit der richtigen Backup-Strategie sind all diese Fehler leicht wieder auszubügeln.
Wir sprechen hier nicht von der Sicherung einer kompletten Installation - für so etwas gibt es die Möglichkeit, ein Image von einer Partition oder einer ganzen Platte zu erstellen - sondern von der Sicherung einzelner Verzeichnisse. Für diesen Zweck hat tecneeq (der hier hin und wieder unter seinem Pseudonym Karsten Kruse auftaucht) ein Shell-Script namens tecback geschrieben, das in wenigen Minuten eingerichtet ist und von da an seinen Dienst unauffällig und zuverlässig mit vorhandenen Bordmitteln wie tar und find versieht.
Backup-Strategien gibt es wie Sand am Meer, vom einfachen "Hin und wieder das eine oder andere auf CD brennen" bis hin zu wissenschaftlich und mathematisch fundierten, in dicken Wälzern dokumentierten Mammutsystemen ist alles denkbar. Für tecback gilt eine sehr einfache und wirkungsvolle Strategie: Jeder bestimmt selbst, was zu welchem Zeitpunkt gesichert werden soll und wie lange die Sicherung aufbewahrt wird.
Zwei Begriffe sollen hier kurz erläutert werden: Full-Backup und Incrementelles Backup. Ein Full-Backup sichert sämtliche Dateien in den ausgewählten Verzeichnissen. Ein Incrementelles Backup sichert nur diejenigen Dateien, die seit dem letzten Full bzw. dem letzten Incremental verändert oder neu erstellt wurden. Mit der richtigen Mischung aus Fulls und Incrementals hat man also die Gewähr, dass alle Dateien in ihrem aktuellen Stand gesichert werden, ohne unnötig Ressourcen zu erschwenden.
Der Nachteil dieser Strategie besteht darin, dass eine eventuelle Wiederherstellung von mehreren Dateien oder Verzeichnissen mit jedem Incremental etwas komplizierter wird, da je nach Erstellungs- oder Änderungszeitpunkt die Dateien sich in verschiedenen Sicherungsstadien und Sicherungsverzeichnissen befinden können. In diesem Fall muss man also gegebenenfalls ein komplettes Fullbackup und mehrere Incrementals zurück spielen um zu dem gewünschten Ergebnis zu kommen.
Um die Anzahl der vorhandenen Backups übersichtlich zu halten und einen Restore möglichst unkompliziert vornehmen zu können, werden also nicht nach einem Full-Backup einfach täglich Incrementals gefahren. Ein Full hat ein Verfallsdatum. Ist dieses Datum erreicht, werden das Full und die dazugehörigen Incrementals gelöscht. Selbstverständlich wurde vorher ein neues Full gesichert.
In tecback läßt sich die Aufbewahrungszeit der Fulls einstellen. Das Script führt ein Backup immer dann als Full aus, wenn es entweder kein gültiges vorfindet oder wenn der jeweilige Monatserste ist. Somit lassen sich mehrere Generationen an Full-Backups vorhalten und es ist möglich, Daten tagesgenau zu restaurieren.
So - nun aber genug gequackelt, jetzt geht's an die "Installation". Unter download/tecback holst du dir das Skript, das sollte selbst mit einem 24er Modem noch sehr schnell erledigt sein. Nach dem Download wird tecback in das Verzeichnis kopiert, in dem die Backups aufbewahrt werden sollen.
Hierzu noch eine Anmerkung: Wer sich völlig sicher ist, dass ihm höchstens mal ein Versehen passiert und er unbeabsichtigt einige Daten löscht, der kann die Backups auf der gleichen Platte lagern wie die Originale, die so genannten "Online-Daten". Damit sind aber im Falle eines Hardware-Defektes auch die Backups futsch. Es empfiehlt sich also, das Backupverzeichnis auf einer anderen, idealerweise einer eigenen Platte anzulegen.
Wie auch immer, ich lege mir (als root) ein Verzeichnis namens /_backup (oder eben /home/_backup, /srv/_backup ...) an:
mkdir /_backup
In dieses Verzeichnis verschiebe ich das Skript tecback und mache es ausführbar:
mv tecback /_backup/ chmod 700 /_backup/tecback
Die Konfiguration erklärt tecneeq in den Kommentaren zu seinem Skript am besten selbst:
# tecback - 01/2003 Karsten Kruse www.tecneeq.de # # Installation: # 1) Leg das Script dort ab wo du viel Platz hast und mach es ausfuerbar # mit ,,chmod 700 tecback''. # # 2) Weiter unten sind einige Einstellungen die du anpassen solltest: # * holdbackup - Das Alter in Tagen des aeltesten Backups das du # behalten willst # * tar - Voller Pfad zu einem GNU-tar (mindestens Version # 1.13.25) # * basedir - Der volle Pfad in dem dieses Script liegt # * include - Verzeichnisse die gesichert werden sollen # * exclude - Verzeichnisse die nicht gesichert werden sollen # * compression - Mit welchem Kompressionsprogramm soll das Backup # komprimiert werden? bz2=bzip2 gz=gzip keine=nichts # # 3) Von Hand starten um sicherzustellen das alles klappt: ,,/pfad/tecback'' # # 4) Einen Cronjob anlegen, z.b. so: 10 2 * * * nice /pfad/tecback #
Alle Einstellungen sind also in dem Skript selbst zu machen. Dazu öffnest du die Datei mit einem Editor, ich verwende den vom Midnight Commander:
mcedit /_backup/tecback
Etwas mehr Details:
holdbackup:
Der hier einzutragende Wert ist natürlich sehr stark vom Userverhalten und der Datenmenge abhängig. Je
größer dieser Wert ist, desto länger lassen sich Änderungen zurückverfolgen und desto sicherer kann man
beliebige Versionen zurück holen, allerdings auf Kosten von sehr viel Speicherplatz. Der vorgeschlagene
Wert von 62 Tagen sollte für die allermeisten Anwender richtig sein. Wer nur kurzfristig sichern will kann
ihn auf bis zu 32 Tage herunter schrauben, damit ist die Existenz mehrerer Fulls noch immer gesichert.
tar:
Wo findet das Skript das Archivierungsprogramm tar? Das kannst du mit dem Befehl which tar
oder type tar herausbekommen. Bei mir ergibt das z.B. /bin/tar.
basedir:
Darüber habe ich weiter oben bereits philosophiert.
include:
Hier werden die kompletten Pfade der Verzeichnisse eingetragen die gesichert werden sollen - getrennt durch
ein Leerzeichen. Es lohnt sich durchaus, über diesen Eintrag ein paar Minuten zu meditieren. tecback ist
bestens geeignet zur Sicherung von Datenbeständen die sich häufig ändern. Es macht keinen Sinn, die mehr
oder weniger statischen Systemdateien hier aufzuführen, dafür ist ein Image besser geeignet. Auch z.B. die
MP3-Sammlung, die Fotos der Digicam usw... sind für tecback eine Nummer zu groß und sollten besser auf CD
gebrannt werden. Der Grund hierfür liegt nicht am Skript selbst sondern an der zugrunde liegenden
Backup-Strategie. Welchen Sinn macht es, riesige Datenmengen einmal monatlich voll zu sichern, wenn sich an
den Daten selbst nichts ändert? Auch diejenigen die hier z.B. /var/log eintragen werden sich über ihre
täglichen Incrementals wundern. Da sich die Log-Dateien naturgemäß täglich ändern, werden sie auch täglich
gesichert, was zu großen Incrementals führt. Das gleiche gilt z.B. für Mail-Spools. Wer viele Mails
aufbewahrt, der hat auch einen täglichen großen Incremental-Brocken zu erwarten, da die Spools als einzelne
Dateien vorliegen und mit jeder neuen Mail natürlich geändert werden. Wie gesagt, das Skript an sich
schafft alles - unabhängig von der Datenmenge, letztlich entscheidest du selbst, was du täglich gesichert
haben möchtest.
exclude:
Ein äußerst hilfreicher Schalter. Wenn du z.B. dein $HOME sicherst wird eben alles unterhalb dieses Pfades
mitgesichert. Ich habe z.B. ein Verzeichnis /home/hannes/install, in dem jede Menge heruntergeladene
Software liegt, die normalerweise bereits veraltet ist bevor sie zum ersten mal ein Full-Backup erlebt.
Dieses Verzeichnis gehört also eindeutig in die exclude-Liste.
compression:
Hier kann eingestellt werden, welche Kompressionsmethode verwendet werden soll. bzip2 komprimiert am
stärksten, belastet allerdings die CPU sehr. Wenn du also Daten auf deinem betagten Server sichern willst,
ist bzip2 nicht unbedingt die erste Wahl, für so etwas reicht gzip. Wer seinen Backups eine eigene Platte
spendiert, kann unter Umständen ganz auf Kompression verzichten, was wesentliche Zeitvorteile beim Backup
wie auch beim Restore bringt.
Wenn alles soweit eingerichtet ist, sollte tecback zunächst manuell gestartet werden um sicherzustellen, dass man mit der Konfiguration auch die gewünschten Ergebnisse erzielt. tecback sollte root ausgeführt werden, um keine Probleme mit Zugriffsrechten zu bekommen:
/_backup/tecback
Nach dem ersten Durchlauf befindet sich unterhalb deines _backup Verzeichnisses ein neues Verzeichnis namens archive. In diesem Verzeichnis befindet sich eine leere Datei namens .stampfile, die das Skript für seine weiteren Jobs benötigt. Außerdem gibt es eine Datei, die etwa folgendermaßen aussieht:
-rw-r--r-- 1 root root 363800018 May 14 23:56 server_full_1052948114.tar.gz
Das ist das erste Full-Backup.
Abschließend wird ein Cron-Job eingerichtet, der einmal täglich das Backup-Script aufruft. Wie man sowas macht findest du in der Cron-Anleitung die es auch im Newbie-Net zu bewundern gibt.
Hier ein Beispiel für einen Cronjob der jeden Tag um 4:20 Uhr nachts startet:
20 4 * * * nice /_backup/tecback
Wichtig ist, den Cronjob als root laufen zu lassen, damit es keine Probleme mit Zugriffsrechten gibt. Da das Backup wegen der Kompression sehr CPU-lastig ist, sollte tecback im nice-mode gestartet werden.
Damit verhält sich das Skript und alle aufgerufenen Jobs bescheiden und überlässt anderen Prozessen die CPU-Zeit falls diese sie dringender brauchen.
Wird während des Backups eine zu sichernde Datei gerade geändert, kommt es zu einer Fehlermeldung und die Datei kann nicht gesichert werden. An und für sich ist das kein Beinbruch, kann aber ärgerliche Folgen haben. So ist beispielsweise wie gesagt ein Mailspool eine einzelne Datei, die vom Backup nicht erfasst wird, wenn gerade eine Mail eintrudelt. Hier sollte also der Cronjob zu einem Zeitpunkt laufen, an dem mit hoher Wahrscheinlichkeit keine Mails eintreffen.
Etwas schwieriger ist die Sicherung von z.B. MySQL-Datenbanken. Erfolgt zeitgleich zum Backup gerade ein Zugriff auf die Datenbank, ist zum einen das Backup wertlos, zum andern kann unter gewissen Umständen Schaden an der betroffenen Tabelle entstehen. Datenbankdateien sollten also grundsätzlich vom Backup ausgenommen werden. Um sie dennoch sichern zu können, kann per Cronjob kurz vor der Ausführung von tecback mittels mysqldump eine Sicherung der Datenbanken in ein Verzeichnis erfolgen, das von tecback gesichert wird.
"Mir nützen aber monatliche Fulls nicht, der Backup-Zyklus müßte besser einstellbar sein" - so eine häufiger gehörte Kritik. Es ist keine allzu große Mühe, mit Hilfe von tecback auch in anderen Zyklen Full- und Incrementalbackups zu fahren. Die Option holdbackup eignet sich dazu, eine kürzere Aufbewahrungszeit einzustellen. Ein wöchentliches Fullbackup läßt sich z.B. dadurch erreichen, daß man sich einen weiteren Cronjob einrichtet, der kurz vor dem gewünschten Backuptermin wöchentlich das .stampfile löscht, das sich im Verzeichnis archive befindet. Findet tecback dieses File nicht mehr vor, wird ein Fullbackup gefahren.
Jetzt hast du also bald eine stattliche Sammlung an Full- und Incremental-Backups. Was aber, wenn du jetzt tatsächlich mal auf die Sicherungen zurückgreifen mußt? Falls du aufgrund eines System-Crashes alles wiederherstellen mußt, kannst du das mit folgendem tar-Befehl machen:
cd / ; tar xjpf
Damit wird alles zurückgeschrieben was beim Full gesichert wurde. Auch dieser Befehl muß als root ausgeführt werden, wenn Dateien gesichert worden sind auf die ein normaler User keinen Zugriff hat. Anschließend werden auf die gleiche Weise alle Incrementals "behandelt" . Damit ist der Status vom Datum des letzten Incrementals wieder hergestellt.
Normalerweise möchte man jedoch eher eine oder mehrere Dateien, oder ein Verzeichnis restoren, während der Rest unangetastet bleiben soll. In diesem Fall leistet der Midnight Commander mc gute Dienste, da er den Inhalt selbst komprimierter tar-Archive darstellen kann. mc starten, das gewünschte Backup-File auswählen, Enter drücken und je nach Kompression eine Weile warten. Wird der Inhalt dargestellt, kannst du ganz einfach die gewünschten Dateien auswählen und sie an ihren Ursprungsort zurück kopieren.
Wer z.B. ein kleines Netzwerk betreibt und öfters Restores machen muss, kann sich natürlich auch etwa mit php oder perl ein Browser-Frontend schreiben, das die Restores vielleicht noch etwas komfortabler ermöglicht. Ein solches Skript sollte dann natürlich auch über das Newbie-Net der Allgemeinheit zugeführt werden :-).
Das wars. Die ersten Monate sollte man den Platzverbrauch gut im Auge behalten. Man könnte auch die Backups per Cronjob auf anderen Rechnern spiegeln um zusätzliche Redundanz zu erhalten.
Kommentare, Wünsche und Anträge an Johannes Pössinger hannes(at)poessinger(dot)net.