Dalawang server, isang VPN, isang direktoryo na dapat umiral sa dalawang lugar, at isang utos na madaling patakbuhin at mahirap i-undo. Bago ito i-type, magpasya kung aling kopya ang awtoritatibo, dahil ang bawat susunod na tanong tungkol sa rsync ay nakasalalay sa sagot na iyon. Ang isang-direksiyong replika, shared na working folder at versioned na archive ay nangangailangan ng iba't ibang patakaran para sa mga pagbabago at pagtatanggal. Ang lagusan ay nagbibigay ng daan at walang opinyon sa alinman sa mga ito.

Magpasya kung aling kopya ang mananalo bago mag-type ng utos

Isulat ang direksiyon sa isang pangungusap, kasama ang hostname at landas sa bawat panig, at kunin ang pag-apruba ng may-ari ng data. Sa gabay na ito ang pinagmulan ay /srv/publish/ at ang destinasyon ay isang account sa fileserver.example na pinapayagang magsulat lamang sa /srv/mirror/.

Kumpirmahin ang mga katotohanan ng transportasyon bago ang pagkopya: beripikado ang SSH host key, ang account ng destinasyon ay makakasulat sa replica area at wala nang iba pa, at ang dalawang host ay may magkatugmang bersyon ng rsync. Pinipigilan ng mga paunang kundisyong ito ang maliit na pagkakamali sa pagpaplano na maging insidente sa pahintulot. Sinasabi rin nila kung aling account ang lalabas sa mga log ng destinasyon kapag may naging mali.

I-preview ang kopya at basahin ang detalyadong listahan

Patakbuhin muna ang kopya na may flag ng preview at itago ang output. Sinasabi ng mga detalyadong pagbabago kung ano ang mangyayari sa bawat landas, na mas kapaki-pakinabang kaysa sa buod pagkatapos. Itago ang output sa talaan ng pagbabago upang may maihahambing ang susunod na pagtakbo.

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

Mahalaga ang trailing slash. Sa panig ng pinagmulan, ibig sabihin nito ang nilalaman ng direktoryong iyon, samantalang ang pag-alis nito ay nagdaragdag ng karagdagang antas ng direktoryo na pinangalanan sa pinagmulan. Idinodokumento ng manwal ng rsync ang parehong anyo kasama ang mga flag sa pagpapanatili ng metadata, at ang hanay ng mga opsiyon na kailangan mo ay nakasalalay sa data at hindi sa ugali.

Basahin ang bawat linya laban sa destinasyong nilayon mo. Ang pag-alis ng flag ng preview ay nagsasagawa ng pagkopya at maaaring mag-overwrite ng mga file, at kung walang opsiyon sa pagtatanggal ang labis na mga file na naroon na sa destinasyon ay mananatili lamang kung saan sila naroroon. Ito ay ligtas na default lamang kung talagang nagpasya ka na katanggap-tanggap ang mga lumang file na naiwan. Kung ang sagot ay hindi, ang desisyon sa pagtatanggal sa ibaba ang dapat gawin, hindi isang karagdagang flag na iwawagwag sa utos na ito.

Pagkatapos ay magpasya kung maglalakbay ang mga pagtatanggal

Ang gawing salamin ang destinasyon ay pangalawang desisyon, hindi pagpipino ng una. I-preview ito nang hiwalay, na may idinagdag na flag ng pagtatanggal at walang ibang binago, upang ang pagkakaiba sa listahan ay ganap na pag-aari ng desisyong iyon.

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

Tinatanggal ng mga pagtatanggal ang labis na file sa panig ng tumatanggap sa loob ng naka-sync na saklaw, kaya't ang maling landas ng pinagmulan, isang direktoryong hindi naka-mount o isang filter na nagbubukod ng higit sa nilayon ay maaaring magpamukha ng mapanirang pagtakbo na isang malinis na salamin. Ang listahan ng preview ang tanging lugar kung saan nagiging nakikita ang pagkakaibang iyon bago ito maging magastos. Panatilihin ang isang independiyenteng kopya ng pagbawi kung saan pinangatwiranan ito ng data, at tandaan na matapat na ginagaya ng salamin ang aksidenteng pagtatanggal sa halip na pangalagaan ang kasaysayan.

Wala ring nilo-lock ang preview. Nag-e-edit ang mga tao ng file sa pagitan ng pagsubok at ng tunay na pagtakbo, at may sariling opinyon ang mga filesystem, kaya't ang pagtakbong inaprubahan mo at ang pagtakbong nangyayari ay hindi ang parehong operasyon maliban kung tahimik ang dalawang puno.

Dalawang isang-direksiyong trabaho ay hindi gumagawa ng dalawang-direksiyong sync

Ang pagpapatakbo ng parehong utos sa dalawang direksiyon ang pinakakaraniwang paraan ng pagkawala ng data sa sitwasyong ito. Itinuturing ng bawat direksiyon ang kabilang panig bilang destinasyon at masayang nagsusulat sa ibabaw ng mas bagong nilalaman, at ang mga pagtatanggal ay nasasalamin sa pagkakasunod-sunod na pinapagana ng iskedyul.

Kung kailangang i-edit ng mga gumagamit ang dalawang kopya, iyon ay ibang desisyon sa produkto: paghawak ng salungatan, pagsubaybay sa pagtatanggal at kasangkapan na dinisenyo para sa modelong iyon. Ang pagtatantiya nito sa pagkakasunod-sunod ng iskedyul ang paraan kung paano nagkakaroon ang isang shared folder ng dalawang bersyon ng bawat dokumento na walang makapagkasundo. Magpasya nang tahasan sa halip na tantiyahin ito gamit ang dalawang entry sa cron at pag-asa.

Mag-automate lamang pagkatapos maisulat ang patakaran

Ang naka-iskedyul na trabaho ay dapat magdala ng direksiyon, mga landas, patakaran sa metadata at aprubadong desisyon sa pagtatanggal. Ilagay ang limang katotohanang iyon sa mismong file ng trabaho, hindi sa wiki page na maaaring hindi kailanman basahin ng susunod na administrador. Pigilan ang magkakapatong na pagtakbo, dahil ang dalawang kopya na nagsusulat sa parehong puno nang sabay ay gumagawa ng estado na hindi sinadya ng alinman sa kanila.

Kapag ang pinagmulan ay isang live na database o iba pang multi-file na dataset, kumuha muna ng export na pare-pareho sa application o isang coordinated snapshot. Ang recursive na paglalakad sa file ay hindi transaksyon, at ang kopya ng nagbabagong dataset ay hindi pare-pareho.

Itala ang mga pagkumpleto at pagkabigo, at suriin ang dataset sa destinasyon at hindi lamang ang exit code. Ang pagpapanumbalik ng VPN pagkatapos ng outage ay nagpapanumbalik ng konektibidad; wala itong sinasabi tungkol sa kung natapos ang huling kopya o kung nalutas kailanman ang magkasalungat na pag-edit.

Kaugnay na mga artikulo