rsync VPN દ્વારા: કઈ બાજુ સત્યનો સ્રોત છે?

બે સર્વર, એક VPN, એક ડિરેક્ટરી જે બંને જગ્યાએ હોવી જ જોઈએ, અને એક કમાન્ડ જે ચલાવવો સરળ પણ પાછો લેવો મુશ્કેલ છે. તે લખતા પહેલાં નક્કી કરો કે કઈ નકલ અધિકૃત છે, કારણ કે rsync નો દરેક આગળનો પ્રશ્ન આ જવાબ પર ટકેલો છે. એકતરફી નકલ, વહેંચાયેલ કાર્ય ફોલ્ડર અને આવૃત્તિઓવાળું સંગ્રહ સંપાદન અને ડિલીટ માટે જુદા નિયમો માંગે છે. ટનલ માર્ગ પૂરો પાડે છે અને આમાંથી કોઈના પર તેનો અભિપ્રાય નથી.

કમાન્ડ લખતા પહેલાં નક્કી કરો કે કઈ નકલ જીતે છે

દિશા એક વાક્યમાં લખો, દરેક બાજુએ હોસ્ટનામ અને માર્ગ સહિત, અને ડેટાના માલિક પાસેથી મંજૂરી લો. આ માર્ગદર્શિકામાં સ્રોત /srv/publish/ છે અને લક્ષ્ય fileserver.example પરનું એક ખાતું છે જેને ફક્ત /srv/mirror/ માં લખવાની પરવાનગી છે.

નકલ પહેલાં પરિવહનની હકીકતોની પુષ્ટિ કરો: SSH હોસ્ટ કી ચકાસાયેલી છે, લક્ષ્ય ખાતું નકલ વિસ્તારમાં લખી શકે છે અને બીજે ક્યાંય નહીં, અને બંને હોસ્ટ પાસે સુસંગત rsync આવૃત્તિઓ છે. આ પૂર્વશરતો એક નાની યોજના ભૂલને પરવાનગીની ઘટના બનતા રોકે છે. તેઓ એ પણ કહે છે કે કંઈક ખોટું થાય ત્યારે લક્ષ્યના લોગમાં કયું ખાતું દેખાશે.

નકલનું પૂર્વદર્શન જુઓ અને વિગતવાર યાદી વાંચો

નકલ પહેલાં પૂર્વદર્શન ધ્વજ સાથે ચલાવો અને આઉટપુટ સાચવી રાખો. વિગતવાર ફેરફારો કહે છે કે દરેક માર્ગ સાથે શું થશે, જે પછી મળતા સારાંશ કરતાં ઘણું વધુ ઉપયોગી છે. આઉટપુટને ફેરફાર રેકોર્ડમાં રાખો જેથી આગલી વખતે ચલાવતી વખતે સરખામણી કરવા કંઈક હોય.

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

છેલ્લી તિરછી લીટી મહત્ત્વની છે. સ્રોતની બાજુએ તેનો અર્થ તે ડિરેક્ટરીની સામગ્રી છે, જ્યારે તેને છોડી દેવાથી સ્રોતના નામે એક વધારાનું ડિરેક્ટરી સ્તર ઉમેરાય છે. rsync નું મેન્યુઅલ બંને સ્વરૂપોને મેટાડેટા જાળવવાના ધ્વજ સાથે નોંધે છે, અને તમને જરૂરી વિકલ્પો ટેવ પર નહીં, ડેટા પર આધાર રાખે છે.

દરેક લીટી તમારા ઇરાદાવાળા લક્ષ્ય સામે વાંચો. પૂર્વદર્શન ધ્વજ દૂર કરવાથી નકલ પૂર્ણ થાય છે અને ફાઇલો ઉપર લખાઈ શકે છે, અને ડિલીટ વિકલ્પ વગર લક્ષ્ય પર પહેલેથી રહેલી વધારાની ફાઇલો જ્યાં છે ત્યાં જ રહે છે. આ ફક્ત ત્યારે જ સુરક્ષિત ડિફોલ્ટ છે જ્યારે તમે ખરેખર નક્કી કર્યું હોય કે પાછળ છોડેલી જૂની ફાઇલો સ્વીકાર્ય છે. જવાબ ના હોય તો નીચેનો ડિલીટ નિર્ણય લેવાનો છે, આ કમાન્ડમાં વધારાનો ધ્વજ છાંટવાનો નહીં.

પછી નક્કી કરો કે ડિલીટ યાત્રા કરે છે કે નહીં

લક્ષ્યને અરીસો બનાવવો એ બીજો નિર્ણય છે, પહેલાનો સુધારો નહીં. તેનું પૂર્વદર્શન અલગથી કરો, ડિલીટ ધ્વજ ઉમેરીને અને બીજું કંઈ ન બદલીને, જેથી યાદીનો ફરક સંપૂર્ણપણે તે જ નિર્ણયનો હોય.

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

