rsync-Verwirrungen

S

s24!

Registered User
Guten Abend,

momentan muss ich zwei Server synchronisieren. Dies tue ich so:
Code: 
rsync --delete -aPe ssh /ordner [email protected]:/ordner

Nun ist es so, dass ich eben noch Kompression (-z) angeschaltet hatte. Das erschien mir aber (gerade bei vielen kleinen Dateien unter 100 KB bei 100 MBit/s und einem langsamen "Quellserver") langsamer als ohne Kompression.

Also habe ich den rsync erneut aufgerufen - und er hat zumindest einige Dateien kopiert, die meiner Erinnerung nach (keine Garantie!) schon kopiert wurden - also etwas unsinnig meiner Meinung nach. Geht rsync nicht alphabetisch vor? Wenn ja, würde es das vielleicht schon erklären.

Dann hätte ich dennoch noch eine Frage: Der Parameter -u sorgt nach meinem Verständnis aus der manpage dafür, dass Dateien, die auf dem Zielsystem bereits in neuerer Form vorhanden sind, nicht kopiert werden. Das kann ja bei einem Kopieren auf einen Server, auf dem nichts geändert wird, gar nicht passieren.

Aus Posts in diversen Foren geht für mich hervor, dass man diesen Parameter dazu benutzt, um bereits synchronisierte Dateien nicht neu zu übertragen. Sehe ich es richtig, dass das schlichtweg falsch ist? ;)


Grüße
 
Sorry, ich hatte das eben aus dem Kopf getippt. Natürlich mache ich das in Wahrheit anders. :D

Grüße
 
Soweit ich weiß, deaktiviert der Optionsschalter -u den Check mit MD5. D.h. sollte deine Datei korrupt sein und das Datum Unterscheidet sich nicht, wird sie nicht aktualisiert.

Die Abgleich geht zwar mit -u schneller, ist aber auch nicht so sicher.
 
Ja, hast recht. Laut manpage:
Code: 
-c, --checksum              skip based on checksum, not mod-time & size
-u, --update                skip files that are newer on the receiver

Im Endeffekt ist -u schneller, da für diese Dateien erst gar kein Hash errechnet werden muss. In Kombination mit -c wäre es um einiges schneller, aber auch unsicherer.
 
Ich habe das jetzt einfach mal ausprobiert und scheinbar werden mit -u keine Daten abgeglichen, die auf dem Ziel bereits vorhanden sind. Also diese Dateien werden einfach übergangen - das bringt mich ja nur begrenzt weiter. :D

Grüße
 
Was ist an "skip files that are newer on the receiver" nicht zu verstehen?

rsync synchronisiert prinzipiell mal von Quelle nach Ziel - und zwar in Abhängigkeit ob die Dateien aufgrund der Metadaten im Filesystem unterschiedlich sind (also Timestamp, Größe, Berechtigungen, ...).

Synchronisieren bedeutet auch "downgrade", also neuere Datei am Zielsystem mit älterer Datei vom Quellsystem zu überschreiben.

Gelöscht wird ohne --delete aber nichts.

-u forciert, dass nicht "downgegraded" wird, sondern nur Dateien mit neuerem Zeitstemptel jene mit älterem ersetzen dürfen und nicht umgekehrt.

-c für checksum prüft tatsächlich noch, ob sich Inhalte unterscheiden und synchronisiert so auch solche Dateien, die augenscheinlich aufgrund der Metadaten des Filesystems auf den ersten Blick identisch aussehen würden.

Ob die Kompression was bringt hängt von unterschiedlichen Faktoren ab. Wenn Du ohnehin über SSH synchronisierst ist in der SSH bei gängiger Konfiguration ohnehin auch eine Kompression aktiv. Dass RSYNC ohnehin immer nur die Deltas überträgt sollte bekannt sein.
 
Code: 
 -c, --checksum              skip based on checksum, not mod-time & size
Ist etwas irrführend, aber tatsächlich werden mit -c oder besser --checksum die Hashwerte errechnet. Das könnte etwas länger dauern.

Wenn Du ohnehin über SSH synchronisierst ist in der SSH bei gängiger Konfiguration ohnehin auch eine Kompression aktiv.
Click to expand...

Was bedeutet für dich eine gängige Konfiguration? Bei Debian ist es in der standard ssh_config nicht definiert. Ich weiß jetzt nicht, wie es in anderen Distributionen aussieht.
 
Danke fürs nachschlagen in der man-page.
Somit muss ich mich wohl korrigieren, hab von meiner Konfiguration fälschlicherweise auf den Default geschlossen.
 
You must log in or register to reply here.
Back
Top