dckg.net
Blog
Tools
Downloads
Sonntag, 11 September 2016 in Internet, Linux, Sicherheit
LUKS über's Netzwerk
Das Problem mit Duplicity ist, dass Backups nicht für immer inkrementell ausgeführt werden können.
Beudetet, alle paar Wochen bis Monate muss ein komplettes Full-Backup angestoßen werden. Das braucht nicht nur unnötig Platz, sondern ist bei einem gewöhnlichem Heimanschluss untragbar. Mit 1 oder 10 Mbit/s dauert es zu lange. Zudem müssen bei Wiederherstellung alle inkrementellen Stände seit dem letzten Full-Backup heruntergeladen werden.

Andere Programme, wie z.B. bup, das auf git basiert, sehen interessant aus, sind aber auch alles andere als transparent.
Mit Rsnapshot bekomme ich Verzeichnisse, in denen sich der jeweilige Backup-Stand befindet. Ohne das ich irgendwelche Tools anders als cp, ls, rsync bräuchte, zur Wiederherstellung. Mittels Hard-Links werden vom Dateisystem identische Daten dedupliziert.
Und solange ich ein ext-Dateisystem nutzen kann, komme ich noch ganz unbeschwert wieder an die Daten heran.

Bleibt noch das Problem mit der Verschlüsselung.
Diese muss für mich auf Block-Level clientseitig stattfinden, andernfalls kann man es gleich lassen, IMHO.

LUKS auf SSHFS findet man sehr häufig, dafür muss ein Sparse-File auf dem Zielhost erzeugt werden, und man schreibt letztendlich in eine Datei. Performance mäßig ziemlich dürftig. Man bedenke alleine den Speicherplatz, der verschwendet wird.

Weitergehende Recherchen brachten mich zu nbd, ein ziemlich altes Kernelmodul, mit dem sich ganze Block-Devices über das Netzwerk exportieren lassen.
So kann ich mein BanaNAS schön per LVM formatieren, behalte volle Flexibilität was die Partitionsgrößen angeht, und kann die resultierende Partition (oder gleich das ganze Laufwerk) per nbd exportieren.

Zurück auf die Shell:
root@bananapi ~ # modprobe nbd
modprobe: FATAL: Module nbd not found.


Selbst kompilieren ist angesagt.
git clone https://github.com/yoe/nbd
apt install docbook-utils build-essential dh-autoreconf checkinstall
apt-get build-dep nbd
cd nbd
git checkout debian-jessie
./autogen.sh
./configure
make -j $(nproc)
checkinstall make install


LVM.
pvcreate /dev/sda
vgcreate bananas /dev/sda
lvcreate -L 10G -n test bananas


NBD-Server.
nbd-server 0.0.0.0:2000 /dev/mapper/bananas-test


Clientverbindung.
nbd-client -t 30 -persist 192.168.123.123 2000 /dev/nbd0


Die Entscheidende Frage, die sich mir stellte, ist:
Was passiert bei einem disconnect ohne die persist Option?
Wird es explodieren? Womöglich, während gerade rsnapshot Backups macht? Daten zerstören? Unbemerkt?

Ich habe es ausprobiert.
Der ndb-Client crasht und Lese-/Schreibzugriffe auf das gemountete Verzeichnis hängen sich auf.
ls geht noch, nach Ablauf des Timeouts gehen Schreibzugriffe nicht mehr.
Sobald das Timeout gesetzt wurde, geht nach einem reconnect nichts mehr.

Setze ich allerdings nur die persist Option, hängen bei einem Disconnect alle Schreib-/Leseoperationen, bis sich der nbd-client wiederverbindet. Ein angemesseneres Verhalten also.

Mit LUKS kann es nicht besser werden?
dd if=/dev/zero of=test bs=1M count=1000 conv=fdatasync
1048576000 bytes (1.0 GB) copied, 29.2306 s, 35.9 MB/s

Fast das Maximum der BananaPi Schreibgeschwindigkeit.
Das Durchführen der Verschlüsselung auf den Clients ist neben der Sicherheit auch der Geschwindigkeit zuträglich.

Des Weiteren ist das Verhalten von LUKS zu begrüßen, sogar besser als ohne diese zusätzliche Schicht:
Bricht die Serververbindung ab, wird sofort ein IO-Error geworfen, gerade lesende oder schreibende Programme beenden sich mit Fehlermeldung, zudem wird das Dateisystem read-only, bis der nbd-client die Verbindung wiederhergestellt hat.
Besser als ich es erwartet hätte.

Zusammengefasst würde ich anraten, nbd ausschließlich mit LUKS zu nutzen, da sonst einfach alles einfriert.
nbd-client -persist 192.168.123.123 2000 /dev/nbd0


Quellen:
Verschlüsseltes Verzeichnis - Archwiki
nbd-client Manpage
Site optimised for Google Chrome / Chromium