Ich verwende rsync, um über SSH ein Backup auf einem NAS in meinem lokalen Netzwerk zu erstellen. Beim Ausführen von rsync stelle ich jedoch fest, dass es bei bestimmten Dateien hängen bleibt. Rsync friert vollständig ein und weigert sich, weitere Dateien zu übertragen. Ich muss dann ein SIGKILL erzwingen, wodurch der gesamte rsync-Job neu gestartet wird und bei derselben Datei hängen bleibt, die ihn beim letzten Ausführen zum Hängen gebracht hat.
Ich habe verschiedene Lösungen ausprobiert, aber bisher hat keine funktioniert. Ursprünglich dachte ich, es passiert aufgrund eines Problems mit ungültigen Zeichen zwischen meinem lokalen System (OS X 10.11.3 mit OS Extended FS und meinem NAS mit Ubuntu Linux 14.04.1 mit ext4-Laufwerk für das Backup). Mir ist aufgefallen, dass, wenn rsync bei einer Datei hängen bleibt, der Dateiname oder Pfad in 9 von 10 Fällen ein „&“ enthält.
Nachdem ich jedoch die rsync-Prozesse mit lsofund htopauf dem Server beobachtet habe, sieht es so aus, als ob rsync (meistens, aber nicht immer) ungefähr an der gleichen Stelle abstürzt, an der die rsync-Datei vom Client hängen bleibt. Mir ist jedoch aufgefallen, dass ich, selbst wenn rsync auf der Clientseite hängen bleibt, immer noch eine Ausgabe erhalte, die anzeigt, lsofdass auf die Dateien auf der Serverseite zugegriffen wird.
Dies ist der rsync-Befehl, den ich verwende.
/usr/bin/rsync --bwlimit=1000 --verbose --rsync-path="sudo rsync" --archive --recursive --numeric-ids --human-readable --partial --progress --relative --itemize-changes --stats --files-from=/Users/user/Dropbox/Flex/Scripts/mac/rysnc-backup-to-cp/config/backup_files --exclude-from=/Users/user/Dropbox/Flex/Scripts/mac/rysnc-backup-to-cp/config/exclude -e "ssh -q -p 22 -i /Users/enwhat/.ssh/user" / [email protected]:/media/Backup/_Backup/Machine/
Beispiel, wo rsync normalerweise hängen bleibt:
<f+++++++ Volumes/Data/Users/user1/Pictures/2013_12_iPhone_Archive/IMG_6993.m4v 17.33M 63% 994.25kB/s 0:00:10
oder
<f+++++++ Volumes/Data/Users/user1/Documents/docs/Work/_Sort from USB backup drive/Drive/JOB/CD Album/AAA1834__Album&flyer_15_Years/2-Design/1-D-Visuals/stage 05/AAA_album_12_c.psd 96.40M 50% 1.55MB/s 0:01:00
Ich habe versucht, --verbose --rsync-path="sudo rsync” --delete-duringalle einzeln zu entfernen. Wenn ich diese Argumentflags entferne, gelangt der rsync-Prozess zu einer bestimmten Datei und bleibt dann hängen.
Spielt hier noch etwas anderes eine Rolle oder ist es sehr wahrscheinlich, dass ein ungültiges Zeichen im Dateinamen ein Problem zwischen FS-Typen verursacht?
Ich dachte, dass Crashplan, das auf dem Server läuft, möglicherweise zu viele Ressourcen verbraucht und rsync zum Absturz bringt. Aber wenn ich den CrashPlan-Dienst auf dem Server stoppe, werden zwar Ressourcen freigegeben, aber rsync stürzt immer noch bei denselben Dateien ab. Dies ist eine Randbemerkung und geht über den Rahmen der Frage hinaus, aber ich frage mich, ob ich Crashplan aufgeben und zu Amazon Glacier als Backup-Dienst wechseln sollte, da Crashplan viel CPU und Speicher verbraucht.
Antwort1
Ich weiß nicht, warum rsync hängen bleibt. Sie könnten versuchen, eine normale Kopie über diesen Verzeichnisbaum auszuführen und zu prüfen, ob ein E/A-Fehler irgendeiner Art vorliegt. Eine Dateisystemprüfung durchzuführen wäre keine schlechte Idee.
Was Amazon Glacier betrifft, ja, das können Sie verwenden. Duplicity unterstützt S3 als Backup-Ziel und die Lebenszyklusregeln von S3 ermöglichen es Ihnen, die Dateien automatisch nach Glacier zu verschieben (Konfiguration über die S3-Webkonsole). Sie müssen die Signatur- und Manifestdateien in S3 behalten (sonst kann Duplicity sie nicht abrufen), aber die Volumedateien werden nur benötigt, wenn Sie gesicherte Dateien extrahieren müssen, damit sie sicher in Glacier gespeichert werden können. Die Lebenszyklusregeln erfordern ein bekanntes Präfix, was nicht das Standardverhalten von Duplicity ist. Überprüfen Sie daher unbedingt die Parametereinstellungen.