rsync bricht bei Übertragung von vielen Dateien ab

[frohike]

Hi,

suche nun schon 2 Tage mit Google und so, hab aber bisher keine passende Lösung für mein Problem finden können. Ich hoffe, dass ich hier an der richtigen Adresse bin :)

Also folgendes: Ich habe einen Windows-Rechner mit rsyncd versehen (http://www.itefix.no/phpws/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=6&MMN_position=23:23) und möchte davon mit meinem debian 4.0 Rechner ein Backup mittels rsnapshot machen. Bin auch schon soweit, dass ich Verzeichnisse problemlos übertragen kann.

Nur: sobald ich ein größeres Verzeichnis (25.000 Dateien, viele Verzeichnisse, 5GB) syncen will, streikt rsync. Ich sehe mit den Optionen -vP dass er die filelist bekommt und das Kopieren der ersten Datei startet - aber bei 0% bleibt es. Keine Fehlermeldung, kein Timeout. Muss die Ausführung abbrechen, sonst ändert sich nichts mehr.

An der konkreten Datei kann es nicht liegen, denn wenn ich nur das betroffene Unterverzeichnis angebe, in der die Datei drinnen liegt, funktioniert alles wunderbar. Das Verzeichnis wird komplett gesynced.

Es ist auch schon passiert, dass mehrere Dateien übertragen wurden bevor der Kopiervorgang abgebrochen ist.

Ich habe die betroffenen Dateien nicht in Verwendung.

Irgendwelche Ideen, woran es liegen könnte dass rsync streikt? Ich stelle auch gerne die Konfigurationsdateien und Logfiles zur Verfügung, wenn es etwas hilft.

Dankbar für jede Hilfe
Frohike (a.k.a. Mark)

[pinpin]

Hi,

ich hab auf Anhieb keine Idee. Welches Windows hast du im Einsatz? Gibt es wirklich keine Fehlermeldungen, weder auf Win noch auf Linux Seite? Hast du probiert rsync ein bisschen gesprächiger zu bekommen?

Gruß Björn

[frohike]

Mein Windows Rechner fährt WinXP Home (Updates werden automatisch eingespielt).
Der Befehl den ich von debian aus absetzte lautet:

/usr/bin/rsync -avvP --delete --numeric-ids --relative --delete-excluded --rsh=/usr/bin/ssh myuser@mywinxpcomputer:/cygdrive/c/path/to/dir /var/path/to/backup

Es werden die Dateien gezählt, danach kommt die Liste der Dateien die uptodate sind. Bei der ersten Datei, die er syncen will steckt der Fortschrittsbalken bei 0%.

Die Option -vv läst rsync alles mögliche ausplaudern - nur nicht warum er steckenbleibt :(

Wenn ich mit Strg+C abbreche, bekomme ich die Meldung

rsync error: unexplained error (code 130) at rsync.c(271) [generator=2.6.9]
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(271) [receiver=2.6.9]
ich nehme an, dass das durch das Abbrechen entsteht.

Im Windows eventlog steht nur, dass der public key akzeptiert wurde.

Wo könnte ich noch wegen Fehlermeldungen nachschauen?

Wie schon vorher erwähnt funktioniert's wenn ich im Quellpfad eine Ebene tiefer gehe.

Neue Information: Sieht so aus, als wäre das Problem im Bereich von cygwin beheimatet. Grund: wenn ich bei rsync --timeout=120 eingebe, bricht er aufgrund dieser Einstellung nach 120 Sekunden lang 0% ab.

Bin trotzdem noch am rätseln, wie ich den Fehler finden und beheben kann.

[rep]

Wie schon vorher erwähnt funktioniert's wenn ich im Quellpfad eine Ebene tiefer gehe.


Wie wäre es denn wenn du mal testweise alle Verzeichnisse die in dem eigentlichen Quellpfad liegen nacheinander mit rsync kopierst. Einfach mal von Hand testen, um wirklich auszuschließen das es nicht eventuell bestimmte Dateien in diesen Datenmengen sind.

So wie ich das sehe, kann man erst dann ausschließen das es nicht an den Daten an sich, und nicht an der Menge liegt.

Aber das nur eine Idee...

[marce]

Die Menge ist's sicher nicht - habe auf einem Linux-System rsyncs laufen, die stündlich über >45000 Dateien mit insges. > 40GB Daten laufen und das völlig problemlos...

[frohike]

Ich glaube das Problem jetzt umschifft zu haben.

Wenn ich rsync nicht über ssh tunnle sondern den rsyncd auf der Gegenseite verwende, dann funktioniert's!!!!!
Ich vermute einfach mal einen Bug im Speichermanagement bei der SSH Implementierung bei cygwin, der bei größeren Datenmengen schlagend wird. Ist aber wirklich nur geraten.

Habe halt das Problem, dass der Datenverkehr unverschlüsselt über die Leitung geht. Aber in Anbetracht dessen dass alles im LAN stattfindet werde ich darüber hinwegsehen.

Die Anbindung des WinXP Rechners hab ich von WLAN auf ETH0 geändert, das hat aber keine Verbesserung gebracht - im Gegenteil: Der Timeout war schon früher (was ich zwar nicht verstehe, aber in Wirklichkeit ist es mir auch egal).

Danke jedenfalls für alle Tipps.