rsync över ett VPN: vilken sida är källan till sanning?

Två servrar, ett VPN, en katalog som måste finnas på båda ställena och ett kommando som är lätt att köra och svårt att ångra. Bestäm innan du skriver det vilken kopia som är auktoritativ, för varje följande rsync-fråga beror på det svaret. En enkelriktad replik, en delad arbetsmapp och ett arkiv med versionshantering kräver olika regler för ändringar och borttagningar. Tunneln levererar vägen och har ingen åsikt om något av detta.

Bestäm vilken kopia som vinner innan du skriver ett kommando

Skriv ner riktningen i en mening, inklusive värdnamnet och sökvägen på varje sida, och få den godkänd av den som äger data. I den här genomgången är källan /srv/publish/ och målet ett konto på fileserver.example som bara får skriva i /srv/mirror/.

Bekräfta transportfakta före kopian: SSH-värdnyckeln är verifierad, målkontot kan skriva i replikområdet och ingenting annat, och båda värdarna har kompatibla rsync-versioner. Dessa förutsättningar hindrar ett litet planeringsmisstag från att bli en behörighetsincident. De berättar också vilket konto som dyker upp i målets loggar när något går fel.

Förhandsgranska kopian och läs den detaljerade listan

Kör kopian med förhandsgranskningsflaggan först och spara utdata. De detaljerade ändringsraderna berättar vad som skulle hända med varje sökväg, vilket är mycket mer användbart än en slutsammanfattning i efterhand. Spara utdata i ändringsprotokollet så att nästa körning har något att jämföra med.

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

Det avslutande snedstrecket spelar roll. På källan betyder det innehållet i den katalogen, medan om du utelämnar det läggs en extra katalognivå till som namnges efter källan. rsync-handboken dokumenterar båda formerna tillsammans med flaggorna för att bevara metadata, och den uppsättning alternativ du behöver beror på data och inte på vana.

Läs varje rad mot det mål du avsåg. Att ta bort förhandsgranskningsflaggan utför kopian och kan skriva över filer, och utan ett borttagningsalternativ stannar de extra filerna på målet helt enkelt där de är. Det är bara en säker standard om du faktiskt har beslutat att kvarvarande inaktuella filer är acceptabla. Om svaret är nej är borttagningsbeslutet nedan det som ska fattas, inte en extra flagga att strö in i det här kommandot.

Bestäm sedan om borttagningar följer med

Att göra målet till en spegel är ett andra beslut, inte en förfinning av det första. Förhandsgranska det separat, med borttagningsflaggan tillagd och inget annat ändrat, så att skillnaden i listan helt tillhör det beslutet.

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

Borttagningar tar bort överflödiga filer på mottagarsidan inom det synkroniserade omfånget, och därför kan en felaktig källsökväg, en katalog som inte är monterad eller ett filter som utesluter mer än avsett få en destruktiv körning att se ut som en ren spegel. Förhandsgranskningslistan är den enda platsen där skillnaden blir synlig innan den blir dyr. Håll en oberoende återställningskopia där data motiverar det, och kom ihåg att en spegel troget återger en oavsiktlig borttagning i stället för att bevara historik.

En förhandsgranskning låser inte heller något. Människor redigerar filer mellan provkörningen och den verkliga körningen, och filsystem har egna åsikter, så körningen du godkänner och körningen som utförs är inte samma operation såvida inte båda träden är stilla.

Två enkelriktade jobb ger ingen dubbelriktad synkronisering

Att köra samma kommando i båda riktningarna är det vanligaste sättet att förlora data i det här scenariot. Varje riktning behandlar den andra sidan som mål och skriver glatt över nyare innehåll, och borttagningar speglas i den ordning schemat utlöses.

Om användare måste redigera båda kopiorna är det ett annat produktbeslut: konflikthantering, spårning av borttagningar och ett verktyg designat för den modellen. Att approximera det med schemaordning är hur en delad mapp får två versioner av varje dokument som ingen kan förena. Bestäm det uttryckligen i stället för att approximera det med två cron-poster och hoppas.

Automatisera först efter att policyn är skriven

Ett schemalagt jobb bör bära riktningen, sökvägarna, metadatapolicyn och det godkända borttagningsbeslutet. Sätt de fem fakta i själva jobbfilen, inte på en wikisida som nästa administratör kanske aldrig läser. Förhindra överlappande körningar, för två kopior som skriver samma träd samtidigt ger ett tillstånd som ingen av dem avsåg.

När källan är en levande databas eller en annan datauppsättning med flera filer, ta först en applikationskonsistent export eller en samordnad ögonblicksbild. En rekursiv filvandring är ingen transaktion, och en kopia av en föränderlig datauppsättning är inte konsistent.

Registrera slutförande och fel, och kontrollera datauppsättningen på målet i stället för bara slutstatusen. Att återställa VPN efter ett avbrott återställer anslutningen; det säger inget om huruvida den senaste kopian blev klar eller om motstridiga ändringar någonsin löstes.