From 05536f2283cd973a4e3b2dd4b97f9614cffa384d Mon Sep 17 00:00:00 2001 From: Jan Niggemann Date: Thu, 10 Apr 2014 00:25:26 +0200 Subject: Translate 060 to German Submitting chapter 060, as usual, feedback is welcome... jan --- manual/de/060-sichern.mdwn | 387 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 387 insertions(+) create mode 100644 manual/de/060-sichern.mdwn (limited to 'manual/de') diff --git a/manual/de/060-sichern.mdwn b/manual/de/060-sichern.mdwn new file mode 100644 index 00000000..64eb1472 --- /dev/null +++ b/manual/de/060-sichern.mdwn @@ -0,0 +1,387 @@ +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, daß 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]. + +[Wikipedia zum Thema Kibibytes]: https://de.wikipedia.org/wiki/Kibibyte + +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 heisst, +daß 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: + +* Die `--exclude` Option verwendet reguläre Ausdrücke, die dem kompletten + Pfadnamen jeder Datei bzw. jeden Verzeichnisses entsprechen. + Wenn der Pfadname übereinstimmt, werden die Datei oder das Verzeichnis + nicht gesichert; Obnam tut so als wären die Dateien / das Verzeichnis + nicht vorhanden. Wird ein Verzeichnis ausgeschlossen, dann werden alle Dateien und + Unterverzeichnisse ebenfalls ausgeschlossen. Um beispielsweise + alle MP3-Dateien auszuschließen, verwenden Sie (`--exclude='\.mp3$'`). +* Die `--exclude-caches` Option schließt Verzeichnisse aus, + die eine spezielle Datei namens `CACHEDIR.TAG` enthalten, die + mit einer bestimmten Byte-Sequenz anfangen muss. Eine solche Datei könnte + z.B. im Cache-Verzeichnis Ihre Browsers abgelegt werden. Die Daten in + diesen Verzeichnissen sind meist nicht wichtig und brauchen nicht + gesichert zu werden und es ist einfacher, das gesamte Verzeichnis mittels + der Spezialdatei für den Ausschluß zu markieren, als einen regulären Ausdruck + für `--exclude` zu schreiben. +* Die `--one-file-system` Option schließt alle mount points und den Inhalt + der gemounteten Dateisysteme aus. Das ist praktisch um z.B. virtuelle + Dateisysteme wie `/proc`, remote Dateisysteme (z.B. NFS-mounts) und + mittels `obnam mount` eingebundene Obnam Repositories auszuschließen + (letzteres behandeln wir im nächsten Kapitel). + +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. + +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. Ditto, 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. + +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: + +* Wenn Sie zwei identische Dateien haben. Sie haben vielleicht + verschiedene Namen und liegen in verschiedenen Verzeichnissen, + enthalten aber die selben Daten. +* Wenn Dateien wachsen, aber neue Daten nur am Ende angehängt werden, + was z.B. für Logfiles typisch ist. Falls die ersten chunks unverändert + sind, müssen nur die neuen Daten gesichert werden. +* Wenn eine Datei oder ein Verzeichnis umbenannt oder verschoben wird. + Wenn Sie meinen das der englische Begriff `Photos` für das Verzeichnis + unpassen ist und Sie lieber das finnische `Valokuvat` möchteninstead, + können Sie das Verzeichnis einfach umbenennen. Ohne Deduplizierung + müssen Sie dann aber alle Fotos nochmal sichern. +* Wenn ein Team mit den gleichen Daten arbeitet und demnach jeder + eine Kopie der Daten vorhält, muss das Repository statt eine Kopie pro + Team-Mitglied nur eine einzelne Kopie der Daten vorhalten. + +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. + +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: + +* Der Standard-Modus `fatalist` geht davon aus, das keine Kollisionen + auftreten. Das ist für die Meisten Anwender ein vernünftiger Kompromiss + zwischen Geschwindigkeit, Schutz und Sicherheit. +* Der Modus `verify` geht nimmt an das Kollisionen passieren und stellt sicher, + das bereits gesicherte chunks auch wirklich mit dem zu sichernden chunk + übereinstimmen, indem die eigentlichen Daten verglichen werden. + Um das zu tun muss der chunk aus dem Repository geladen werden, was + recht langsam sein könne, da die Prüfsummen oft passen. Dieser Modus + macht Sinn wenn Sie deduplizieren wollen und sehr schnellen Zugriff auf + das Repository haben, z.B. wenn es auf einer lokalen Platte liegt. +* Mit `never` wird die Deduplizierung komplett abgeschaltet. + Wenn Sie keine Deduplizierung benötigen oder Kollisionen fürchten, ist + dies der richtige Modus für Sie. + +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, die von Obnam aktiv benutzt wird, +manuell aufheben, dann wird es 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 + +Beachten Sie, dass manche Locks je Client gelten, um zu verhindern das +Obnam versehentlich zweimal auf dem gleichen Client läuft. Das wäre, wie +auf die eigenen Zehen zu steigen: Irgendwie beeindruckend, aber +unangenehm und nicht zu empfehlen. + +Wenn Sie eine Sperre für einen bestimmten Client manuell aufheben +müssen, können Sie den Client-Namen explizit angeben: + + obnam --client-name magrat \ + -r /media/backups/tomjon-repo force-lock + +(Lange Zeile aus Layout-Gründen umgebrochen.) + +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: + +* Der Logical Volume Manager (LVM) ermöglichst Snapshots. Sie können + Ihre Backups so einrichten, das zuerst ein Snapshot von jedem logischen + Volume gemacht wird, das gesichert weden soll. Dann machen Sie das + Backup und löschen danach den Snapshot wieder. Niemand kann die Daten + im Snapshot verändern, während trotzdem normal weiter gearbeitet weden + kann, während das Backup läuft. +* Ähnlich können Sie auch mit btrfs und seinen subvolumes vorgehen. +* Sie können das System herunterfahren und im Einzelbenutzermodus + neu starten, das Backup machen, und dann wieder im Mehrbenutzermodus + starten. Das ist nicht der schönste Weg, aber der sicherste, um + ein konsistentes Backup zu erhalten. + +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 vertrauchen 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. -- cgit v1.2.1