rsync oor 'n VPN: watter kant is die bron van waarheid?

Twee bedieners, een VPN, een gids wat op albei plekke moet bestaan, en 'n opdrag wat maklik is om te hardloop en moeilik om ongedaan te maak. Voordat jy dit tik, besluit watter kopie gesaghebbend is, want elke volgende rsync-vraag hang af van daardie antwoord. 'n Eenrigtingreplika, 'n gedeelde werkgids en 'n geargiveerde weergawe benodig verskillende reëls vir wysigings en verwyderings. Die tonnel verskaf die pad en het geen mening oor enige van hulle nie.

Besluit watter kopie wen voordat jy 'n opdrag tik

Skryf die rigting in een sin neer, insluitend die gasheernaam en die pad aan elke kant, en kry dit goedgekeur deur wie die data besit. In hierdie uiteensetting is die bron /srv/publish/ en die bestemming is 'n rekening op fileserver.example wat net in /srv/mirror/ mag skryf.

Bevestig die vervoerfeite voor die kopie: die SSH-gasheersleutel is geverifieer, die bestemmingsrekening kan in die replika-area skryf en nêrens anders nie, en albei gashere het versoenbare rsync-weergawes. Hierdie voorwaardes verhoed dat 'n klein beplanningsfout 'n toestemmingsvoorval word. Hulle sê ook watter rekening in die bestemming se logboeke sal verskyn wanneer iets verkeerd loop.

Voorskou die kopie en lees die gedetailleerde lys

Hardloop die kopie eers met die voorskouvlag en bewaar die uitset. Die gedetailleerde veranderinge sê wat met elke pad sou gebeur, wat baie nuttiger is as 'n voltooiingopsomming agterna. Bewaar die uitset in die veranderingsrekord sodat die volgende lopie iets het om mee te vergelyk.

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

Die sluitende skuinsstreep maak saak. Aan die bronkant beteken dit die inhoud van daardie gids, terwyl die weglating daarvan 'n ekstra gidsvlak byvoeg wat na die bron vernoem is. Die rsync-handleiding dokumenteer albei vorme saam met die vlaggies vir die bewaring van metadata, en die stel opsies wat jy nodig het, hang van die data af en nie van gewoonte nie.

Lees elke reël teen die bestemming wat jy bedoel het. Die verwydering van die voorskouvlag voer die kopie uit en kan lêers oorskryf, en sonder 'n verwyderingsopsie bly die ekstra lêers wat reeds by die bestemming is, net waar hulle is. Dit is net die veilige verstek as jy werklik besluit het dat agtergeblewe verouderde lêers aanvaarbaar is. As die antwoord nee is, is die verwyderingsbesluit hieronder die een wat geneem moet word, nie 'n ekstra vlaggie om in hierdie opdrag te strooi nie.

Besluit dan of verwyderings saamreis

Om die bestemming 'n spieël te maak is 'n tweede besluit, nie 'n verfyning van die eerste nie. Voorskou dit op sy eie, met die verwyderingsvlaggie bygevoeg en niks anders verander nie, sodat die verskil in die lys heeltemal aan daardie besluit behoort.

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

Verwyderings haal oortollige lêers aan die ontvangerkant binne die gesinkroniseerde omvang weg, en daarom kan 'n verkeerde bronpad, 'n gids wat nie gekoppel is nie of 'n filter wat meer uitsluit as wat bedoel is, 'n vernietigende lopie soos 'n skoon spieël laat lyk. Die voorskoulys is die enigste plek waar daardie verskil sigbaar word voordat dit duur word. Hou 'n onafhanklike herstelkopie waar die data dit regverdig, en onthou dat 'n spieël 'n per ongeluk verwydering getrou weergee in plaas van geskiedenis te bewaar.

'n Voorskou sluit ook niks. Mense wysig lêers tussen die proeflopie en die werklike lopie, en lêerstelsels het hul eie mening, dus die lopie wat jy goedkeur en die lopie wat uitgevoer word, is nie dieselfde bewerking nie tensy albei bome stil is.

Twee eenrigtingtake maak nie 'n tweerigting-sinkronisering nie

Om dieselfde opdrag in albei rigtings te hardloop, is die mees algemene manier om data in hierdie scenario te verloor. Elke rigting behandel die ander kant as bestemming en oorskryf vrolik nuwer inhoud, en verwyderings spieël in die volgorde waarin die skedule afgaan.

As gebruikers albei kopieë moet wysig, is dit 'n ander produkbesluit: konflikhantering, die volging van verwyderings en 'n hulpmiddel wat vir daardie model ontwerp is. Om dit met skedulevolgorde te benader, is hoe 'n gedeelde gids twee weergawes van elke dokument kry wat niemand kan versoen nie. Besluit dit uitdruklik eerder as om dit met twee cron-inskrywings en hoop te benader.

Outomatiseer eers nadat die beleid geskryf is

'n Geskeduleerde taak behoort die rigting, die paadjies, die metadata-beleid en die goedgekeurde verwyderingsbesluit te dra. Sit daardie vyf feite in die taaklêer self, nie op 'n wiki-bladsy wat die volgende administrateur dalk nooit sal lees nie. Verhoed oorvleuelende lopies, want twee kopieë wat dieselfde boom gelyktydig skryf, lewer 'n toestand wat nie een van hulle bedoel het nie.

Wanneer die bron 'n lewendige databasis of 'n ander lêerverspreide datastel is, neem eers 'n toepassingskonsistente uitvoer of 'n gekoördineerde momentopname. 'n Rekursiewe lêerwandeling is nie 'n transaksie nie, en 'n kopie van 'n veranderende datastel is nie konsekwent nie.

Teken voltooiings en mislukkings aan, en kontroleer die datastel by die bestemming eerder as net die uitgangstatus. Om die VPN na 'n onderbreking te herstel, herstel die verbinding; dit sê niks oor of die laaste kopie klaar was of of botsende wysigings ooit opgelos is nie.