ડિલીટ સિંક થયેલા દાયરાની અંદર પ્રાપ્ત કરનારી બાજુની વધારાની ફાઇલો દૂર કરે છે, તેથી ખોટો સ્રોત માર્ગ, ન માઉન્ટ કરેલી ડિરેક્ટરી કે ઇરાદાથી વધુ બાકાત કરતું ફિલ્ટર વિનાશક ચલાવણને સ્વચ્છ અરીસા જેવી બતાવી શકે છે. પૂર્વદર્શન યાદી એ જ જગ્યા છે જ્યાં આ ફરક મોંઘો થતાં પહેલાં દેખાય છે. જ્યાં ડેટા વાજબી ઠેરવે ત્યાં સ્વતંત્ર પુનઃપ્રાપ્તિ નકલ રાખો, અને યાદ રાખો કે અરીસો ઇતિહાસ બચાવવાને બદલે અકસ્માતે ડિલીટને વફાદારીથી પુનરાવર્તિત કરે છે.

પૂર્વદર્શન કંઈ પણ તાળું મારતું નથી. લોકો પરીક્ષણ અને ખરેખરી ચલાવણ વચ્ચે ફાઇલો સંપાદિત કરે છે, અને ફાઇલ સિસ્ટમનો પોતાનો અભિપ્રાય હોય છે, તેથી તમે મંજૂરી આપેલી ચલાવણ અને જે ચાલે છે તે એક જ ક્રિયા નથી જ્યાં સુધી બંને વૃક્ષો શાંત ન હોય.

બે એકતરફી કામ મળીને દ્વિતરફી સિંક બનતા નથી

એક જ કમાન્ડ બંને દિશામાં ચલાવવો આ પરિસ્થિતિમાં ડેટા ગુમાવવાનો સૌથી સામાન્ય રસ્તો છે. દરેક દિશા બીજી બાજુને લક્ષ્ય માને છે અને આનંદથી નવી સામગ્રી ઉપર લખી નાખે છે, અને ડિલીટ એ જ ક્રમમાં અરીસા બને છે જેમાં સમયપત્રક સક્રિય થાય છે.

જો વપરાશકર્તાઓએ બંને નકલો સંપાદિત કરવી પડે, તો આ બીજો ઉત્પાદન નિર્ણય છે: સંઘર્ષ સંચાલન, ડિલીટનું નિરીક્ષણ અને તે મોડેલ માટે બનાવેલું સાધન. સમયપત્રકના ક્રમથી તેનો અંદાજ કાઢવો એ રસ્તો છે જેનાથી વહેંચાયેલ ફોલ્ડરમાં દરેક દસ્તાવેજની બે આવૃત્તિઓ આવી જાય છે જેને કોઈ મેળવી શકતું નથી. બે cron એન્ટ્રીઓ અને આશાથી અંદાજ કાઢવાને બદલે તેને સ્પષ્ટ રીતે નક્કી કરો.

નીતિ લખાયા પછી જ સ્વયંસંચાલિત કરો

સમયપત્રકવાળા કામે દિશા, માર્ગ, મેટાડેટા નીતિ અને મંજૂર થયેલો ડિલીટ નિર્ણય સાથે રાખવો જોઈએ. આ પાંચ હકીકતો કામની ફાઇલમાં જ રાખો, કોઈ વિકિ પૃષ્ઠ પર નહીં જે આગલો વ્યવસ્થાપક કદાચ ક્યારેય ન વાંચે. એકબીજા પર ચઢતી ચલાવણો અટકાવો, કારણ કે એક જ વૃક્ષ પર એક જ સમયે લખતી બે નકલો એવી સ્થિતિ બનાવે છે જે કોઈએ ઇચ્છી ન હતી.

જ્યારે સ્રોત જીવંત ડેટાબેઝ કે બીજું બહુ-ફાઇલ ડેટાસેટ હોય, ત્યારે પહેલાં એપ્લિકેશન સાથે સુસંગત નિકાસ કે સમન્વિત સ્નેપશોટ લો. ફાઇલોનો પુનરાવર્તી પ્રવાસ વ્યવહાર નથી, અને બદલાતા ડેટાસેટની નકલ સુસંગત નથી.

પૂર્ણતાઓ અને નિષ્ફળતાઓ નોંધો, અને ફક્ત નિકાસ કોડને બદલે લક્ષ્ય પરનું ડેટાસેટ તપાસો. અવરોધ પછી VPN પુનઃસ્થાપિત કરવાથી કનેક્ટિવિટી પાછી આવે છે; તે કહેતું નથી કે અગાઉની નકલ પૂરી થઈ કે વિરોધાભાસી સંપાદનો ક્યારેય ઉકેલાયા.