☰

Sind cp/rsync asynchron?

tag-icon • tag-icon bash rsync tar cp
Sind cp/rsync asynchron?

Wir führen ein Sicherungsskript aus, das zuerst eine Datei an ein Ziel kopiert und dann tardarüber läuft.

DIR2BCK='/foo/bar'
TMPDIR=$(mktemp -d)
rsync -a ${DIR2BCK} ${TMPDIR}/ > /dev/null 2>&1
tar czf /tmp/foo.backup.tar ${TMPDIR}

Nach dem Ausführen dieses letzten Befehls wird manchmal die folgende Warnung angezeigt:

/tmp/tmp.blqspkA136: Datei wurde beim Lesen geändert

Wir kopieren das Ziel in ein temporäres Verzeichnis, um Dateiänderungen zum Zeitpunkt der Komprimierung zu vermeiden. Dieses Verhalten ist auch reproduzierbar, wenn der cpBefehl anstelle von verwendet rsyncwird. Mein ganzes Leben lang dachte ich, diese Befehle wären synchron, aber diese Warnung scheint das Gegenteil zu beweisen.

sleepWenn ich zwischen den rsync/ cpund den Zeilen einen Befehl setze tar, erscheint die Warnung nicht, ich halte das aber für eine nicht ganz saubere Lösung.

Einige Fakten:

  • Ich habe versucht, synczwischen den Befehlen rsyncund einen Befehl einzufügen tar, mit demselben Ergebnis.

  • Wie von @jcbermu vorgeschlagen, habe ich auch versucht, das Skript so zu ändern, dass die beiden Zeilen lauten:

    rsync -a ${DIR2BCK} ${TMPDIR}/ > /dev/null 2>&1 &
wait

    Ich habe das Skript mehrere Male ausgeführt und einige Male zeigte sich das gleiche Verhalten mit der Behauptung, die Datei habe sich beim Kopieren geändert.

  • Das verwendete Dateisystem ist EXT4 sowohl für ${TMPDIR}als auch ${DIR2BCK}.

  • ${DIR2BCK}befindet sich auf einem Remote-Dateisystem. Tatsächlich handelt es sich dabei um einen Samba-Einhängepunkt einer Remote-Maschine. ${TMPDIR}befindet sich auf dem lokalen Dateisystem. Ein Wechsel ${DIR2BCK}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, sie synchron zu machen, oder einen alternativen Befehl?

Antwort1

Eine Lösung besteht darin, es wie folgt umzuschreiben:

rsync -a ${DIR2BCK} ${TMPDIR}/ > /dev/null 2>&1 ; tar czf foo.backup.tar ${TMPDIR}

Also, tares wird nicht beginnen, bis rsynces endet.

cpDie andere Lösung besteht darin, / in den Hintergrund zu schicken rsyncund zu warten, bis es mit dem Befehl endet wait.

Zum Beispiel:

rsync -a ${DIR2BCK} ${TMPDIR}/ > /dev/null 2>&1 &
wait
tar czf foo.backup.tar ${TMPDIR}

Der letzte &in der rsyncZeile schickt die Ausführung in den Hintergrund (es wird einKindder aktuellen Sitzung) und waitzwingt diese Shell-Sitzung dann, mit der Fortsetzung zu warten, bis alle untergeordneten Elemente fertig sind.

Antwort2

Ich habe zwischen den rsync/cp- und den tar-Zeilen einen Sleep-Befehl eingefügt, die Warnung wird zwar nicht angezeigt, halte das aber für eine nicht ganz saubere Lösung.

Gut für Sie 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 ist nicht zu erwarten, dass dieser Ansatz auf allen Unix-Systemen funktioniert (aber vielleicht auf allen Linux-Systemen). Ich erwähne es, nachdem ich Folgendes gelesen habe:https://ubuntuforums.org/showthread.php?t=589975Und nachdem ich einen ersten Bericht gelesen hatte, der die Sicherheit dieser Vorgehensweise in Frage stellte, habe ich weitere Beiträge in Forenthreads gelesen, die die Sicherheit dieser Vorgehensweise bestätigen.

verwandte Informationen