rsync over eit VPN: kva side er kjelda til sanning?

To tenarar, eitt VPN, éin katalog som må finnast på begge stader, og ein kommando som er lett å køyre og vanskeleg å angre. Før du skriv han, må du avgjere kva kopi som er autoritativ, for kvart påfølgjande rsync-spørsmål heng av det svaret. Ein einvegsreplika, ei delt arbeidsmappe og eit arkiv med versjonskontroll treng ulike reglar for endringar og slettingar. Tunnelen leverer vegen og har inga meining om nokon av dei.

Avgjer kva kopi som vinn før du skriv ein kommando

Skriv ned retninga i éi setning, med vertsnamnet og stien på kvar side, og få henne godkjend av den som eig dataa. I denne gjennomgangen er kjelda /srv/publish/ og målet ein konto på fileserver.example som berre får skrive i /srv/mirror/.

Stadfest transportfakta før kopien: SSH-vertsnøkkelen er verifisert, målkontoen kan skrive i replikaområdet og inkje anna, og begge vertane har kompatible rsync-versjonar. Desse føresetnadene hindrar at ein liten planleggingsfeil blir ei tilgangshending. Dei fortel deg òg kva konto som dukkar opp i loggane til målet når noko går gale.

Førehandsvis kopien og les den detaljerte lista

Køyr kopien med førehandsvisingsflagget først, og ta vare på utdata. Dei detaljerte endringslinjene fortel kva som ville skje med kvar sti, noko som er langt nyttigare enn eit samandrag i etterkant. Legg utdata i endringsprotokollen slik at neste køyring har noko å samanlikne med.

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

Den avsluttande skråstreken betyr noko. På kjelda betyr han innhaldet i den katalogen, medan om du let han vere legg til eit ekstra katalognivå som er kalla opp etter kjelda. rsync-handboka dokumenterer begge formene saman med flagga for å ta vare på metadata, og settet med val du treng, heng av dataa og ikkje av vane.

Les kvar linje mot målet du hadde tenkt. Å fjerne førehandsvisingsflagget utfører kopien og kan skrive over filer, og utan eit sletteval blir dei ekstra filene på målet berre liggjande der dei er. Det er berre den trygge standarden om du faktisk har avgjort at forelda filer som blir liggjande er akseptabelt. Er svaret nei, er sletteavgjerda nedanfor den som skal takast, ikkje eit ekstra flagg du strør inn i denne kommandoen.

Avgjer deretter om slettingar følgjer med

Å gjere målet til eit spegel er ei andre avgjerd, ikkje ein finpuss av den første. Førehandsvis henne for seg, med sletteflagget lagt til og inkje anna endra, slik at skillnaden i lista heilt høyrer til den avgjerda.

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

Slettingar fjernar overflødige filer på mottakarsida innanfor det synkroniserte området, og difor kan ein feil kjedesti, ein katalog som ikkje er montert, eller eit filter som utelukkar meir enn tenkt, få ei destruktiv køyring til å sjå ut som eit reint spegel. Førehandsvisingslista er den einaste staden skillnaden blir synleg før han blir dyr. Hald ein uavhengig gjenopprettingskopi der dataa rettferdiggjer det, og hugs at eit spegel trutt attgjev ei utilsikta sletting i staden for å ta vare på historikk.

Ei førehandsvising låser heller ingenting. Folk redigerer filer mellom prøvekøyringa og den ekte køyringa, og filsystem har eigne meiningar, så køyringa du godkjenner og køyringa som blir utført er ikkje same operasjon med mindre begge trea er stille.

To einvegsjobbar gjev inga tovegssynkronisering

Å køyre den same kommandoen i begge retningar er den vanlegaste måten å miste data på i dette scenariet. Kvar retning behandlar den andre sida som mål og skriv gladeleg over nyare innhald, og slettingar blir spegla i den rekkjefølgja tidsplanen blir utløyst i.

Om brukarar må redigere begge kopiane, er det ei anna produktavgjerd: konflikthandtering, sporing av slettingar og eit verktøy laga for den modellen. Å nærme seg det med rekkjefølgja i tidsplanen er korleis ei delt mappe får to versjonar av kvart dokument som ingen kan sameine. Avgjer det eksplisitt i staden for å nærme deg det med to cron-oppføringar og håpe.

Automatiser først etter at policyen er skriven

Ein planlagd jobb bør bere retninga, stiane, metadatapolicyen og den godkjende sletteavgjerda. Legg desse fem fakta i sjølve jobbfila, ikkje på ei wikiside som neste administrator kanskje aldri les. Hindre overlappande køyringar, for to kopiar som skriv same tre samstundes gjev ein tilstand ingen av dei hadde tenkt seg.

Når kjelda er ein levande database eller eit anna datasett med fleire filer, ta først ein applikasjonskonsistent eksport eller eit koordinert augeblinksbilete. Ein rekursiv filgjennomgang er ikkje ein transaksjon, og ein kopi av eit datasett i endring er ikkje konsistent.

Loggfør fullføring og feil, og kontroller datasettet på målet i staden for berre exit-statusen. Å gjenopprette VPN etter eit avbrot gjenopprettar tilkoplinga; det seier ingenting om den siste kopien vart ferdig eller om motstridande endringar nokon gong vart løyste.