rsync über ein VPN: Welche Seite ist die Quelle der Wahrheit?

Zwei Server, ein VPN, ein Verzeichnis, das an beiden Orten vorhanden sein muss, und ein Befehl, der schnell ausgeführt und schwer rückgängig zu machen ist. Bevor Sie ihn eingeben, sollten Sie entscheiden, welche Kopie maßgeblich ist, denn jede weitere rsync-Frage hängt von dieser Antwort ab. Eine Einweg-Replik, ein gemeinsam genutzter Arbeitsordner und ein versioniertes Archiv brauchen unterschiedliche Regeln für Änderungen und Löschungen. Der Tunnel liefert den Pfad und hat zu all dem keine Meinung.

Entscheiden Sie, welche Kopie gewinnt, bevor Sie einen Befehl eingeben

Schreiben Sie die Richtung in einem Satz auf, einschließlich des Hostnamens und des Pfads auf jeder Seite, und lassen Sie sie von demjenigen bestätigen, dem die Daten gehören. In dieser Anleitung ist die Quelle /srv/publish/ und das Ziel ein Konto auf fileserver.example, das nur in /srv/mirror/ schreiben darf.

Bestätigen Sie die Transportfakten vor der Kopie: Der SSH-Hostschlüssel ist verifiziert, das Zielkonto kann in den Replikationsbereich schreiben und sonst nirgendwo, und beide Hosts haben kompatible rsync-Versionen. Diese Voraussetzungen verhindern, dass ein kleiner Planungsfehler zu einem Berechtigungsvorfall wird. Sie sagen Ihnen auch, welches Konto in den Protokollen des Ziels auftauchen wird, wenn etwas schiefgeht.

Vorschau der Kopie ansehen und die Einzelliste lesen

Führen Sie die Kopie zuerst mit dem Vorschau-Flag aus, und bewahren Sie die Ausgabe auf. Die Einzeländerungen zeigen Ihnen, was mit jedem Pfad passieren würde, was weit nützlicher ist als eine Abschlusszusammenfassung im Nachhinein. Legen Sie die Ausgabe im Änderungsprotokoll ab, damit der nächste Lauf etwas zum Vergleichen hat.

rsync -rt --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

Der abschließende Schrägstrich ist entscheidend. Bei der Quelle bedeutet er den Inhalt dieses Verzeichnisses, während sein Fehlen eine zusätzliche Verzeichnisebene mit dem Namen der Quelle hinzufügt. Das rsync-Handbuch beschreibt beide Formen zusammen mit den Flags zum Erhalt von Metadaten, und der Optionssatz, den Sie brauchen, hängt von den Daten ab und nicht von der Gewohnheit.

Lesen Sie jede Zeile im Hinblick auf das beabsichtigte Ziel. Das Entfernen des Vorschau-Flags führt die Kopie aus und kann Dateien überschreiben, und ohne Löschoption bleiben die zusätzlichen Dateien am Ziel einfach liegen, wo sie sind. Das ist nur dann die sichere Voreinstellung, wenn Sie tatsächlich entschieden haben, dass zurückbleibende veraltete Dateien akzeptabel sind. Wenn die Antwort nein lautet, ist die Löschungsentscheidung weiter unten zu treffen und nicht als zusätzliches Flag in diesen Befehl zu streuen.

Dann entscheiden Sie, ob Löschungen mitwandern

Das Ziel zu einem Spiegel zu machen, ist eine zweite Entscheidung und keine Verfeinerung der ersten. Prüfen Sie sie separat in der Vorschau, mit hinzugefügtem Lösch-Flag und sonst unveränderten Einstellungen, damit der Unterschied in der Liste vollständig zu dieser Entscheidung gehört.

rsync -rt --delete --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/

Löschungen entfernen überzählige Dateien auf der Empfängerseite innerhalb des synchronisierten Bereichs, weshalb ein falscher Quellpfad, ein nicht eingehängtes Verzeichnis oder ein Filter, der mehr ausschließt als beabsichtigt, einen zerstörerischen Lauf wie einen sauberen Spiegel aussehen lassen können. Die Vorschauliste ist der einzige Ort, an dem dieser Unterschied sichtbar wird, bevor er teuer wird. Halten Sie eine unabhängige Wiederherstellungskopie bereit, wo die Daten es rechtfertigen, und denken Sie daran, dass ein Spiegel eine versehentliche Löschung getreu reproduziert, statt Verlauf zu bewahren.

Eine Vorschau sperrt außerdem nichts. Zwischen dem Probelauf und dem echten Lauf bearbeiten Menschen Dateien, und Dateisysteme haben eigene Vorstellungen, sodass der Lauf, den Sie genehmigen, und der Lauf, der ausgeführt wird, nicht dieselbe Operation sind, solange nicht beide Bäume ruhig sind.

Zwei Einweg-Jobs ergeben keine Zwei-Wege-Synchronisierung

Denselben Befehl in beide Richtungen laufen zu lassen, ist der häufigste Weg, in diesem Szenario Daten zu verlieren. Jede Richtung behandelt die andere Seite als Ziel und überschreibt fröhlich neueren Inhalt, und Löschungen spiegeln sich in der Reihenfolge, in der der Zeitplan auslöst.

Wenn Benutzer beide Kopien bearbeiten müssen, ist das eine andere Produktentscheidung: Konfliktbehandlung, Löschungsverfolgung und ein Werkzeug, das für dieses Modell entworfen wurde. Das mit der Reihenfolge von Zeitplänen nachzubauen, führt dazu, dass ein gemeinsamer Ordner von jedem Dokument zwei Versionen bekommt, die niemand zusammenführen kann. Entscheiden Sie es ausdrücklich, statt es mit zwei Cron-Einträgen nachzubauen und zu hoffen.

Automatisieren Sie erst, nachdem die Richtlinie geschrieben ist

Ein geplanter Job sollte die Richtung, die Pfade, die Metadaten-Richtlinie und die genehmigte Löschungsentscheidung mitführen. Legen Sie diese fünf Fakten in der Jobdatei selbst ab, nicht auf einer Wiki-Seite, die der nächste Administrator vielleicht nie liest. Verhindern Sie überlappende Läufe, weil zwei Kopien, die gleichzeitig denselben Baum schreiben, einen Zustand erzeugen, den keine von beiden beabsichtigt hat.

Wenn die Quelle eine laufende Datenbank oder ein anderes mehrteiliges Dataset ist, erstellen Sie zuerst einen anwendungskonsistenten Export oder einen koordinierten Snapshot. Ein rekursiver Dateidurchlauf ist keine Transaktion, und eine Kopie eines sich ändernden Datasets ist keine konsistente.

Protokollieren Sie Abschlüsse und Fehler, und prüfen Sie das Dataset am Ziel statt nur den Exit-Status. Das Wiederherstellen des VPN nach einem Ausfall stellt die Konnektivität wieder her; es sagt nichts darüber aus, ob die letzte Kopie fertig wurde oder ob widersprüchliche Änderungen jemals aufgelöst wurden.