Cryptomator: Frage zu Datentransfer auf NAS

[el.com]

Moin zusammen,

Ich schreibe Backups meiner lokalen Disks auf mein NAS (Synology). Damit die Daten dort nicht unverschlüsselt abgelegt werden, benutze ich Cryptomator. Das Share ist in Windows 11 via SMB3 gemountet und wird in Cryptomator via WinFsp auf einen Laufwerksbuchstaben gemapped.

Das Backup erfolgt über robocopy in einem PowerShell-Script. Beim Robocopy-Aufruf werden Quell- und Zielverzeichnis angegeben (mit diversen Optionen z.B. für Logging).

Bisher habe ich anstatt Cryptomator immer VeraCrypt-Container genutzt, die auf dem NAS lagen. Die statischen Containergrößen waren mir dabei aber schon länger ein Dorn im Auge, weil dadurch unnötig Speicherplatz verschenkt wird (von den Schwierigkeiten der Volume-Vergrößerung von Netzwerk-gehosteten Containern mal ganz zu schweigen). Daher nun der Umstieg auf Cryptomator.

Grundsätzlich funktioniert das Setup auch. Was mich allerdings stutzig macht: Insbesondere beim Schreiben größerer Dateien während des Backups ist im Windows Task Manager und im Synology Resource Monitor zu sehen, dass Daten ungefähr in gleicher Menge gesendet wie auch empfangen werden (siehe beigefügte Screenshots). Das Backup wird aber nur unidirektional geschrieben, d.h. von den lokalen Disks auf das NAS. Normalerweise würde ich also erwarten, dass Windows einen deutlich höheren Upstream als Downstream generiert (und umgekehrt im Synology Resource Monitor). Klar wird beim Hochladen immer auch ein gewisser Downstream erzeugt, aber der beschränkt sich doch normalerweise nur auf den Abgleich von Prüfsummen beim Transfer und sollte daher deutlich geringer sein als der Upload.

Kann sich jemand auf das Verhalten einen Reim machen? Ich kann mir das nur dadurch erklären, dass jedes File beim Upload auch wieder vollständig zurückgelesen wird, um die Integrität abzugleichen. Wenn das stimmt, wäre das aber eine massive Ressourcenverschwendung (denn wofür gibt es Prüfsummen?)

In dem NAS stecken klassische Festplatten. Und die mögen gleichzeitige Schreib- und Lesevorgänge auf dieselben Disks bekanntermaßen nicht so gern (Stichwort Seek Time).

Vllt gibt's hier jemanden der eine Idee hat oder das Verhalten bestätigen kann? Besonders stark ist der Effekt sichtbar bei sehr großen Dateien (z.B. VMware VMDKs).

 

[BFF]

Du schreibst nicht zufaellig doch von NAS auf NAS?

Das Share ist in Windows 11 via SMB3 gemountet und wird in Cryptomator via WinFsp auf einen Laufwerksbuchstaben gemapped.

Wo liegen die verschluesselten Dateien wirklich die robocopy auf den NAS schaufelt?
Irgendwie fehlt mir da was.

Normalerweise würde ich also erwarten, dass Windows einen deutlich höheren Upstream als Downstream generiert (und umgekehrt im Synology Resource Monitor). Klar wird beim Hochladen immer auch ein gewisser Downstream erzeugt, aber der beschränkt sich doch normalerweise nur auf den Abgleich von Prüfsummen beim Transfer und sollte daher deutlich geringer sein als der Upload.

Ist auch so. Seh ich ja bei mir aus so wenn ich meine VM auf den NAS kopieren lasse.
Zu Gegentest kannst Du ja mal mit Robocopy ein paar lokale ISO auf den NAS schaufeln.

 

[el.com]

Wo liegen die verschluesselten Dateien wirklich die robocopy auf den NAS schaufelt?
Irgendwie fehlt mir da was.

Der (verschlüsselte) Cryptomator-Vault liegt auf einem SMB-Share, das ich in Windows ganz normal als Netzwerklaufwerk mounte. Den Vault mounte ich in Cryptomator dann auf einen freien Laufwerksbuchstaben und schreibe dort das Backup rein.

 

[BFF]

Und Robocopy kopiert dann das Verschluesselte.
NAS -> PC -> NAS

Daher der Traffic.

 

[el.com]

Nein. Ich mache kein Backup vom NAS. Nur auf das NAS. Die lokalen Disks im PC (z.B. C:, D:, etc.) werden in den Cryptomator-Vault geschrieben.

Ein Beispielaufruf von einem Robocopy-Job in dem Backupscript:

C:\Windows\System32\Robocopy.exe "C:\Games\" "Z:\Backup\C\Games\" /e /MT /r:3 /w:3 /xj /unilog:"Z:\Backup\C-Games.log" /tee

"Z:" ist dabei der Laufwerksbuchstabe des entsperrten Vaults. Aber das ist ja nur ein virtuelles Loopback-Device. Da steckt keine reale lokale Disk dahinter. Der zugrundeliegende Storage ist das NAS.

//edit

Interessanterweise tritt das Verhalten auch nicht konstant auf, sondern scheinbar nur bei der Übertragung großer Dateien. Der beigefügte Screenshot zeigt das Verhalten während das Script eine Menge kleine Dateien übertragen hat. Da sieht man einen deutlich größeren Upstream als Downstream (wie man es eben auch erwarten würde).

 

[foofoobar]

Interessanterweise tritt das Verhalten auch nicht konstant auf, sondern scheinbar nur bei der Übertragung großer Dateien. Der beigefügte Screenshot zeigt das Verhalten während das Script eine Menge kleine Dateien übertragen hat. Da sieht man einen deutlich größeren Upstream als Downstream (wie man es eben auch erwarten würde).

Möglicherweise liest das Filesystem Daten vorher ein bevor die überschrieben werden.
-> Mit wireshark oder tshark nachschauen.