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]. [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 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: * 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 Ausschluss 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. 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: * Ein **Server**, auf den Sie über SFTP zugreifen können. Dies könnte ein eigener Server sein, ein gemieteter virtueller Server ("VPS"), oder etwas Ähnliches wie z.B. der Rechner eines Freundes, der Ihnen Plattenplatz auf seinem System zur Verfügung stellt (und umgekehrt!). * Ein **ssh key** ("Schlüssel"), um sich beim Server anzumelden. Ein Login mittels Passwort wird zur Zeit von Obnam nicht unterstützt. * Genügend Speicherplatz auf dem Server, um Ihre Backups vorzuhalten. 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](http://de.wikipedia.org/wiki/Bazaar)) ist der Pfad absolut, außer wenn er mit `/~/` beginnt (dann ist er relativ zum home-Verzeichnis des Benutzers auf dem Server). Beispiele: * `sftp://liw@backups.pieni.net/~/backup-repo` ist das Verzeichnis `backup-repo` im home-Verzeichnis des Benutzers `liw` auf dem Server `backups.pieni.net`. Beachten Sie das wir nicht den absoluten Pfad des Home-Verzeichnisses benötigen. * `sftp://root@my.server.example.com/home` ist das Verzeichnis `/home` (absoluter Pfad) auf dem Server `my.server.example.com`, wobei der Benutzername `root` verwendet wird, um auf den Server zuzugreifen. * `sftp://foo.example.com:12765/anti-clown-society` ist das Verzeichnis `/anti-clown-society` auf dem Server `foo.example.com`, Zugriff über Port 12765. 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: * 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 unpassend ist und Sie stattdessen lieber das finnische `Valokuvat` möchten, 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. In den folgenden Fällen ist Deduplizierung nicht sinnvoll: * Änderungen an Dateien, indem größere Teile innerhalb der Datei verschoben werden. Die (jetzige) Implementierung der Deduplizierung basiert auf nicht überlappenden Teilen (chunks), die vom Anfang der Datei an gebildet werden. Wenn Daten eingefügt werden, kann Obnam nicht bemerken, dass der Rest der Daten nur etwas "nach hinten" gerutscht ist. Das könnte zum Beispiel in Disk- oder ISO-Images der Fall sein. * Dateien mit doppelten Daten, die aber nicht an einer Chunk-Grenze liegen. Dies könnte zum Beispiel der Fall sein, wenn eine eMail mit großem Anhang an mehrere Empfänger (=Mailboxen auf dem Host) gesendet wird. Jeder Empfänger erhält verschiedene `Received` Kopfzeilen, was den Mailbody und die Anhänge mehr oder weniger verschiebt. Aus diesem Grund kann Obnam die doppelten Daten nicht erkennen und dementsprechend nicht deduplizieren. * Wenn Daten komprimiert vorliegen, zum Beispiel als `.zip` oder `.tar.xz`. Obnam weiss nichts von der Kompression und "sieht" nur die komprimierten Daten, die naturgemäß nicht deduplizierbar sind. 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: * 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 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: * 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 werden 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 werden 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 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.