Linux: rsync zum Spiegeln des SMB-Mount auf die lokale Festplatte ist sehr langsam

Ich versuche, eine über SMB gemountete Freigabe in ein lokales Verzeichnis zu spiegeln. Die Freigabe wird auf einem Windows 2016-Server gehostet, auf den ich keinen Zugriff habe und auf dem ich keine Tools installieren kann. Ich habe also nur eine SMB-Aktie.

Die Freigabe enthält rund 350 GB Daten, meist kleine Dateien (4 MB). Jede Nacht wird ein rsyncJob ausgeführt und alle Updates an ein lokales Verzeichnis übertragen. Dies dauert ewig. Das Senden der inkrementellen Dateiliste dauert ungefähr 10 bis 15 Minuten (ich muss dies überprüfen), aber dann muss rsync ein paar MB (ungefähr 20 Dateien, die pro Nacht geändert werden) satte 12 Stunden übertragen.

Vielleicht habe ich ein Missverständnis darüber, wie es rsyncfunktioniert. Ich habe jedoch den Eindruck, dass nach Erhalt der inkrementellen Dateiliste rsyncherausgefunden werden kann, welche Dateien übertragen werden müssen. Sie müssen also nur noch die geänderten Dateien auswählen und übertragen, was nicht länger als ein paar Minuten bis maximal eine Stunde dauern sollte.

Ich konnte die Übertragungszeit von 12 auf 9 Stunden verkürzen, indem ich die SMB-Freigabe mit actimeo=600Option bereitstellte. Aber es dauert immer noch viel länger als erwartet.

Das ist also der Mount (auf einem Synology NAS):

mount -t cifs //remote.server/share /volume1/sysadmin/share -o vers=3.0,username=john,password='***',domain=EXAMPLE,ro,soft,uid=1026,forceuid,gid=100,forcegid,addr=remote.server,file_mode=0777,dir_mode=0777,iocharset=utf8,nocase,cache=none,noserverino,actimeo=600

Und das ist der rsync-Job:

rsyncOptions=(
    --delete
    --human-readable
    --itemize-changes
    "--modify-window=1"
    --partial
    --protect-args
    --recursive
    --stats
    --times
    --verbose
)
rsyncExclusions=(
    --exclude=.DS_Store
    --exclude=.Trash
    --exclude=.TemporaryItems
    --exclude=._*
    --exclude=.AppleDB
    --exclude=.AppleDouble
    --exclude=__MACOSX
    --exclude=.AppleDesktop
    --exclude=.~lock*
    --exclude=.fseventsd
    --exclude=.lock
    --exclude=.afpDeleted*
    --exclude=.smbdelete*
    --exclude=.TEMP_*
    [email protected]
    --exclude=Thumbs.db
    --exclude='* '
    --exclude='*.'
)
/usr/bin/rsync "${rsyncOptions[@]}" "${rsyncExclusions[@]}" "/volume1/sysadmin/share/" "/volume1/share/

Hier die Statistiken der letzten Synchronisierung:

Number of files: 571170
Number of files transferred: 279
Total file size: 351.95G bytes
Total transferred file size: 387.34M bytes
Literal data: 387.34M bytes
Matched data: 0 bytes
File list size: 25.95M
File list generation time: 0.526 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 413.57M
Total bytes received: 223.89K

sent 413.57M bytes  received 223.89K bytes  13.11K bytes/sec
total size is 351.95G  speedup is 850.56

Wie könnte ich die Übertragung beschleunigen? Vielleicht sind andere Tools wie lftpbesser geeignet, um dies zu erreichen ... Alle Hinweise werden geschätzt.

UPDATE 1

• lftpMit mirror --dry-run --no-perms --exclude-glob="*." --exclude-glob="* " --parallel --only-newerOption dauert die Fertigstellung ebenfalls etwa 9 bis 12 Stunden. Das ist also keine Alternative.

• Eine einfache Kopie in der GUI oder über cpeine 4,7-MB-Datei dauert ca. 2-3 Sekunden.

• Ich habe rsyncmit --dry-runOption begonnen. Ich werde diesen Beitrag aktualisieren, sobald ich die Ergebnisse habe.

UPDATE 2

• rsyncmit --dry-runläuft jetzt seit mehr als 6 stunden. Ich denke, es ist sicher anzunehmen, dass es auch 9 Stunden plus dauern wird. Der einzige Eintrag im Protokoll ist sending incremental file list. Heute ist hier ein Feiertag (daher keine Änderungen an Dateien / Verzeichnissen), daher bin ich mir nicht sicher, wie lange es gedauert hat, diesen Teil des Prozesses abzuschließen.

UPDATE 3

Wenn mehr Protokollierung aktiviert ist, sieht das Ergebnis folgendermaßen aus:

2019/10/04 04:00:03 [20771] building file list
2019/10/04 05:42:16 [20771] .d..t...... dir1/
2019/10/04 05:42:17 [20771] >f+++++++++ dir1/file1
2019/10/04 05:42:44 [20771] .d..t...... dir1/subdir1/
2019/10/04 05:42:44 [20771] >f.st...... dir1/subdir1/file1
2019/10/04 05:43:19 [20771] >f..t...... dir1/subdir1/file2
2019/10/04 05:43:20 [20771] >f.st...... dir1/subdir1/file3
2019/10/04 05:43:20 [20771] .d..t...... dir1/subdir2/
2019/10/04 05:43:21 [20771] >f+++++++++ dir1/subdir2/file1
2019/10/04 10:16:38 [20771] .d..t...... dir2/subdir1/

...

Beachten Sie die enorme Zeitlücke zwischen dir1 und dir2, die entweder rsyncviel Zeit benötigt, um den Verzeichnisbaum zu durchlaufen, oder ich habe etwas anderes vor.

Ich dachte, dass die einzige Möglichkeit, meine Probleme zu lösen, darin bestand, auf beiden Seiten einen Daemon laufen zu lassen. Da ich Cygwin oder WSL nicht auf dem entfernten Windows Server installieren wollte (nicht unter meiner Kontrolle), habe ich Unison verwendet, was bisher einwandfrei funktioniert. Die Synchronisierung dauert jetzt 10-15 Minuten. Verwenden Sie also Unison mit SSH. Ich habe die SSH-Binärdatei aus dem PowerShell-Repository auf GitHub heruntergeladen. Ich hatte also zwei Binärdateien / tragbare Apps, die ich einfach auf den Server legen und zum Laufen bringen konnte. Stellen Sie sicher, dass Sie bei Verwendung von Unison dieselbe Version von Unison und OCAML verwenden.