Sichern

Dieses Kapitel beschreibt verschiedene Aspekte der Erstellung von Backups mit Obnam.

Ihr erstes Backup

OK, dann lasst uns mal ein Backup machen! Um den Beispielen zu folgen benötigen Sie Live-Daten, die Sie sichern können. Diese Beispiele benutzen Dateinamen, die Sie an Ihre eigenen Dateinamen anpassen müssen. Die Beispiele gehen davon aus, dass Ihr Home-Verzeichnis /home/tomjon ist und Sie Dokumente in einem weiteren Verzeichnis names Documents in Ihrem Home-Verzeichnis haben. Weiterhin wird davon ausgegangen das Sie ein USB-Laufwerk unter /media/backups gemounted haben und das Sie das Verzeichnis tomjon-repo auf diesem USB-Laufwerk als Backup-Repository benutzen.

Diesen Annahmen folgend sichern Sie Ihre Dokumente so:

obnam backup -r /media/backups/tomjon-repo ~/Documents

Das ist alles. Wenn Sie viele Dokumente haben dauert es eine Weile, aber am Ende sieht es dann ungefähr so aus:

Backed up 11 files (of 11 found), uploaded 97.7 KiB in 0s at 647.2 KiB/s average speed

Das bedeutet, das Obnam insgesamt 11 Dateien gefunden hat, von denen alle 11 gesichert wurden. Die Dateien waren zusammen ungefähr 100 Kilobyte groß und die Upload Geschwindigkeit für diese Daten war über 600 Kilobytes pro Sekunde. Für die Eindeutigkeit sind Einheiten mit IEC Präfixen versehen (Basis 2), weitere Informationen finden Sie unter [Wikipedia on kibibytes].

Ihr erster Sicherungslauf sollte eher wenige Daten enthalten, so können Sie prüfen das alle Einstellungen korrekt sind ohne lange zu warten. Anstatt Ihres gesamten Home-Verzeichnisses könnten Sie mit einem kleineren Unterordner beginnen.

Ihr zweites Backup

Nach Ihrem ersten Backup möchten Sie irgendwann einmal ein Weiteres erstellen. Das tun Sie auf die gleiche Weise:

obnam backup -r /media/backups/tomjon-repo ~/Documents

Beachten Sie das Sie Obnam nicht mitteilen müssen ob Sie ein Vollbackup oder ein inkrementelles Backup erstellen wollen. Obnam sorgt dafür das jede Generation ein Snapshot der Daten zur Zeit des Backups ist. Somit wird nicht zwischen Vollbackup und inkrementellem Backup unterschieden. Jede Generation ist eine vollständige Sicherung, was aber nicht heißt, dass jede einzelne Generation sämtliche Daten separat vorhält. Obnam sorgt dafür das mit jeder neuen Generation nur die Daten gesichert werden, die bisher nicht im Repository waren. Obnam sucht die Daten in jeder Datei und jeder vorausgehenden Generation aller Clients, die sich das Repository teilen.

Wir kommen später auf das Thema zurück, wie Generationen gelöscht werden können, Sie werden dabei sehen das Obnam jede beliebige Generation löschen kann, auch wenn sie sich mit anderen Generationen Daten teilt. Die anderen Generationen werden dabei natürlich keinerlei Daten verlieren.

Nachdem Sie das zweite Backup erstellt haben, können Sie die Generationen ansehen:

$ obnam generations -r /media/backups/tomjon-repo
2   2014-02-05 23:13:50 .. 2014-02-05 23:13:50 (14 files, 100000 bytes) 
5   2014-02-05 23:42:08 .. 2014-02-05 23:42:08 (14 files, 100000 bytes)

Wir sehen zwei Generationen, die die Kennungen 2 und 5 haben. Die Bezeichner der Generationen sind nicht unbedingt eine einfache Folge wie 1, 2, 3. Dies liegt daran wie einige der internen Datenstrukturen in Obnam umgesetzt werden, und in keinster Weise daran das der Autor Spaß daran hat, Menschen zu verwirren.

Die beiden Zeitstempel zeigen wenn der Backup-Lauf begann und wann er endete. Darüber hinaus wird für jede Generation die Anzahl der Dateien in dieser Generation ausgegeben (insgesamt, nicht nur neue oder geänderte Dateien), und die summierte Größe der Dateien.

Auswählen was zu sichern ist -- und was nicht

