☰

Warum sendet rsync bei jedem Aufruf dieselben Dateien?

tag-icon • tag-icon linux macos ssh backup rsync
Warum sendet rsync bei jedem Aufruf dieselben Dateien?

Ich verwende rsync, um Dateien über SSH von Linux auf den Mac zu kopieren.

Mein Befehl sieht folgendermaßen aus:

rsync \
    --exclude FOO \
    --exclude BAR \
    -e ssh \
    -rclpvih \
    --delete \
    --stats \
    /local/dir/ \
    host:/remote/dir/

Und die Ausgabe sieht folgendermaßen aus:

building file list ... done
...
<fc.T...... core/FileRecordingProcessor.cpp
<fc.T...... core/Pipeline.hpp
...

Number of files: 4,910 (reg: 4,401, dir: 509)
Number of created files: 0
Number of regular files transferred: 35
Total file size: 332.34M bytes
Total transferred file size: 2.62M bytes
Literal data: 0 bytes
Matched data: 2.62M bytes
File list size: 196.59K
File list generation time: 0.457 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 209.72K
Total bytes received: 12.03K

sent 209.72K bytes  received 12.03K bytes  147.83K bytes/sec
total size is 332.34M  speedup is 1,498.70

Auch wenn sich lokal nichts geändert hat, überträgt rsync bei jedem Aufruf die gleiche (Teil-)Menge an Dateien.

Diese Dateien sind nur eine kleine Teilmenge des gesamten Baums. Andere Dateien werden nicht erneut gesendet, es sei denn, sie werden wirklich geändert. Die Anzahl der erneut gesendeten Dateien beträgt immer 35. Alle von ihnen haben <fc.T......Flags.

Die Dateien sehen auf lokalen und Remote-Rechnern identisch aus.

Lokal:

$ ll core/Pipeline.hpp
-rw-r--r-- 1 victor victor 5.1K Nov  2 18:24 core/Pipeline.hpp
$ md5sum core/Pipeline.hpp
7604940d777322a587d2fe2fa12c1183  core/Pipeline.hpp

Fernbedienung:

$ ll core/Pipeline.hpp
-rw-r--r-- 1 victor staff 5.1K Nov  3 18:20 core/Pipeline.hpp
$ md5sum core/Pipeline.hpp
7604940d777322a587d2fe2fa12c1183  core/Pipeline.hpp

Besitzer, Gruppe und Zeiten sind nicht gleich, aber rsync ist nicht so konfiguriert, dass sie erhalten bleiben, sondern so, dassPrüfsummen verwenden.

Die Uhrzeit auf den beiden Rechnern ist nicht synchronisiert.

Antwort1

Dies kann beispielsweise passieren, wenn rsync Dateien zwischen einem Dateisystem mit Groß- und Kleinschreibung (normalerweise Linux) und einem Dateisystem ohne Groß- und Kleinschreibung (normalerweise Windows und MacOS) überträgt.

Wenn die beiden synchronisierten Pfade (z. B. d/xund d/X) nach der theoretischen Konvertierung in beispielsweise Kleinbuchstaben gleich sind, bemerkt rsync dies nicht und überträgt möglicherweise und d/xüberschreibt dann dieselbe Zieldatei mit d/X.

Wenn die Dateien nicht dieselben Daten enthalten und nicht denselben Zeitstempel haben, werden die Dateien bei zukünftigen rsync-Läufen immer aktualisiert.

Ich schlage vor, zu prüfen, ob ein Unterschied zwischen Groß- und Kleinschreibung dazu führt, dass rsync die Dateien versehentlich erneut überträgt. Ein nützlicher Linux-Befehl ist:

find . | tr '[:upper:]' '[:lower:]' | LC_ALL=C sort | LC_ALL=C uniq -d

Quelle

Antwort2

Ihnen fehlen entweder die Flags --archive( -a) oder --times( -t). Ohne eines dieser Flags rsyncwird die Änderungszeit nicht verfolgt und es können daher keine Dateien umgangen werden, die aussehen, als wären sie bereits kopiert worden

Sie weisen auch ausdrücklich darauf hin, rsyncdass Prüfsummen verwendet werden sollen, um zu bestätigen, dass die Dateien kopiert wurden. Und genau das rsyncgeschieht.

Im Allgemeinen erledigt das Flag --archive( ) so ziemlich alles, was Sie brauchen:-a

rsync --exclude FOO --exclude BAR -avi --delete --stats /local/dir/ host:/remote/dir/

Möglicherweise möchten Sie -HHardlinks (sofern vorhanden) und -AXACLs und erweiterte Attribute (sofern vorhanden) beibehalten.

Antwort3

TL;DR: Wenn Sie macOS verwenden, versuchen Sie, /usr/bin/rsync anstelle des Open-Source-Rsync zu verwenden, das möglicherweise von „brew“ oder „nix“ oder anderen Systemen installiert wird. Das native Rsync versteht Apples spezielles Dateisystem besser und kopiert unveränderte Dateien nicht erneut.

Längere Version...

Dies kann beispielsweise passieren, wenn die von rsyncIhnen verwendete Version betriebssystemspezifische Situationen nicht unterstützt. Dateien, von denen angenommen wird, dass sie sich geändert haben, dies aber nicht der Fall ist, werden erneut kopiert.

Auf meinem Mac gibt es beispielsweise zwei Versionen von rsync:

$ which -a rsync
/usr/local/bin/rsync
/usr/bin/rsync

/usr/local/bin/rsyncist Version 3.2.4, die Protokollversion 31 unterstützt. Ich habe dies mit „brew“ installiert.

/usr/bin/rsyncist die von Apple bereitgestellte Version, die aus der (deutlich älteren) Version 2.6.9 hervorgegangen ist und die Protokollversion 29 unterstützt. Apple hat diese Version erweitert, um macOS-spezifische Dateisystemfunktionen zu unterstützen.

Wenn ich -cdie Open-Source-Version verwende, werden Dateien erneut kopiert, die sich nicht geändert haben. Das von Apple bereitgestellte rsync hat dieses Problem nicht.

Obwohl es zwischen den Protokollversionen 29 und 31 viele Optimierungen gibt, werden Sie diese wahrscheinlich nicht vermissen. Es ist wahrscheinlich wichtig, die Dinge mithilfe von Apples rsync richtig zu machen.

Antwort4

Ich wechselte schließlich zuEinklangzur Synchronisierung zwischen Linux und macOS (und Windows):

unison \
    -servercmd /usr/local/bin/unison
    -ignore "Name FOO" \
    -ignore "Name BAR" \
    -auto \
    -batch \
    -force /local/dir/ \
    /local/dir/ \
    ssh://host/remote/dir/

verwandte Informationen