rsync VPN:n yli: kumpi puoli on totuuden lähde?

Kaksi palvelinta, yksi VPN, yksi hakemisto, jonka on oltava molemmissa paikoissa, ja komento, joka on helppo ajaa ja vaikea perua. Ennen sen kirjoittamista päätä, mikä kopio on valtuutettu, koska jokainen seuraava rsync-kysymys riippuu siitä vastauksesta. Yksisuuntainen replika, jaettu työkansio ja versioitu arkisto tarvitsevat erilaiset säännöt muutoksille ja poistoille. Tunneli tarjoaa polun eikä sillä ole mielipidettä mistään niistä.

Päätä, mikä kopio voittaa, ennen kuin kirjoitat komennon

Kirjoita suunta yhdellä lauseella, mukaan lukien isäntänimi ja polku kummallakin puolella, ja hanki hyväksyntä tiedon omistajalta. Tässä ohjeessa lähde on /srv/publish/ ja kohde on tili palvelimella fileserver.example, jolla saa kirjoittaa vain hakemistoon /srv/mirror/.

Vahvista siirron tosiasiat ennen kopiointia: SSH-isäntäavain on vahvistettu, kohdetili voi kirjoittaa repliikkialueelle eikä muualle, ja molemmilla isännillä on yhteensopivat rsync-versiot. Nämä edellytykset estävät pientä suunnitteluvirhettä muuttumasta käyttöoikeuspoikkeamaksi. Ne kertovat myös, mikä tili näkyy kohteen lokeissa, kun jotain menee pieleen.

Esikatsele kopio ja lue yksityiskohtainen luettelo

Aja kopio ensin esikatselulipulla ja säilytä tuloste. Yksityiskohtaiset muutokset kertovat, mitä kullekin polulle tapahtuisi, mikä on paljon hyödyllisempää kuin jälkikäteen tehty yhteenveto. Tallenna tuloste muutoskirjaan, jotta seuraavalla ajolla on jotain vertailtavaa.

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

Lopun vinoviivalla on merkitystä. Lähteen puolella se tarkoittaa kyseisen hakemiston sisältöä, kun taas sen pois jättäminen lisää ylimääräisen hakemistotason, joka on nimetty lähteen mukaan. rsync-käsikirja dokumentoi molemmat muodot sekä metatietojen säilytysliput, ja tarvitsemasi vaihtoehtojoukko riippuu tiedoista eikä tavasta.

Lue jokainen rivi suhteessa aiottuun kohteeseen. Esikatselulipun poistaminen suorittaa kopioinnin ja voi korvata tiedostoja, ja ilman poistovaihtoehtoa kohteessa jo olevat ylimääräiset tiedostot jäävät yksinkertaisesti paikoilleen. Tämä on turvallinen oletus vain, jos olet todella päättänyt, että taakse jäävät vanhentuneet tiedostot ovat hyväksyttäviä. Jos vastaus on ei, alla oleva poistopäätös on tehtävä, eikä tähän komentoon ole ripoteltava ylimääräistä lippua.

Päätä sitten, kulkevatko poistot mukana

Kohteen muuttaminen peiliksi on toinen päätös, ei ensimmäisen hienosäätö. Esikatsele sitä erikseen, poistolippu lisättynä ja mitään muuta muuttamatta, jotta luettelon ero kuuluu kokonaan sille päätökselle.

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

Poistot poistavat ylimääräiset tiedostot vastaanottavalta puolelta synkronoidun laajuuden sisällä, minkä vuoksi väärä lähdepolku, liittämätön hakemisto tai suodatin, joka jättää pois enemmän kuin on tarkoitettu, voivat saada tuhoisan ajon näyttämään puhtaalta peililtä. Esikatseluluettelo on ainoa paikka, jossa tuo ero tulee näkyväksi ennen kuin siitä tulee kallista. Pidä riippumaton palautuskopio siellä, missä tiedot sen oikeuttavat, ja muista, että peili toistaa vahingossa tehdyn poiston uskollisesti sen sijaan että säilyttäisi historian.

Esikatselu ei myöskään lukitse mitään. Ihmiset muokkaavat tiedostoja kokeilun ja varsinaisen ajon välissä, ja tiedostojärjestelmillä on omat mielipiteensä, joten hyväksymäsi ajo ja toteutuva ajo eivät ole sama toimenpide, elleivät molemmat puut ole hiljaisia.

Kaksi yksisuuntaista työtä ei tee kaksisuuntaista synkronointia

Saman komennon ajaminen molempiin suuntiin on yleisin tapa menettää tietoja tässä skenaariossa. Kumpikin suunta kohtelee toista puolta kohteena ja kirjoittaa iloisesti uudemman sisällön päälle, ja poistot peilautuvat siinä järjestyksessä, jossa aikataulu laukeaa.

Jos käyttäjien on muokattava molempia kopioita, se on toinen tuotepäätös: konfliktien käsittely, poistojen seuranta ja kyseiselle mallille suunniteltu työkalu. Sen lähentäminen aikataulun järjestyksellä on tapa, jolla jaettu kansio saa jokaisesta asiakirjasta kaksi versiota, joita kukaan ei pysty sovittamaan. Päätä se nimenomaisesti sen sijaan, että lähentäisit sitä kahdella cron-merkinnällä ja toivolla.

Automatisoi vasta, kun käytäntö on kirjoitettu

Ajastetun työn pitäisi kantaa suunta, polut, metatietokäytäntö ja hyväksytty poistopäätös. Laita ne viisi tosiasiaa itse työtiedostoon, ei wikisivulle, jota seuraava ylläpitäjä ei ehkä koskaan lue. Estä päällekkäiset ajot, koska kaksi kopiota, jotka kirjoittavat samaan puuhun samanaikaisesti, tuottavat tilan, jota kumpikaan ei tarkoittanut.

Kun lähde on elävä tietokanta tai muu monitiedostoinen tietojoukko, ota ensin sovelluksen kanssa yhdenmukainen vienti tai koordinoitu tilannekuva. Rekursiivinen tiedostojen läpikäynti ei ole transaktio, eikä muuttuvan tietojoukon kopio ole yhdenmukainen.

Kirjaa valmistumiset ja epäonnistumiset ja tarkista tietojoukko kohteessa eikä vain poistumiskoodia. VPN:n palauttaminen katkoksen jälkeen palauttaa yhteyden; se ei kerro mitään siitä, valmistuiko viimeinen kopio tai ratkaistiinko ristiriitaiset muokkaukset koskaan.