Obnam muss wissen, was gesichert werden soll. Dazu übergeben Sie eine Liste von Verzeichnissen, die backup roots genannt werden. Bisher haben wir in den Beispielen dieses Kapitels das Verzeichnis ~/Documents als backup root benutzt (das ist das Verzeichnis Documents in Ihrem Home Verzeichnis). Es darf aber auch mehrere backup roots geben:

obnam -r /media/backups/tomjon-repo ~/Documents ~/Photos

Alles in den backup root Verzeichnissen wird gesichert -- außer es ist explizit ausgeschlossen. Es gibt mehrere Möglichkeiten um etwas von Backups auszuschließen:

Generell ist es besser zu viel zu sichern als zu wenig. Sie sollten auch genau wissen, was gesichert wird und was nicht. Die Option --pretend bewirkt das Obnam ein Backup anfertigt, das Repository dabei aber nicht verändert, es ist also schnell durchgelaufen. So können Sie sehen was gesichert würde und die excludes entsprechend anpassen.

Backups "außer Haus" speichern

Vermutlich möchten Sie mindestens ein Backup auf einem entfernten Rechner "offsite" (außer Haus) speichern. Obnam kann Backups mittels SFTP (Teil von ssh) über das Netzwerk machen. Sie benötigen folgendes um dies zu tun:

Um auf den Server zuzugreifen verwendet Obnam lediglich den SFTP-Teil der ssh-Verbindung. Um zu prüfen ob das funktioniert können Sie diesen Befehl ausführen:

sftp USER@SERVER

Passen Sie USER@SERVER entsprechend Ihren Zugangsdaten an. Sie sollten die Meldung Connected to SERVER sehen und in der Lage sein, ls -la aufzurufen um den Verzeichnisinhalt der Gegenseite auszugeben.

Sobald all das richtig eingerichtet ist, kann Obnam den Server über eine SFTP-URL als Repository benutzen und so auf den Server sichern.

 obnam -r sftp://USER@SERVER/~/mein-wertvolles-backup

Einzelheiten über SFTP-URLs finden Sie im nächsten Abschnitt.

URL Syntax

Wann immer Obnam eine URL akzeptiert, kann immer ein lokaler Pfadname oder eine SFTP-URL angegeben werden. SFTP-URLs haben die Form:

sftp://[user@]domain[:port]/path

Dabei ist domain ein normaler Domainname der einen Server bezeichnet, user der Benutzername auf diesen Server, port ein optionaler numerischer port und path ein gültiger Pfad auf dem Server.

Entgegen dem SFTP-Standard (aber wie bei bzr) ist der Pfad absolut, außer wenn er mit /~/ beginnt (dann ist er relativ zum home-Verzeichnis des Benutzers auf dem Server).

Beispiele:

Sie können SFTP URLs für das Repository und die Live-Daten (--root)verwenden. Aufgrund von Beschränkungen im SFTP-Protokoll und seiner Implementierung in der paramiko-Bibliothek funktionieren einige Dinge beim Zugriff auf Live-Daten über SFTP nicht so gut.

Dabei besonders hervorzuheben wäre die Handhabung von Hardlinks, weswegen die URL beim Zugriff auf Live-Daten nicht mit /~/ enden sollte. Fügen Sie in diesem besonderen Fall einen Punkt am Ende hinzu.

Pull Backups

Obnam kann die Live-Daten auch über SFTP statt über das lokale Dateisystem sichern. Das heißt Sie können Obnam auf, sagen wir, Ihrem Desktop zur Sicherung Ihres Servers oder auf Ihrem Laptop zur Sicherung Ihres Telefons laufen lassen (vorausgesetzt, Sie bekommen den SSH-Server auf dem Telefon zum laufen). Manchmal ist es nicht möglich, Obnam auf der Maschine zu installieren, auf der die Live-Daten liegen. Dann ist es sinnvoll, stattdessen ein Pull Backup zu machen: Sie lassen Obnam auf einem anderen Rechner laufen und lesen die Live-Daten über das SFTP-Protokoll.

Um dies zu tun spezifizieren Sie die Backup-Quelle (root im config file oder als Kommandozeilen-Argument zu obnam backup) mittels einer SFTP-URL. Sie sollten auch den Client-Namen explizit angeben. Ansonsten wird Obnam den Hostnamen des Rechners verwenden auf dem es läuft. Dies kann höchst verwirrend sein: Angenommen der Client-Name ist my-laptop und der des Servers ist down-with-clowns, dann speichert Obnam die Backups als ob die Daten zu my-laptop gehörten.

