Synchronisieren Sie mit verschlüsseltem Remote-Speicher

1051
Matei David

Ich versuche, eine Ordnerstruktur zwischen mehreren Computern synchron zu halten. Derzeit verwende ich unisoneine Sterntopologie mit einem zentralen Remote-Server. Ich möchte, dass die Daten auf dem Server verschlüsselt werden. Auf dem Server wird der unisonBaum (einschließlich des .unisonOrdners) in einem encfsBaum gespeichert . Um eine Synchronisierung durchzuführen, muss jeder Client

  • montiert den Server-Speicher mit sshfs
  • hängt den encfsSpeicher sshfslokal an
  • führt unisonzwischen der lokalen Kopie der Dokumente und der angehängten aus.

Das Setup hat viele Vorteile:

  • Open-Source-Werkzeuge
  • Skriptfähige Befehlszeilenlösung
  • Sichere Kommunikation über ssh
  • Privacy from Server, da der encfsOrdnerbaum dort nie entschlüsselt wird
  • Fähigkeit, Änderungen während der Synchronisation zu differenzieren, da unisonüber Klartext läuft

Was nicht so gut funktioniert, ist die Geschwindigkeit der Synchronisierung. Da der encfsOrdner vom Server auf dem Client eingehängt ist, muss jeder stat()Anruf, den der Client ausführt, sshan den Server weitergeleitet werden. Die Dokumentenstruktur enthält bereits Tausende von Dateien, und eine unisonSynchronisierung muss mindestens einen stat()Aufruf für jede Datei durchführen (um Änderungen am in dem .unisonOrdner gespeicherten Status auszuschließen ). Gibt es eine schnellere Alternative, die die oben aufgeführten Vorteile beibehält?

Hinweis: Wenn ich die letzte Bedingung entfernen würde, könnte ich unisonüber cyphertext laufen und den encfsBaum nur lokal einhängen . Dann unisonwürde lokal auf dem Client und auf dem Server ausgeführt, so stat()Anrufe wären schnell. Aber es ist schön, zumindest die Dateien anzeigen zu können, die synchronisiert werden. mit unisonover encfscyphertext würden Dateinamen verschlüsselt.

Ich verstehe, dass zur Lösung dieses Problems während der Synchronisierung Datei-Metadaten effizient vom Server zum Client übertragen werden müssen. Ich frage mich, ob es eine Möglichkeit gibt (z. B. eine Kombination aus vorhandenen Werkzeugen), um die Metadaten an einem Ort zu speichern, sodass alle übertragen werden, indem nur ein (oder wenige) Datenblöcke gesendet werden, anstatt Tausende von Blöcken zu senden (was die Weiterleitung von stat()Aufrufen bewirkt).

Was wäre, wenn ich encfseine ext4Over- dm-cryptPartition ersetzen würde, die in einer großen Datei auf dem Server gespeichert und auf dem Client per losetupover sshfseingebunden ist? Würde das ext4Dateisystem Dateimetadaten zusammenhalten, so dass es durch das Senden einiger Blöcke übertragen wird? Möchten Sie sshfsnur ein paar Blöcke während eines Updates senden, anstatt die gesamte verschlüsselte Datei neu zu schreiben?

0

1 Antwort auf die Frage

0
Matei David

Ich habe mit Erfolg hatte ext4über luksüber sshfs. Ich finde, dass das Laufen unisonauf einem Mount dieses Typs viel, viel schneller ist als encfsvorbei sshfs. Es muss also sein, dass diese Tausenden von stat()Strukturen irgendwie in den ext4fs gebündelt sind, sodass sie während einer Synchronisierung weniger Netzwerkverkehr benötigen.

Etwas ärgerlich ist, dass das ext4Dateisystem für jede Datei eine Benutzer-ID benötigt. Diese Benutzer-ID wird zum Berechnen von Zugriffsberechtigungen verwendet, wenn die ext4fs lokal auf einem Client eingehängt ist. In meinem Fall habe ich mich dazu entschieden, meine lokale Benutzer-ID auf allen Clients, von denen ich synchronisiere, in eine bestimmte Zahl zu ändern . Die Alternative wäre, die Dateien in den speichern ext4fs mit uid 0, dann verwenden Sie bindfsdie Montage ext4fs mit Nicht-Root - uid.

Verwandte Probleme