rsync përmes një VPN: cila anë është burimi i së vërtetës?

Dy serverë, një VPN, një drejtori që duhet të ekzistojë në të dyja vendet dhe një komandë që është e lehtë për t'u ekzekutuar dhe e vështirë për t'u zhbërë. Përpara se ta shkruani, vendosni cila kopje është autoritative, sepse çdo pyetje e mëvonshme për rsync varet nga ai përgjigje. Një replikë njëdrejtimëshe, një dosje pune e përbashkët dhe një arkiv me versione kërkojnë rregulla të ndryshme për ndryshimet dhe fshirjet. Tuneli ofron rrugën dhe nuk ka mendim për asnjërën prej tyre.

Vendosni cila kopje fiton përpara se të shkruani një komandë

Shkruani drejtimin në një fjali, duke përfshirë emrin e hostit dhe shtegun në secilën anë, dhe merrni miratimin e pronarit të të dhënave. Në këtë udhëzues burimi është /srv/publish/ dhe destinacioni është një llogari në fileserver.example që lejohet të shkruajë vetëm në /srv/mirror/.

Konfirmoni faktet e transportit përpara kopjimit: çelësi i hostit SSH është verifikuar, llogaria e destinacionit mund të shkruajë në zonën e replikës dhe askund tjetër, dhe të dy hostet kanë versione rsync të përputhshme. Këto parakushte parandalojnë që një gabim i vogël planifikimi të bëhet incident lejeje. Ato gjithashtu ju tregojnë cila llogari do të shfaqet në regjistrat e destinacionit kur diçka shkon keq.

Shikoni paraprakisht kopjen dhe lexoni listën e detajuar

Ekzekutoni kopjen fillimisht me flamurin e shikimit paraprak dhe ruani daljen. Ndryshimet e detajuara ju tregojnë se çfarë do të ndodhte me çdo shteg, gjë që është shumë më e dobishme sesa një përmbledhje e mëvonshme. Ruajeni daljen në regjistrin e ndryshimeve që ekzekutimi i ardhshëm të ketë me çfarë të krahasohet.

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

Pjerrësia e fundit ka rëndësi. Në anën e burimit ajo nënkupton përmbajtjen e asaj drejtorie, ndërsa heqja e saj shton një nivel drejtorie të emërtuar sipas burimit. Manuali i rsync dokumenton të dyja format bashkë me flamujt e ruajtjes së metadata, dhe grupi i opsioneve që ju nevojiten varet nga të dhënat dhe jo nga zakoni.

Lexoni çdo rresht kundrejt destinacionit që kishit ndërmend. Heqja e flamurit të shikimit paraprak kryen kopjimin dhe mund të mbishkruajë skedarë, dhe pa një opsion fshirjeje skedarët shtesë që ekzistojnë tashmë në destinacion thjesht mbeten aty ku janë. Ky është parazgjedhja e sigurt vetëm nëse keni vendosur vërtet që skedarët e vjetër të mbetur pas janë të pranueshëm. Nëse përgjigjja është jo, vendimi për fshirje më poshtë është ai që duhet marrë, jo një flamur shtesë për të spërkatur në këtë komandë.

Më pas vendosni nëse fshirjet udhëtojnë

Shndërrimi i destinacionit në pasqyrë është një vendim i dytë, jo një rafinim i të parit. Shikojeni paraprakisht veçmas, me flamurin e fshirjes të shtuar dhe asgjë tjetër e ndryshuar, në mënyrë që ndryshimi në listë t'i përkasë tërësisht atij vendimi.

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

Fshirjet heqin skedarët e tepërt në anën marrëse brenda fushës së sinkronizuar, prandaj një shteg burimi i gabuar, një drejtori e pamontuar ose një filtër që përjashton më shumë sesa synohet mund ta bëjnë një ekzekutim shkatërrues të duket si pasqyrë e pastër. Lista e shikimit paraprak është vendi i vetëm ku ai ndryshim bëhet i dukshëm përpara se të bëhet i kushtueshëm. Mbani një kopje rikuperimi të pavarur aty ku të dhënat e justifikojnë, dhe mbani mend se një pasqyrë riprodhon me besnikëri një fshirje aksidentale në vend që të ruajë historikun.

Shikimi paraprak gjithashtu nuk bllokon asgjë. Njerëzit modifikojnë skedarë midis provës dhe ekzekutimit real, dhe sistemet e skedarëve kanë mendimet e tyre, kështu që ekzekutimi që miratoni dhe ekzekutimi që ndodh nuk janë i njëjti veprim nëse të dy pemët nuk janë të qeta.

Dy punë njëdrejtimëshe nuk bëjnë një sinkronizim dydrejtimësh

Ekzekutimi i të njëjtës komandë në të dy drejtimet është mënyra më e zakonshme për të humbur të dhëna në këtë skenar. Secili drejtim e trajton anën tjetër si destinacion dhe mbishkruan me gëzim përmbajtje më të re, dhe fshirjet pasqyrohen në rendin në të cilin aktivizohet plani.

Nëse përdoruesit duhet të modifikojnë të dyja kopjet, ky është një vendim tjetër produkti: trajtimi i konflikteve, gjurmimi i fshirjeve dhe një mjet i projektuar për atë model. Përafrimi i tij me rendin e planit është mënyra se si një dosje e përbashkët merr dy versione të çdo dokumenti që askush nuk mund t'i pajtojë. Vendoseni atë në mënyrë eksplicite në vend që ta përafroni me dy zëra cron dhe shpresë.

Automatizoni vetëm pasi politika të jetë shkruar

Një punë e planifikuar duhet të mbajë drejtimin, shtigjet, politikën e metadata dhe vendimin e miratuar për fshirje. Vendosni ato pesë fakte në vetë skedarin e punës, jo në një faqe wiki që administratori i ardhshëm mund të mos e lexojë kurrë. Parandaloni ekzekutimet që mbivendosen, sepse dy kopje që shkruajnë të njëjtën pemë njëkohësisht krijojnë një gjendje që asnjëra nuk e kishte ndërmend.

Kur burimi është një bazë të dhënash aktive ose një grup tjetër të dhënash me shumë skedarë, së pari bëni një eksport të qëndrueshëm me aplikacionin ose një pamje të koordinuar. Kalimi rekursiv nëpër skedarë nuk është transaksion, dhe kopja e një grupi të dhënash që ndryshon nuk është e qëndrueshme.

Regjistroni përfundimet dhe dështimet dhe kontrolloni grupin e të dhënave në destinacion, jo vetëm kodin e daljes. Rikthimi i VPN-së pas një ndërprerjeje rikthon lidhjen; nuk thotë asgjë për atë nëse kopja e fundit përfundoi apo nëse ndryshimet në konflikt u zgjidhën ndonjëherë.