Wenn Sie Ihr Laptop ebenfalls in das gleiche Backup-Repository sichern, wird es noch schlimmer. Obnam speichert dann sowohl Server- und Laptop-Daten mit dem gleichen Client-Namen, was zu viel Verwirrung für alle führt.

Beispiel:

obnam backup -r /mnt/backups sftp://server.example.com/home \
    --client-name=server.example.com3

Konfigurationsdateien: Eine kurze Einführung

Zu diesem Zeitpunkt werden Sie vielleicht bemerkt haben, dass Obnam eine ganze Reihe von konfigurierbare Einstellungen hat, die Sie auf vielfältige Art verändern können. Auf der Kommandozeile ist das immer möglich, aber dann wird das Kommando doch recht lang. Stattdessen könnten Sie auch eine Konfigurationsdatei verwenden.

Jede Option die Obnam kennt, kann auch in einer Konfigurationsdatei verwendet werden. Später in diesem Handbuch gibt es ein ganzes Kapitel, das alle Details der Konfigurationsdateien und verschiedenen Einstellungen, die Sie verwenden können, umfasst. Hier geben wir erstmal eine kurze Einführung.

Eine Obnam Konfigurationsdatei sieht so aus:

[config]
repository = /media/backup/tomjon-repo
root = /home/liw/Documents, /home/liw/Photos
exclude = \.mp3$
exclude-caches = yes
one-file-system = no

Diese Form der Konfigurationsdatei ist als "INI file" bekannt, vielen z.B. von Microsoft Windows. Jede Obnam-Option wird in den Abschnitt [config] geschrieben, und jede Einstellung hat den gleichen Namen wie die Kommandozeilen-Option (ohne die Doppel-Minuszeichen). Demnach wird --exclude auf der Kommandozeile und exclude im Config-File verwendet.

Einige Optionen können mehrere Werte annehmen, z.B. exclude und root, die Werte werde mittels Komma getrennt. Wenn die Anzahl der Werte zu groß wird können Sie sie über mehrere Zeilen verteilen; die zweite und weitere Zeilen müssen dann mit Leerzeichen oder TAB eingerückt werden.

Jetzt sollten Sie genug für den Anfang haben, Details finden Sie im Kapitel "Obnam Konfigurationsdateien und Einstellungen".

Wenn Ihre wertvollen Daten sehr groß sind

Wenn Ihre wertvollen Daten sehr groß ist, kann die erste Sicherung sehr lange dauern. Dito, wenn Sie viele neue wertvolle Daten in eine späteres Backup aufnehmen. In diesen Fällen müssen Sie sehr geduldig sein und dem Backup Zeit lassen. Oder Sie können klein beginnen und dann nach und nach Sicherungen hinzufügen.

Die Option "Geduld" ist einfach: Sie lassen Obnam alles sichern, starten die Sicherung und warten, bis es fertig ist, auch wenn das Stunden oder Tage dauert. Sollte die Sicherung vorzeitig abbrechen, z. B. wegen einer ausgefallenen Netzwerkverbindung, brauchen Sie Dank Obnams Checkpoint-Unterstützung nicht von Grund auf neu beginnen. Jedes Gigabyte oder so (standardmäßig) erzeugt Obnam eine Checkpoint Generation. Wenn die Sicherung später abstürzt, können Sie Obnam einfach erneut ausführen und es wird beim letzten Checkpoint weitermachen. Das alles passiert vollautomatisch. Wie oft die Checkpoints erstellt werden sollen können Sie in der Option --checkpoint verändern.

Falls Obnam nicht bis zum Ende durchläuft und Sie es neu starten müssen, dann beginnt der Scan der Quelldateien wieder von vorne. Die Checkpoint Generationen enthalten nicht genügend Zustandsinformationen über die gescannten Quelldateien, um Obnam einfach bei der aktuellen Datei im Checkpoint weiter laufen zu lassen: Es wäre ein sehr komplizierter Zustand, der außerdem leicht von Dateisystem-Änderungen invalidiert würde. Stattdessen scannt Obnam erneut alle Dateien, wobei die meisten hoffentlich schon in einer Checkpoint Generation enthalten sind und seitdem nicht geändert wurden, so dass der Scan recht schnell gehen sollte.

