rsync mit --partial

[pr0j3ctx]

Hallo zusammen.

Ich stehe gerade auf dem Schlauch. Kurzer Schwenk, da ich vor kurzem von 50MBit auf 6MBit downgraden musste, ist die Funktion grosse Dateien mit --partial zu synchronisieren für mich interessant geworden.

Mehrmals schon habe ich nun versucht rsync mit folgendem Befehl auszuführen:

rsync -e 'ssh' -ruvP --stats * root@192.168.5.120:/mnt/nas/daten/tmp/

-P in diesem Fall für --partial --progress

Leider werden abgebrochene Dateitransfers nicht fortgesetzt sondern immer wieder neu kopiert. Leider bin ich hier nicht weiter gekommen.
- Liegt es evtl. an der Option über SSH? Muss ein Daemon auf der Gegenseite laufen?
- Oder beisst sich -P mit einer anderen Option?

Für einen Tipp bin ich sehr dankbar.

Schöne Grüße
pr0

[schorschruffneck]

--------------------------------------------------------------------------------------------------------------------------------------------------

[Cae]

Leider werden abgebrochene Dateitransfers nicht fortgesetzt sondern immer wieder neu kopiert.

Woran machst du das fest?

Die Syntax sieht sonst korrekt aus; -e 'ssh' ist redundant, weil Default, sobald user@host:/path/-URIs verwendet werden. Eine Daemon braucht's nicht, der wird bei der "over-SSH"-Variante in der entfernten Shell gestartet und danach wieder beendet. Dieser temporaere Daemon ist nicht ueber einen Socket erreichbar, sondern per stdin/out innerhalb der SSH-Session. Daran sollte es nicht liegen.

Gruss Cae

[pr0j3ctx]

Hallo.

Ich mache es daran fest, das beim erneuten ausführen er wieder bei 0% anfängt.
Das könnte noch normal sein, aber die Geschwindigkeit ist auch nur maximal meine maximale downloadrate.
Es ist nicht so das er dann bis zur letzten Stelle schneller lädt bzw schneller anzeigt.

Hmm oder denke ich falsch.

Grüsse pr0j3ctx

[Cae]

Ich hab' das gerade mal ausprobiert, ein raw-Image von einer Platte ueber NFS in's lokale tmpfs. Dauert lang genug, ist halbwegs langsam, und man kann rumspielen. Meine Beobachtung dabei:

1. ja, er faengt wieder bei 0% an
2. ja, es wird durchgaengig ungefaehr dieselbe Uebertragungsgeschwindigkeit angezeigt, auch nach Abbruch und Wiederaufnahme
3. Nein, die einmal angefangene Datei wird immer groesser

Meine Threorie zum ersten Punkt: Die Platte (remote oder lokal) ist zu lahm. Die einzelnen Chunks muessen auf jeder Seite pruefsummiert werden, um festzustellen, ob man sich den Transfer sparen kann (die Datei koennte sich ja zwischendrin geaendert haben). Dazu passt auch die Beobachtung: Datenuebertragung findet zu diesem Zeitpunkt wenig statt.

Punkt zwei: Das koennte der Plattendurchsatz oder eine "virtuelle Geschwindigkeit" sein, "wieviel man gerade eigentlich transportieren muesste". Keine Ahunung.

Dritter Punkt, sofern rsync hart abgeschossen wird, kann's sein, dass eine Datei foo als .foo.123456 im Zielverzeichnis landet. 123456 ist eine Zufallskombination, wohl von mkstemp(). Moeglicherweise wird der Transfer in diesem Fall nicht mit -P korrekt aufgenommen.

Gruss Cae

[pr0j3ctx]

Hallo.

Deine Theorie klingt logisch. Ehrlich gesagt war mir die Funktion gar nicht so bewusst, da aber auf der Empfangsseite eine Seagate Dockstar (1,2 Ghz Marvell, 128 MB RAM) werkelt, wird wohl hier das Problem liegen.

Ich habe das ganze gerade nochmal getestet. Die Prozessorlast auf der Dockstar schiesst in die Höhe. Das berechnen der Prüfsummen bringt die Dockstar an die Grenze und daher wohl dieser Effekt.

Grundsätzlich ist die Funktion --partial gegeben, aber in diesem Fall nicht sehr effektiv, aufgrund der minimalen Rechenleistung.

vielen Dank und schöne Grüße
pr0

[dimi]

Ich denke da fehlt noch zusätzlich der Schalter --partial-dir mit entsprechendem Verzeichnis oder verwende --inplace anstatt der beiden partial Optionen.

[pr0j3ctx]

Wenn ich das richtig gesehen habe ist --inplace schon in -u enthalten!?!

Grüsse
pr0

[Cae]

Wenn ich das richtig gesehen habe ist --inplace schon in -u enthalten!?!

Noe, siehst du verkehrt. -u ist keine Zusammenfassung fuer --update, --inplace, --append und die weiteren Optionen zusammen.

Code: Alles auswählen

...
        -L, --copy-links            transform symlink into referent file/dir
        -u, --update                skip files that are newer on the receiver
            --inplace               update destination files in-place
            --append                append data onto shorter files
...

-u ist ein Alias fuer --update, genauso -L fuer --copy-links. --inplace und --append haben einfach keine Aliases, die muss man "lang" schreiben. Wenn du unten in der Manpage guckst, wo zu jeder Option noch ein Text steht, findest du da nix von --inplace unter -u.

Gruss Cae

[pr0j3ctx]

Hallo zusammen.

Lange hat mich das Thema noch beschäftigt. Genaugenommen bis gestern. Dann habe ich durch Zufall eine Eingebung gehabt.

rsync -e 'ssh' -ruvP --stats * root@192.168.5.120:/mnt/nas/daten/tmp/

So sah der ursprüngliche Befehl aus, mit dem es nicht klappte. Falsch war nur eine sache. Der Schalter -u.

-u, --update skip files that are newer on the receiver

Da bei einem Abbruch die Dateien im Ziel noch nicht den Original-Zeitstempel haben, sondern den zum Zeitraum des abbruchs, sind diese Files immer neuer und werden nicht mehr angefasst.

-u Weg und alles läuft wie es soll.

Danke für eure Mithilfe und einen schönen Tag.