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

To servere, ett VPN, én katalog som må finnes på begge steder, og en kommando som er lett å kjøre og vanskelig å angre. Før du skriver den, må du bestemme hvilken kopi som er autoritativ, for hvert påfølgende rsync-spørsmål avhenger av det svaret. En enveisreplika, en delt arbeidsmappe og et arkiv med versjonskontroll trenger ulike regler for endringer og slettinger. Tunnelen leverer veien og har ingen mening om noen av dem.

Bestem hvilken kopi som vinner før du skriver en kommando

Skriv ned retningen i én setning, med vertsnavnet og stien på hver side, og få den godkjent av den som eier dataene. I denne gjennomgangen er kilden /srv/publish/ og målet en konto på fileserver.example som bare får skrive i /srv/mirror/.

Bekreft transportfakta før kopien: SSH-vertsnøkkelen er verifisert, målkontoen kan skrive i replikaområdet og ingenting annet, og begge vertene har kompatible rsync-versjoner. Disse forutsetningene hindrer at en liten planleggingsfeil blir en tilgangshendelse. De forteller deg også hvilken konto som dukker opp i målets logger når noe går galt.

Forhåndsvis kopien og les den detaljerte listen

Kjør kopien med forhåndsvisningsflagget først, og ta vare på utdataene. De detaljerte endringslinjene forteller hva som ville skje med hver sti, noe som er langt mer nyttig enn et sammendrag i etterkant. Legg utdataene i endringsprotokollen slik at neste kjøring har noe å sammenligne med.

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

Den avsluttende skråstreken betyr noe. På kilden betyr den innholdet i den katalogen, mens hvis du utelater den, legges et ekstra katalognivå til som er oppkalt etter kilden. rsync-håndboken dokumenterer begge formene sammen med flaggene for å bevare metadata, og settet med alternativer du trenger, avhenger av dataene og ikke av vane.

Les hver linje mot målet du hadde tenkt. Å fjerne forhåndsvisningsflagget utfører kopien og kan overskrive filer, og uten et slettealternativ blir de ekstra filene på målet bare liggende der de er. Det er bare den trygge standarden hvis du faktisk har bestemt at foreldede filer som blir igjen er akseptabelt. Er svaret nei, er slettebeslutningen nedenfor den som skal tas, ikke et ekstra flagg du strør inn i denne kommandoen.

Avgjør deretter om slettinger følger med

Å gjøre målet til et speil er en andre beslutning, ikke en finpuss av den første. Forhåndsvis den for seg, med sletteflagget lagt til og ingenting annet endret, slik at forskjellen i listen helt tilhører den beslutningen.

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

Slettinger fjerner overflødige filer på mottakersiden innenfor det synkroniserte området, og derfor kan en feil kildesti, en katalog som ikke er montert, eller et filter som utelukker mer enn tenkt, få en destruktiv kjøring til å se ut som et rent speil. Forhåndsvisningslisten er det eneste stedet forskjellen blir synlig før den blir dyr. Hold en uavhengig gjenopprettingskopi der dataene berettiger det, og husk at et speil trofast gjengir en utilsiktet sletting i stedet for å bevare historikk.

En forhåndsvisning låser heller ingenting. Folk redigerer filer mellom prøvekjøringen og den ekte kjøringen, og filsystemer har egne meninger, så kjøringen du godkjenner og kjøringen som utføres er ikke samme operasjon med mindre begge trærne er stille.

To enveisjobber gir ingen toveissynkronisering

Å kjøre den samme kommandoen i begge retninger er den vanligste måten å miste data på i dette scenariet. Hver retning behandler den andre siden som mål og overskriver gladelig nyere innhold, og slettinger speiles i den rekkefølgen tidsplanen utløses.

Hvis brukere må redigere begge kopiene, er det en annen produktbeslutning: konflikthåndtering, sporing av slettinger og et verktøy laget for den modellen. Å tilnærme seg det med rekkefølgen på tidsplanen er hvordan en delt mappe får to versjoner av hvert dokument som ingen kan forene. Bestem det eksplisitt i stedet for å tilnærme deg det med to cron-oppføringer og håpe.

Automatiser først etter at policyen er skrevet

En planlagt jobb bør bære retningen, stiene, metadatapolicyen og den godkjente slettebeslutningen. Legg disse fem fakta i selve jobbfilen, ikke på en wikiside som neste administrator kanskje aldri leser. Hindre overlappende kjøringer, for to kopier som skriver samme tre samtidig gir en tilstand ingen av dem hadde tenkt seg.

Når kilden er en levende database eller et annet datasett med flere filer, ta først et applikasjonskonsistent eksport eller et koordinert øyeblikksbilde. En rekursiv filgjennomgang er ikke en transaksjon, og en kopi av et datasett i endring er ikke konsistent.

Loggfør fullføring og feil, og kontroller datasettet på målet i stedet for bare exit-statusen. Å gjenopprette VPN etter et avbrudd gjenoppretter tilkoblingen; det sier ingenting om hvorvidt den siste kopien ble ferdig eller om motstridende endringer noen gang ble løst.