Ich möchte das Home-Verzeichnis meines Laptops verschlüsselt auf eine externe Festplatte sichern. (Später sollen vielleicht auch Teile davon auf einen Online-Speicher abgelegt werden.)

Bisher habe ich dazu rsync und EncFS benutzt. Dies sah so aus, dass ich eine externe Festplatte zunächst mittels EncFS vollständig verschlüsselt habe und anschließend mit rsync mein Home-Verzeichnis darauf gesichert habe. Der Vorteil hierin liegt, dass ich - sofern das Volume entschlüsselt ist - normalen Zugriff auf die aktuellen Dateien haben kann. Nicht zuletzt weil ich beim Backup nach Möglichkeit soweit möglich verstehen möchte, was passiert, habe ich diese Methode genutzt.

Nun bin ich auf duplicity gestoßen. Wenn ich das richtig verstehe, dann legt dieses am Zielort ein (oder mehrere?) verschlüsselte tar-Dateien an, in dem eine Vollsicherung sowie Patches der inkrementellen Sicherung liegen. D.h., dass ich hiermit nicht immer nur den letzten sondern auch vorherige Zustände abrufen kann. Sichern kann ich das ganze dann wieder mittels rsync auf eine externe Platte. Diese kann unverschlüsselt bleiben, weil ja bereits die Archive verschlüsselt sind.

Meine Fragen:

• Habe ich die Funktionsweise richtig verstanden?

• Wie funktioniert eine Wiederherstellung v.a. von Zuständen, die nicht dem aktuellsten entsprechen?

• Welche weiteren Vor- oder Nachteile haben die beiden obigen Backup-Varianten?

• Wie sieht es mit der Verschlüsselung im Hinblick auf Online-Speicher aus? Ist eine Methode "sicherer"?

• Ist eine Methode "zukunftssicherer"? (Ich überlege vor allem, was passiert, wenn duplicity mal nicht mehr weiterentwickelt wird. Bei der rsync-Methode habe ich schließlich die normalen Dateien vorliegen.)

Vielen Dank für Antworten!

P.S.: Dass Deja Dup existiert, ist mir klar. Ich möchte aber zunächst verstehen, was "hinter den Kulissen" passiert.

Hallo,

vorweg etwas zum Thema duplicity. Du willst wissen, was "hinter den Kulissen" von Deja Dup passiert - wenn man sich die letzten Problemmeldungen in diesem Forum ansieht, hast Du durchaus Chancen, dich intensiv damit zu beschäftigen, falls Du es verwendest.

.

Grundsätzlich:

Meiner Ansicht (und meinem Verständnis) nach ist EncFS nur eingeschränkt eine Verschlüsselungssoftware, da sie dateibasiert verschlüsselt; was Vorteile hat, aber den großen Nachteil, dass die Dateinamen noch lesbar sind. Je nachdem, wovor die Verschlüsselung schützen soll, greift sie also nur eingeschränkt.

Das ist aber nicht der wesentliche Punkt.

Der wesentliche Punkt ist, dass eine Sicherung langfristig gesehen werden muss. Ich sichere auf Basis von storeBackup und meine ältesten noch vorhandenen Sicherungen sind von Anfang 2003. Aus diesem Grunde habe ich ein Sicherungsverfahren gewählt, das möglichst transparent ist und nur Standards verwendet: Ein Linux-Filesystem - der Rest (das Backup-Programm) ist nicht nötig, auch wenn es noch mit den alten Sicherungen klar kommt).

Nun zu Deiner Idee: Vor ca. einem Monat fand ich im Internet jemand, der mit EncFS und storeBackup seine Daten verloren hat - und das hatte nach seiner Beschreibung definitiv nichts mit storeBackup zu tun: Es waren nach erfolgreicher Sicherung beim Recover von EncFS einfach alle Dateien weg, die Directories waren noch da. Es gab keine Antworten auf sein Problem.

In Deiner Stelle würde ich entweder auf die Verschlüsselung verzichten oder dm-crypt (mit luks) verwenden. Das ist im Vanilla Kernel und massenhaft erprobt. Die Wahrscheinlichkeit, dass Du in 5-10 Jahren noch an Deine Daten kommst, ist relativ hoch.