Das Problem mit der Option "Geduld" ist, dass Ihre wichtigsten Daten nicht gesichert werden, während alle Ihre großen, aber weniger wertvollen Daten gesichert werden. Zum Beispiel können Sie eine große Menge an heruntergeladenen Videos von Konferenz-Präsentationen haben, was schön ist, aber nicht enorm wichtig. Während diejenigen gesichert werden, bleiben Ihre eigenen Dokumente ungesichert.

Sie können dies umgehen, indem Sie zunächst alles außer Ihren wertvollsten Daten vom Backup ausschließen. Wenn diese dann gesichert sind, können Sie nach und nach die Ausschlüsse reduzieren, bis Sie alles gesichert haben. Zum Beispiel könnte Ihr erstes Backup folgende Konfiguration haben:

obnam backup -r /media/backups/tomjon-repo ~ \
    --exclude ~/Downloads

So werden alle Downloads ausgeschlossen. Im nächsten Lauf schließen Sie nur noch Video-Dateien (mp4) aus:

obnam backup -r /media/backups/tomjon-repo ~ \
    --exclude ~/Downloads/'.*\.mp4$'

Dann reduzieren Sie den Ausschluss auf einzelne Videos, deren Namen mit einem bestimmten Buchstaben beginnen:

obnam backup -r /media/backups/tomjon-repo ~ \
    --exclude ~/Downloads/'[^b-zB-Z].*\.mp4$'

Reduzieren Sie die Ausschlüsse immer weiter bis alle Videos gesichert sind.

Deduplizierung

Obnam de-dupliziert die Daten die es sichert über alle Dateien in allen Generationen für alle Clients, die sich das Repository teilen. Dies geschieht durch Aufteilen der Dateidaten in "chunks" genannte Teile. Jedes Mal wenn Obnam eine Datei liest und ein chunk zusammenkommt, schaut es im Repository nach, ob ein identischer chunk bereits vorhanden ist. Wenn ja muss Obnam den chunk nicht hochladen, was Platz, Bandbreite und Zeit spart.

Deduplizierung in Obnam ist in verschiedenen Situationen hilfreich:

Die Deduplizierung in Obnam ist nicht perfekt. Die Granularität des Findens doppelter Daten ist recht grob (vgl. Option --chunk-size) , daher kann Obnam oft keine Überschneidungen finden, wenn die Änderungen nur klein sind.

In den folgenden Fällen ist Deduplizierung nicht sinnvoll:

Künftige Versionen werden hoffentlich einen besseren Deduplizierungsalgorithmus enthalten. Sollten Sie diesen optimistischen Absatz in einer 2017 oder später erschienenen Version von Obnam finden, informieren Sie bitte die Maintainer. Vielen Dank.

Deduplizierung und Sicherheit gegen Prüfsummen-Kollisionen

Dieses Thema ist ein bisschen beängstigend, aber es wäre unehrlich, es überhaupt nicht zu behandeln. Sie dürfen gern später auf diesen Abschnitt zurück kommen.

Obnam verwendet den MD5-Algorithmus zur Erkennung von doppelten chunks. MD5 hat den Ruf, unsicher zu sein: Menschen haben Dateien gebaut die zwar unterschiedlich sind, aber zu der gleichen MD5-Prüfsumme führen. Es stimmt -- MD5 ist nicht für sicherheitskritische Anwendungen geeignet.

Jeder Prüfsummen-Algorithmus kann Kollisionen haben. Obnam auf, sagen wir, SHA1, SHA2, oder den neuen SHA3 Algorithmus umzustellen, würde nicht die Möglichkeit von Kollisionen ausschließen. Es reduzierte die Chance von zufälligen Kollisionen, aber die Chance ist bereits so klein, dass sie mit MD5 vernachlässigt werden kann. Oder, anders ausgedrückt: Wenn Sie über zufällige MD5-Kollisionen besorgt sind, sollten Sie ebenfalls über versehentliche SHA1, SHA2 oder SHA3 Kollisionen besorgt sein.

Abgesehen von zufälligen Kollisionen gibt es zwei Fälle, in denen Sorgen um Prüfsummen-Kollisionen angebracht sind (unabhängig von Algorithmus).

Erstens: Wenn Sie einen Gegner haben der Ihre gesicherten Daten korrumpieren möchte, kann er einige der gesicherten Daten mit anderen Daten mit der gleichen Prüfsumme austauschen. Auf diese Weise werden Ihre Daten beschädigt ohne das Obnam es merkt und Sie können sie nicht wieder herstellen.

