rsync over een VPN: welke kant is de bron van waarheid?
Een tunnel geeft u een pad, geen samenvoegbeleid. Kies de gezaghebbende kopie, bekijk de eenrichtingskopie als voorbeeld en beslis daarna apart of verwijderingen meereizen.
Twee servers, één VPN, één map die op beide plekken moet bestaan, en een commando dat makkelijk te draaien en moeilijk terug te draaien is. Bepaal voordat u het typt welke kopie gezaghebbend is, want elke volgende rsync-vraag hangt van dat antwoord af. Een eenrichtingsreplica, een gedeelde werkmap en een archief met versiebeheer vragen verschillende regels voor wijzigingen en verwijderingen. De tunnel levert het pad en heeft over geen daarvan een mening.
Bepaal welke kopie wint voordat u een commando typt
Schrijf de richting in één zin op, inclusief de hostnaam en het pad aan elke kant, en laat die bevestigen door wie de gegevens bezit. In deze uitleg is de bron /srv/publish/ en de bestemming een account op fileserver.example dat alleen in /srv/mirror/ mag schrijven.
Bevestig de transportfeiten vóór de kopie: de SSH-hostsleutel is geverifieerd, het doelaccount kan in het replicagebied schrijven en nergens anders, en beide hosts hebben compatibele rsync-versies. Die voorwaarden voorkomen dat een kleine planningsfout een rechtenincident wordt. Ze vertellen u ook welk account in de logboeken van de bestemming verschijnt als er iets misgaat.
Bekijk de kopie als voorbeeld en lees de detaillijst
Draai de kopie eerst met de voorbeeldvlag en bewaar de uitvoer. De detailregels vertellen u wat er met elk pad zou gebeuren, wat veel nuttiger is dan een samenvatting achteraf. Bewaar de uitvoer in het wijzigingsrecord, zodat de volgende run iets heeft om mee te vergelijken.
rsync -rt --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/
De afsluitende schuine streep is belangrijk. Bij de bron betekent die de inhoud van die map, terwijl weglaten ervan een extra mapniveau toevoegt dat naar de bron is genoemd. De rsync-handleiding beschrijft beide vormen samen met de vlaggen voor het behouden van metadata, en de set opties die u nodig hebt hangt af van de gegevens en niet van gewoonte.
Lees elke regel tegen de bestemming die u bedoelde. Het verwijderen van de voorbeeldvlag voert de kopie uit en kan bestanden overschrijven, en zonder verwijderoptie blijven de extra bestanden op de bestemming gewoon staan waar ze staan. Dat is alleen de veilige standaard als u daadwerkelijk hebt besloten dat achterblijvende verouderde bestanden aanvaardbaar zijn. Is het antwoord nee, dan is de verwijderbeslissing hieronder aan de orde, niet een extra vlag die u in dit commando strooit.
Beslis daarna of verwijderingen meereizen
De bestemming tot een spiegel maken is een tweede beslissing, geen verfijning van de eerste. Bekijk die apart als voorbeeld, met de verwijderflag toegevoegd en verder niets gewijzigd, zodat het verschil in de lijst volledig bij die beslissing hoort.
rsync -rt --delete --dry-run --itemize-changes -e ssh -- /srv/publish/ [email protected]:/srv/mirror/
Verwijderingen ruimen overtollige bestanden aan de ontvangende kant op binnen het gesynchroniseerde bereik, en daarom kunnen een verkeerd bronpad, een niet-aangekoppelde map of een filter dat meer uitsluit dan bedoeld een destructieve run op een schone spiegel laten lijken. De voorbeeldlijst is de enige plek waar dat verschil zichtbaar wordt voordat het duur wordt. Houd een onafhankelijke herstelkopie aan waar de gegevens dat rechtvaardigen, en bedenk dat een spiegel een per ongeluk verwijdering trouw reproduceert in plaats van geschiedenis te bewaren.
Een voorbeeld vergrendelt ook niets. Mensen bewerken bestanden tussen de proefrun en de echte run, en bestandssystemen hebben eigen meningen, dus de run die u goedkeurt en de run die wordt uitgevoerd zijn niet dezelfde bewerking tenzij beide bomen stil zijn.
Twee eenrichtingstaken maken nog geen tweerichtingssynchronisatie
Hetzelfde commando in beide richtingen draaien is de meest voorkomende manier om in dit scenario gegevens te verliezen. Elke richting behandelt de andere kant als bestemming en overschrijft vrolijk nieuwere inhoud, en verwijderingen spiegelen in de volgorde waarin het schema afgaat.
Als gebruikers beide kopieën moeten bewerken, is dat een andere productbeslissing: conflictbehandeling, het volgen van verwijderingen en een hulpmiddel dat voor dat model is ontworpen. Dat benaderen met de volgorde van het schema is hoe een gedeelde map van elk document twee versies krijgt die niemand kan verzoenen. Beslis het expliciet in plaats van het met twee cron-regels te benaderen en te hopen.
Automatiseer pas nadat het beleid is geschreven
Een geplande taak hoort de richting, de paden, het metadatabeleid en de goedgekeurde verwijderbeslissing mee te dragen. Zet die vijf feiten in het taakbestand zelf, niet op een wikipagina die de volgende beheerder misschien nooit leest. Voorkom overlappende runs, want twee kopieën die tegelijk dezelfde boom schrijven leveren een toestand op die geen van beide bedoelde.
Als de bron een live database of een andere dataset met meerdere bestanden is, maak dan eerst een toepassingsconsistente export of een gecoördineerde momentopname. Een recursieve bestandswandeling is geen transactie, en een kopie van een veranderende dataset is geen consistente.
Leg voltooiing en fouten vast, en controleer de dataset op de bestemming in plaats van alleen de exitstatus. Het VPN herstellen na een storing herstelt de verbinding; het zegt niets over of de laatste kopie klaar was of of conflicterende bewerkingen ooit zijn opgelost.