rsync over en VPN: hvilken side er kilden til sandhed?

To servere, ét VPN, én mappe der skal findes begge steder, og en kommando der er let at køre og svær at fortryde. Beslut, før du skriver den, hvilken kopi der er autoritativ, for hvert efterfølgende rsync-spørgsmål afhænger af det svar. En envejsreplika, en delt arbejdsmappe og et arkiv med versionsstyring kræver forskellige regler for ændringer og sletninger. Tunnelen leverer vejen og har ingen mening om nogen af dem.

Beslut hvilken kopi der vinder, før du skriver en kommando

Skriv retningen ned i én sætning, inklusive værtsnavnet og stien på hver side, og få den godkendt af den, der ejer dataene. I denne gennemgang er kilden /srv/publish/, og målet er en konto på fileserver.example, der kun må skrive i /srv/mirror/.

Bekræft transportfakta før kopien: SSH-værtsnøglen er verificeret, målkontoen kan skrive i replikaområdet og intet andet, og begge værter har kompatible rsync-versioner. Disse forudsætninger forhindrer, at en lille planlægningsfejl bliver en tilladelseshændelse. De fortæller dig også, hvilken konto der vises i målets logfiler, når noget går galt.

Forhåndsvis kopien, og læs den detaljerede liste

Kør kopien med forhåndsvisningsflaget først, og gem outputtet. De detaljerede ændringslinjer fortæller, hvad der ville ske med hver sti, hvilket er langt mere nyttigt end et resumesammendrag bagefter. Gem outputtet i ændringsprotokollen, så næste kørsel har noget at sammenligne med.

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

Den afsluttende skråstreg betyder noget. På kilden betyder den indholdet af den mappe, mens hvis du udelader den, tilføjes et ekstra mappeniveau opkaldt efter kilden. rsync-manualen dokumenterer begge former sammen med flagene til at bevare metadata, og det sæt valgmuligheder, du har brug for, afhænger af dataene og ikke af vane.

Læs hver linje op mod det mål, du havde tænkt. Fjernelse af forhåndsvisningsflaget udfører kopien og kan overskrive filer, og uden en sletningsmulighed bliver de ekstra filer på målet bare liggende, hvor de er. Det er kun standarden, der er sikker, hvis du faktisk har besluttet, at forældede filer bagude er acceptable. Er svaret nej, er sletningsbeslutningen nedenfor den, der skal træffes, ikke et ekstra flag, du drysser ind i denne kommando.

Beslut derefter, om sletninger følger med

At gøre målet til et spejl er en anden beslutning, ikke en forfinelse af den første. Forhåndsvis den for sig, med sletningsflaget tilføjet og intet andet ændret, så forskellen i listen helt tilhører den beslutning.

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

Sletninger fjerner overflødige filer på modtagersiden inden for det synkroniserede område, og derfor kan en forkert kildesti, en ikke-monteret mappe eller et filter, der udelukker mere end tilsigtet, få en destruktiv kørsel til at ligne et rent spejl. Forhåndsvisningslisten er det eneste sted, forskellen bliver synlig, før den bliver dyr. Hold en uafhængig gendannelseskopi, hvor dataene berettiger det, og husk, at et spejl trofast gengiver en utilsigtet sletning i stedet for at bevare historik.

En forhåndsvisning låser heller intet. Folk redigerer filer mellem prøvekørslen og den rigtige kørsel, og filsystemer har deres egne meninger, så den kørsel, du godkender, og den kørsel, der udføres, er ikke den samme operation, medmindre begge træer er stille.

To envejsjob giver ikke en tovejssynkronisering

At køre den samme kommando i begge retninger er den mest almindelige måde at miste data i dette scenarie. Hver retning behandler den anden side som mål og overskriver gladeligt nyere indhold, og sletninger spejles i den rækkefølge, som tidsplanen udløses i.

Hvis brugere skal redigere begge kopier, er det en anden produktbeslutning: konflikthåndtering, sporing af sletninger og et værktøj designet til den model. At tilnærme det med tidsplanrækkefølge er måden, hvorpå en delt mappe får to versioner af hvert dokument, som ingen kan forene. Beslut det eksplicit i stedet for at tilnærme det med to cron-poster og håbe.

Automatiser først, når politikken er skrevet

Et planlagt job bør bære retningen, stierne, metadatapolitikken og den godkendte sletningsbeslutning. Læg de fem fakta i selve jobfilen, ikke på en wikiside, som den næste administrator måske aldrig læser. Forhindr overlappende kørsler, for to kopier, der skriver samme træ samtidig, giver en tilstand, som ingen af dem havde til hensigt.

Når kilden er en levende database eller et andet datasæt med flere filer, tag først et applikationskonsistent eksport eller et koordineret øjebliksbillede. En rekursiv filgennemgang er ikke en transaktion, og en kopi af et ændrende datasæt er ikke konsistent.

Registrer fuldførelse og fejl, og kontroller datasættet på målet i stedet for kun slutstatus. At gendanne VPN efter et udfald gendanner forbindelsen; det siger intet om, hvorvidt den sidste kopi blev færdig, eller om modstridende ændringer nogensinde blev løst.