Zweitens: Wenn Sie Prüfsummen-Kollisionen erforschen, haben Sie wahrscheinlich Dateien, deren Prüfsummen kollidieren. In diesem Fall werden Sie nach einer Katastrophe die Daten in ihrem Ursprungszustand wieder herstellen wollen, ohne das Obnam eine mit der anderen verwechselt.

Um mit diesen Situationen umzugehen besitzt Obnam drei Deduplizierungs-Modi, die Sie mit der --deduplicate Einstellung steuern:

Leider gibt es keine Deduplizierung die unverwundbar gegen Kollisionen ist und dabei auch noch schnell arbeitet, wenn der Zugriff auf das Repository langsam ist. Der einzige Weg um dagegen geschützt zu sein ist, die Daten zu vergleichen. Wenn das Herunterladen der Daten aus dem Repository langsam ist, dann wird der Vergleich natürlich erhebliche Zeit in Anspruch nehmen.

Locking

Mehrere Clients können sich ein Repository teilen. Um zu verhindern das sie sich dabei gegenseitig auf die Füße treten, sperren sie Teile des Repositories während des Vorgangs. Im Kapitel "Mehrere Clients in einem Repository" finden Sie Details.

Wenn Obnam abrupt abbricht kann die Sperre bestehen bleiben, auch wenn es nur einen einzelnen Client im Repository gibt. Neue Backups sind so nicht mehr möglich. Der Abbruch kann z.B. durch eine abgebrochene Netzwerkverbindung oder aufgrund eines Fehlers in Obnam passieren, genau so wenn Obnam vom Benutzer unterbrochen wird, bevor es fertig ist.

Die Befehl force-lock kann diese Situation bereinigen, aber das ist gefährlich. Wenn Sie eine Sperre aufheben, die von egal welcher Obnam-Instanz auf egal welchem Client, der das Repository aktiv benutzt, manuell aufheben, dann wird Obnam wahrscheinlich ins Stolpern geraten. Im Extremfall kann sogar das Repository beschädigt werden. Seien Sie also vorsichtig.

Wenn Sie entschieden haben das es kein Problem darstellt, wird die Sperre wie folgt aufgehoben:

obnam -r /media/backups/tomjon-repo force-lock

Zum jetzigen Zeitpunkt ist es nicht möglich Eine Sperre manuell aufzuheben, die zu einem einzelnen Client gehört.

Konsistenz der Live-Daten

Das Erstellen einer Sicherungskopie kann eine ganze Weile dauern, und während das Backup läuft, könnte sich das Dateisystem ändern. Dies führt dazu, das der Snapshot, den Obnam als Generation sichert, in sich inkonsistent ist. Ein Beispiel: Sie haben zwei Dateien, A und B, die synchron gehalten werden müssen. Sie machen ein Backup, währenddessen Sie zuerst A und dann B ändern. Unglücklicherweise sichert Obnam File A bevor Sie Ihre Änderungen speichern und File B, nachdem Sie die Änderungen gespeichert haben. Die Sicherungsgeneration hat nun Versionen von A und B, die nicht synchron sind. Das ist schlecht.

Es gibt mehrere Möglichkeiten, mit diesem Problem umzugehen:

Beachten Sie, dass Snapshots auf Dateisystemebene nicht wirklich eine konsistente Sicht auf die Live-Daten garantieren können. Eine Anwendung kann mitten im Schreiben einer Datei oder Gruppe von Dateien sein, wenn der Snapshot gemacht wird. Das ist gewissermaßen ein Bug in der Anwendung, aber das zu wissen hilft Ihnen nicht besser zu schlafen.

In der Regel haben die meisten Systeme aber ausreichend Leerlaufzeit, um ein konsistentes Backup während dieser Zeit zu erstellen. Zum Beispiel kann das Backup auf einem Laptop ausgeführt werden, während der Benutzer anderswo ist und nicht aktiv mit der Maschine arbeitet.

Wenn irgend möglich sollte Ihr Backup-Programm überprüfen, ob die Daten einer Backup-Generation in sich konsistent sind. Ansonsten werden Sie entweder darauf vertrauen müssen das die Anwendungen, die Sie verwenden, nicht zu buggy sind.

Wenn Sie diesen Abschnitt nicht verstanden haben: Keine Sorge, seien Sie glücklich und schlafen Sie gut.