LUKS übers 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
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.
Weitergehende Recherchen brachten mich zu
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
Zurück auf die Shell:
Selbst kompilieren ist angesagt.
LVM.
NBD-Server.
Clientverbindung.
Die Entscheidende Frage, die sich mir stellte, ist:
Was passiert bei einem disconnect ohne die
Wird es explodieren? Womöglich, während gerade
Ich habe es ausprobiert.
Der ndb-Client crasht und Lese-/Schreibzugriffe auf das gemountete Verzeichnis hängen sich auf.
Sobald das Timeout gesetzt wurde, geht nach einem reconnect nichts mehr.
Setze ich allerdings nur die
Mit
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
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,
Quellen:
Verschlüsseltes Verzeichnis - Archwiki
nbd-client Manpage
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