Für die Sicherung würde ich Format empfehlen, bei dem Du ohne das Tool noch an Deine Daten kommst. Das schützt gegen Fehler des Tools, Einstellung des Tools in ein paar Jahren und insbesondere Formatänderungen (z.B. dass alte Versionen auf neueren Distris nicht mehr laufen und ältere Distris nicht mehr auf neuen Rechnern oder VMs). In Frage kommen da z.B. rsync oder eben storeBackup, was als Backuptool wesentlich leistungsfähiger ist (z.B. Dedup, Hardlinks korrekt zurücksichern, alte Backups löschen, selektive Kompression, Konsistenzprüfung, sehr weitgehend konfiguriertbar, etc.). Bei verschlüsselten Platten würde ich auch immer Empfehlen, ein Kopie des Backups zu haben; da bin ich als Tester für storeBackup gerade dabei, eine Replikationslösung zu verwenden, die jetzt seit ca. 3 Wochen bei mir läuft (gibt's noch nicht offiziell, ist aber auf der WebSite unter Support als im Test befindlich dargestellt).

Man findet die Doku unter http://www.nongnu.org/storebackup/de/, es ist auch im Debian / Ubuntu Repository (allerdings nicht in der letzten Version).

.

Das war jetzt vielleicht nicht das, was Du erwartet hast, aber ich hoffe, es hilft Dir etwas.

ixo

Hallo,

@ixo: Was macht diese storeBackup Replikation? Ich konnte da jetzt nichts dazue auf der Webseite finden.

Wird duplicity mitlerweile als "stable" herausgegeben? Bedenke auch das bei duplicity Bitfehler in einem älteren Backup dazu führen können, dass alle nachfolgenden (inkrementellen) Backups nicht mehr lesbar sind.

EncFs hat den vorteil, das sich die verschlüsselten Datein effizient mit rsync/unison mit einem Online-Speicher synchronisieren lassen. Das verlierst Du mit duplicity. Mein Tip zum regelmäßigen effizienten speichern von lokalen Backups (gesicherte konsistente Zustande) wäre auch storeBackup.

Zum synchronisieren: http://wiki.ubuntuusers.de/Unison#Automatisierung-mit-sucsynct (Auf der anderen Seite kann ja wieder storeBackup laufen.) Zusätzlich zu den (z.B. stündlichen) storeBackup läufen, kann dir unison dann auch noch die letzten x Versionen der gerade bearbeiteten Dateien vorhalten. Damit sollte es immer einen einfachen Weg zurück geben.

Netzmaat 007 schrieb:

Hallo,

@ixo: Was macht diese storeBackup Replikation? Ich konnte da jetzt nichts dazu auf der Webseite finden.

Wie geschrieben, läuft das Zeugs bei mir inzwischen seit etwa 2 Monaten ohne Probleme. (Ich repliziere einfach nur drei Backup-Serien auf eine externe Platte, die ich einmal pro Woche dranhänge. Die Deltas speichere ich bis dahin auf einem anderen Medium als das primäre Backup - einfach auf der source Platte.)

Es gab einige Diskussionen wegen der Doku. Die englische sollte inzwischen soweit brauchbar sein(!?) - ich habe sie noch nicht ganz gelesen ). Es wird wohl noch einen "ReplicationWizard" geben, um die einfachste Konfiguration noch einfacher zu machen. Den gibt's aber noch nicht (generiert einfach ein paar Konfigurationsdateien konsistent). Urlaubszeit und Arbeit haben auch nicht dazu beigetragen, dass es schneller geht.

Falls Du auch "testen" willst, schick mir 'ne PN mit Deiner E-Mail Adresse.

Wird duplicity mitlerweile als "stable" herausgegeben? Bedenke auch das bei duplicity Bitfehler in einem älteren Backup dazu führen können, dass alle nachfolgenden (inkrementellen) Backups nicht mehr lesbar sind.

Keine Ahnung. Ich habe mich nie damit beschäftigt.

EncFs hat den vorteil, das sich die verschlüsselten Datein effizient mit rsync/unison mit einem Online-Speicher synchronisieren lassen.

Ich habe neulich (ich find's nicht mehr wieder), was von demjenigen gelesen, der die Probleme mit storeBackup und EncFs hatte. Er hatte keine Antwort bekommen, aber herausgefunden, dass das Problem mit rsync nicht Auftritt. Der Unterschied von rsync und storeBackup in diesem Kontext ist nach meinem Verständnis, dass storeBackup das Schreiben von kopierten oder komprimierten sowie von Hardlinks parallelisiert und rsync nicht. storeBackup ist also etwas "brutaler" zum Ziel-Filesystem. Das das scheinbar Probleme bedingt, stimmt mich über EncFs bedenklich. Ich habe aber mit EncFs überhaupt keine Erfahrung (auch keine Ahnung davon), vielleicht liegt es auch an etwas völlig anderes (z.B. Hardwarefehler).

Das verlierst Du mit duplicity. Mein Tip zum regelmäßigen effizienten speichern von lokalen Backups (gesicherte konsistente Zustande) wäre auch storeBackup.

Zum synchronisieren: http://wiki.ubuntuusers.de/Unison#Automatisierung-mit-sucsynct (Auf der anderen Seite kann ja wieder storeBackup laufen.) Zusätzlich zu den (z.B. stündlichen) storeBackup läufen, kann dir unison dann auch noch die letzten x Versionen der gerade bearbeiteten Dateien vorhalten. Damit sollte es immer einen einfachen Weg zurück geben.

Das Problem bei dieser Art zu synchronisieren ist u.a., dass immer das gesamt Backup in die Synchronisation einbezogen wird - was bei vielen Backups und damit sehr vielen Hardlinks reichlich lange dauert. Ich hatte das vorher auch mit rsync gemacht.

Grüße, ixo

Ich würde immer nur die aktuellen Dateien zwischen den Hosts per unison synchronisieren lassen (entweder nur die verschlüsselte oder nur die klar Version), und jeden Host eingenständig Backups von den synchronisierten Dateien machen (speichern) lassen. Da unison so nur den aktuelle Satz an Dateien beobachtet, geht das schneller und die Änderungen werden mit der rsync/unison effizienz übertragen (sogar dropbox-mäßig in beide Richtungen), statt wie storeBackup Datei-weise bzw Datei-Block-weise sofern konfiguriert.

Auf allen Hosts, die etweder verschlüsselte oder unverschlüsselte Dateien im Dateisystem liegen haben (Dateinamen sind wenn auch Verschlüsselt), arbeitet storeBackup dann auch wieder unabhängig von EncFS direkt mit den Dateien im normalen Dateisystem.

PS: Möglicherweise wurde bei dem von Dir geschildertem Problemfall mit encfs --reverse gearbeitet (eine virtuelle, verschlüsselte Ansicht eines Unverschlüsselten Verzeichnis), dieses scheint schreibbar, es kommmt aber noch zu Fehlern beim Schreiben in das Verzeichnis (tmp files etc.).