Wir führen ein Sicherungsskript aus, das eine Datei zuerst an ein Ziel kopiert und dann darüber läuft tar.
DIR2BCK='/foo/bar' TMPDIR=$(mktemp -d) rsync -a $ $/ > /dev/null 2>&1 tar czf /tmp/foo.backup.tar $
Nachdem dieser letzte Befehl ausgeführt wurde, wird manchmal die folgende Warnung angezeigt:
/tmp/tmp.blqspkA136: Datei wurde beim Lesen geändert
Wir kopieren das Ziel genau in ein temporäres Verzeichnis, um Änderungen der Datei während der Komprimierung zu vermeiden. Dieses Verhalten ist auch reproduzierbar, wenn Sie den cpBefehl anstelle von verwenden rsync. Ich habe mein Leben lang geglaubt, dass diese Befehle synchron sind, aber diese Warnung scheint das Gegenteil zu zeigen.
Wenn ich einen sleepBefehl zwischen die Zeilen rsync/ cpund setze tar, wird die Warnung nicht angezeigt, aber ich halte dies für eine nicht ganz saubere Lösung.
Einige Fakten:
Ich habe versucht, einen syncBefehl zwischen den Befehlen rsyncund tarmit demselben Ergebnis einzufügen.
Wie von @jcbermu vorgeschlagen, habe ich auch versucht, das Skript so zu ändern, dass die beiden Zeilen folgende sind:
rsync -a $ $/ > /dev/null 2>&1 & wait
Ich führe das Skript mehrmals aus und einige von ihnen zeigten dasselbe Verhalten und behaupten, dass die Datei beim Kopieren geändert wurde.
Das verwendete Dateisystem ist EXT4 für $und $.
$befindet sich auf einem Remote-Dateisystem, eigentlich ist dies ein Samba-Mountpoint einer Remote-Maschine. $ist im lokalen Dateisystem. Das Wechseln $zum lokalen Dateisystem macht jedoch keinen Unterschied.
Alle Dateisysteme basieren auf Hardware-RAID-5.
Sind diese Befehle tatsächlich synchron? Wenn nicht, gibt es eine Möglichkeit, dies zu tun, oder einen alternativen Befehl?
Ja, diese Befehle werden ausgeführt, wenn sie beendet werden. Sie zitieren keine Datei- / Verzeichnisnamen. Bitte beheben Sie das so schnell wie möglich.
Daniel B vor 6 Jahren
0
@ Danielb mein fehler. Obwohl die Logik dieselbe ist, ist dies nicht der eigentliche Code. Die reale enthält die Zitate.
nKn vor 6 Jahren
0
Nun, vielleicht liegt ein kleiner Fehler im * echten * Code. Oder reicht der obige Code tatsächlich aus, um das Problem zu reproduzieren?
Daniel B vor 6 Jahren
0
Ja, es sollte genug sein, da die Pfade korrekt sind. Das Hauptproblem ist, dass beim Starten von "tar" das Kopieren von "rsync" / "cp" noch nicht beendet ist und die Warnung angezeigt wird. Ich nahm an, dass diese Befehle synchron sind, deshalb bin ich überrascht.
nKn vor 6 Jahren
0
Nehmen Sie nicht an, versuchen Sie es. Andernfalls kann keine qualifizierte Antwort angegeben werden. // `sync` hilft hier nicht. Sie greifen nicht auf Rohdaten auf Geräten zu. // Bitte geben Sie auch an, auf welchen Dateisystemen sich $ TMPDIR und $ DIR2BCK befinden.
Daniel B vor 6 Jahren
0
Befinden sich sowohl $ TMPDIR als auch $ DIR2BCK im selben Dateisystem? oder sind sie separate Laufwerke oder Partitionen? Verwenden Sie normale Festplatten / SSDs oder eine Art RAID?
arielnmz vor 6 Jahren
0
@arielnmz Sie befinden sich auf separaten Dateisystemen. `$ ` ist eigentlich eine Samba-Freigabe auf einem anderen Computer. Dies geschah jedoch auch, wenn beide sich auf demselben Dateisystem befanden. Alle Dateisysteme sind auf RAID5.
nKn vor 6 Jahren
0
2 Antworten auf die Frage
0
jcbermu
Eine Lösung ist, es als neu zu schreiben:
rsync -a $ $/ > /dev/null 2>&1 ; tar czf foo.backup.tar $
Also tarfängt es nicht an bis es rsyncendet.
Die andere Lösung besteht darin, das cp/ rsyncin den Hintergrund zu senden und zu warten, bis es mit dem Befehl endet wait.
Zum Beispiel:
rsync -a $ $/ > /dev/null 2>&1 & wait tar czf foo.backup.tar $
Der letzte &in der rsyncZeile schickt die Ausführung in den Hintergrund (er wird ein Kind der aktuellen Sitzung), und dann waitzwingt diese Shell-Sitzung zu warten, bis alle Kinder fertig sind, um fortzufahren.
Das Problem beim ersten Ansatz ist, dass er dem von mir verwendeten entspricht. Das Aufteilen der beiden Befehle in zwei Zeilen ist das gleiche wie ein Einzeiler mit dem `;` als Trennzeichen. Keiner von ihnen sollte die `tar`-Zeile starten lassen, bis die` rsync` / `cp`-Befehle beendet sind, wenn sie synchron sind, aber in diesem Fall passiert dies nicht. Ich versuche den zweiten Ansatz und komme zurück.
nKn vor 6 Jahren
1
Leider zeigte die von Ihnen vorgeschlagene Änderung in einigen Durchläufen dasselbe Verhalten. Ich bearbeitete meine Frage und fügte diesen Test hinzu.
nKn vor 6 Jahren
0
0
TOOGAM
Ich gebe einen Schlafbefehl zwischen die rsync / cp- und die tar-Zeilen, die Warnung wird nicht angezeigt, aber ich halte dies für eine nicht ganz saubere Lösung.
Gut für dich oder Standards. Was passiert, wenn Sie anstelle von Schlaf Folgendes verwenden:
Sudo Sync; Echo 3 | Sudo tee / proc / sys / vm / drop_caches
Halten Sie das für eine gute Lösung?
Hinweis: / proc / sys / vm / drop_caches scheint das zu sein, was Ubuntu verwendet, und es wird nicht erwartet, dass es ein Ansatz ist, der auf allen Unixen funktioniert (obwohl möglicherweise alle Linuxes). Ich erwähne es, nachdem ich gelesen habehttps://ubuntuforums.org/showthread.php?t=589975 und nachdem ein erster Bericht gelesen wurde, in dem die Sicherheit in Frage gestellt wird, werden weitere Forenbeiträge gelesen, die seine Sicherheit bestätigen.
Ich habe vergessen, in meiner Frage zu erwähnen, aber ich habe den Befehl `sync` bereits ohne Erfolg versucht. Ich habe sowohl ein lokales als auch ein entferntes Dateisystem als Ziel der Kopie ausprobiert, aber das gleiche passiert. Die "drop_caches" sind nicht gut für uns, da wir viele verschiedene Betriebssysteme verwenden (CentOS, Ubuntu, Debian ...).
nKn vor 6 Jahren
0