Wer ein verschlüsseltes Laufwerk remote, also entweder im lokalen Netzwerk oder via Internet auf einem anderen Server, betreiben will, kennt das Problem: Egal ob man LUKS oder Veracrypt benutzt, die Performance bricht extrem ein.
Woran das liegt kann ich Ihnen zwar nicht sagen, aber es gibt für Linux-Systeme einen Weg, die reguläre Performance der jeweiligen Leitung auch für verschlüsselte Laufwerke zu erhalten.
Zunächst erzeugt man eine Datei, die etwas größer ist als das geplante verschlüsselte Laufwerk. Ein paar GB mehr reichen:
dd if=/dev/zero of=loopbackfile.img bs=1G count=100
Dies erzeugt z.B. eine Datei aus nur Nullbytes mit der Größe 100GB. Danach richtet man diese Datei als Loop Device ein:
sudo losetup -fP loopbackfile.img
Dann ein Filesystem darauf installieren:
mkfs.ext4 loopbackfile.img
Es empfiehlt sich, die Menge des für das Betriebssystem reservierten Speichers in diesem Laufwerk zu reduzieren. Da nur eine einzige Datei darauf kommt, und die (fast) den gesamten Speicherplatz einnimmt, wird kein reservierter Speicher benötigt:
tune2fs -m 0 loopbackfile.img
Jetzt das Loop-Laufwerk mounten:
mkdir loopfs mount -o loop loopbackfile.img loopfs
Und nun kann man im Verzeichnis „loopfs“ die Verschlüsselungsdatei mit gleich welchem Verfahren anlegen und befüllen. Wenn alles erledigt ist, Crypt- und Loop-Laufwerk (in dieser Reihenfolge) unmounten, dann das „loopbackfile.img“ an die endgültige Destination hochladen – und voilà, das externe verschlüsselte Laufwerk funktioniert mit der vollen Geschwindigkeit der jeweiligen Anbindung.
(Um das verschlüsselte Laufwerk von remote zu benutzen, zuerst das Loop-File von remote mounten, und dann darin den verschlüsselten Container von quasi lokal im Loop-Verzeichnis.)
Meine Vermutung ist, wenn das Laufwerk direkt über das Netzwerk gemounted wird, sichert Linux weit häufiger die Daten hoch. Wenn es aber als Loop eingebunden ist, werden die vorhandenen Schreibcache-Möglichkeiten besser ausgenutzt, weil Linux „glaubt“, das wäre ein lokales Device. Aber das ist nur geraten, was genau die Ursache der grottenschlechten Performance für verschlüsselte Remote-Container ist, kann ich nicht sagen.
Doch als Beispiel, worum es geht: Ich hatte neulich das Problem, ein System mit sensiblen Daten auf das Netzwerk zu sichern, Anbindung 1GBit synchron. Zuerst, weil ich zu faul war, habe ich es direkt gelöst – Ausführungsdauer 14 Stunden (für den gesamten Datenbestand, ca. 180GB). Na, das war dann viel zu lang, eine so lange Blockade des Systems konnte ich nicht brauchen; obwohl natürlich nach der Initialisierung immer nur die Differenzen zu sichern sind, aber da ging es trotzdem immer noch um ca. 80GB pro Sicherungslauf. Habe ich also wie oben beschrieben umgestellt, Ergebnis: unter 1 Stunde für den gesamten Datenbestand.
Das ist doch ganz nett für den insgesamt überschaubaren Arbeitsaufwand für die „Loopifizierung“ eines Crypt-Laufwerks… unter Windows tritt übrigens exakt das gleiche Phänomen auf, aber ein Workaround dort ist mir nicht bekannt. Vielleicht geht es mit dem Linux-Subsystem von Windows, aber das habe ich noch nicht ausprobiert, ich weiß nämlich nicht, ob man damit auf alle Daten des darüberliegenden Windows-Hosts kommen kann.
