Pritunl: નિયંત્રણ સ્થિતિ વિરુદ્ધ જનરેટ થયેલી પ્રોફાઇલ

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

બે વસ્તુઓ બેકઅપ જેવી લાગે છે અને ફક્ત એક સેવા પુનઃસ્થાપિત કરે છે

ડાઉનલોડ કરેલી ક્લાયન્ટ પ્રોફાઇલમાં પ્રમાણપત્ર, કી અને એન્ડપોઇન્ટ હોય છે. તે તે એક ઉપકરણ માટે પૂર્ણ છે અને તૈનાતીના રેકોર્ડ તરીકે નકામી: તેમાં કોઈ સંસ્થા, નિષ્ક્રિય વપરાશકર્તા, સર્વર રૂટ કે વહીવટી ખાતા હોતા નથી. પ્રોફાઇલ ફોલ્ડરમાંથી પુનઃસ્થાપન એવા ક્લાયન્ટ આપે છે જે કોઈપણ વસ્તુ સામે પ્રમાણિત થઈ શકતા નથી.

હોસ્ટ કન્ફિગરેશનની નકલ પણ તેટલી જ આંશિક છે. /etc/pritunl.conf હોસ્ટ-સ્તરીય સેટિંગ્સ રાખે છે, જેમાં ડેટાબેઝ સુધી પહોંચવાની રીતનો સમાવેશ થાય છે, અને પોતે VPN ઑબ્જેક્ટ રાખતું નથી.

ડેટાબેઝ શું ધરાવે છે અને હોસ્ટ શું ધરાવે છે

Pritunl સર્વર વ્યાખ્યાઓ, વપરાશકર્તાઓ, સંસ્થાઓ અને કી MongoDB માં રાખે છે. તે ડેટાબેઝ સત્તાવાર નિયંત્રણ સપાટી છે, અને ડિસ્ક પર જનરેટ થયેલી દરેક OpenVPN ફાઇલ તેમાંથી ઉતરી આવેલું આઉટપુટ છે. જનરેટ થયેલી ફાઇલમાં સીધો કરેલો ફેરફાર આગલી પુનઃજનન સુધી ટકે છે અને પછી અદૃશ્ય થાય છે, તેથી રનટાઇમ ફાઇલોમાં સંપાદન ટકાઉ સુધારો નથી. એ જ નિયમ અસરકારક રૂટ અને ઇન્ટરફેસ પર લાગુ પડે છે: તેઓ કહે છે કે નિયંત્રણ સપાટીએ શું ઉત્પન્ન કર્યું, નહીં કે તેણે શું ઉત્પન્ન કરવું જોઈએ.

હોસ્ટ નાનો પણ સ્થાનાંતરિત ન થઈ શકે તેવો મૂલ્ય સમૂહ આપે છે. તેમાંથી એક /var/lib/pritunl/pritunl.uuid છે, તે ચોક્કસ નોડની ઓળખ.

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

સુસંગત ડમ્પ લો, ડિરેક્ટરી નકલ નહીં

સેવા લખતી વખતે MongoDB ડેટા ડિરેક્ટરીની નકલ કરવાથી એવી ફાઇલો બને છે જે વાપરી શકાય તેવો ડેટાબેઝ ન બનાવી શકે. તેના બદલે ડેટાબેઝનો સમર્થિત ડમ્પ માર્ગ વાપરો, જે તમારી પાસે ખરેખર હોય તે ટોપોલોજી સામે ચલાવવામાં આવે:

mongodump --uri="mongodb://127.0.0.1:27017/pritunl" --out=/var/backups/pritunl/db
sudo tar czf /var/backups/pritunl/host.tgz /etc/pritunl.conf /var/lib/pritunl/pritunl.uuid

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

જરૂર પડે તે પહેલાં પુનઃસ્થાપનનો અભ્યાસ કરો

જે બેકઅપ કોઈએ પુનઃસ્થાપિત કર્યું નથી તે એક પરિકલ્પના છે. સેવા અલગ નેટવર્કમાં બનાવો, ડમ્પ પુનઃસ્થાપિત કરો અને હોસ્ટ ફાઇલો પાછી મૂકો:

mongorestore --uri="mongodb://127.0.0.1:27017" --drop /var/backups/pritunl/db
sudo tar xzf /var/backups/pritunl/host.tgz -C /

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

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