કેવી રીતે GitLab તમને મોટા નેક્સ્ટક્લાઉડ સ્ટોરેજનો બેકઅપ લેવામાં મદદ કરે છે

હે હબર!

આજે હું નેક્સ્ટક્લાઉડ સ્ટોરેજમાંથી મોટા ડેટાના બેકઅપને વિવિધ રૂપરેખાંકનોમાં સ્વચાલિત કરવાના અમારા અનુભવ વિશે વાત કરવા માંગુ છું. હું Molniya AK ખાતે સર્વિસ સ્ટેશન તરીકે કામ કરું છું, જ્યાં અમે IT સિસ્ટમનું કન્ફિગરેશન મેનેજમેન્ટ કરીએ છીએ; નેક્સ્ટક્લાઉડનો ઉપયોગ ડેટા સ્ટોરેજ માટે થાય છે. વિતરિત માળખા સાથે, નિરર્થકતા સહિત.

ઇન્સ્ટોલેશનની વિશેષતાઓથી ઊભી થતી સમસ્યાઓ એ છે કે ત્યાં ઘણો ડેટા છે. નેક્સ્ટક્લાઉડ, રીડન્ડન્સી, વ્યક્તિલક્ષી કારણો અને વધુ દ્વારા પ્રદાન કરવામાં આવેલ સંસ્કરણ ઘણા ડુપ્લિકેટ્સ બનાવે છે.

પ્રાગૈતિહાસિક

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

અમે નેક્સ્ટક્લાઉડથી અમારા સ્થાને અથવા ગ્રાહકના અલગ મશીનો પર બેકઅપ સ્ટોર કરવા માટેના વિકલ્પો પ્રદાન કરીએ છીએ, જેને વહીવટ માટે લવચીક સ્વચાલિત અભિગમની જરૂર છે.

ઘણા ક્લાયન્ટ્સ છે, તે બધા વિવિધ રૂપરેખાંકનો સાથે, અને બધા તેમની પોતાની સાઇટ્સ પર અને તેમની પોતાની લાક્ષણિકતાઓ સાથે. જ્યારે આખી સાઇટ તમારી હોય ત્યારે આ એક માનક તકનીક છે, અને બેકઅપ ક્રાઉન્સમાંથી બનાવવામાં આવે છે; તે સારી રીતે બંધબેસતું નથી.

પ્રથમ, ચાલો ઇનપુટ ડેટા જોઈએ. અમને જરૂર છે:

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

બેકઅપ મેનેજ કરવાની સમસ્યાને ઉકેલવા માટે, અમે GitLab ઇન્સ્ટોલ કર્યું છે. ટાકલ દ્વારા વધુ વિગતો.

અલબત્ત, આવી સમસ્યાનો ઉકેલ લાવવામાં અમે પ્રથમ નથી, પરંતુ અમને લાગે છે કે અમારો વ્યવહારુ, સખત મહેનતનો અનુભવ રસપ્રદ હોઈ શકે છે અને અમે તેને શેર કરવા તૈયાર છીએ.

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

બેકઅપ સાધનો

અમે બેકઅપ બનાવવાનું સાધન પસંદ કરીને ઉકેલ પદ્ધતિઓ માટે અમારી શોધ શરૂ કરી.

નિયમિત tar + gzip સારી રીતે કામ કરતું નથી - ડેટા ડુપ્લિકેટ છે. ઇન્ક્રીમેન્ટમાં ઘણી વાર બહુ ઓછા વાસ્તવિક ફેરફારો હોય છે, અને એક ફાઇલમાંનો મોટાભાગનો ડેટા પુનરાવર્તિત થાય છે.
બીજી સમસ્યા છે - વિતરિત ડેટા સ્ટોરેજની રીડન્ડન્સી. અમે minio નો ઉપયોગ કરીએ છીએ અને તેનો ડેટા મૂળભૂત રીતે રીડન્ડન્ટ છે. અથવા તમારે મિનિઓ દ્વારા જ બેકઅપ લેવો પડ્યો હતો - તેને લોડ કરો અને ફાઇલ સિસ્ટમ વચ્ચેના તમામ સ્પેસરનો ઉપયોગ કરો, અને, ઓછું મહત્વનું નથી, કેટલીક બકેટ્સ અને મેટા-માહિતી વિશે ભૂલી જવાનું જોખમ છે. અથવા ડુપ્લિકેશનનો ઉપયોગ કરો.

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

બેકઅપ્સનું સંચાલન

બોર્ગ અને રેસ્ટિક સારા છે, પરંતુ કોઈપણ ઉત્પાદનમાં કેન્દ્રિય નિયંત્રણ પદ્ધતિ નથી. સંચાલન અને નિયંત્રણના હેતુ માટે, અમે એક સાધન પસંદ કર્યું છે જે અમે પહેલેથી જ અમલમાં મૂક્યું છે, જેના વિના અમે ઓટોમેશન સહિત અમારા કાર્યની કલ્પના કરી શકતા નથી - આ જાણીતું CI/CD - GitLab છે.

વિચાર નીચે મુજબ છે: નેક્સ્ટક્લાઉડ ડેટા સ્ટોર કરતા દરેક નોડ પર gitlab-runner ઇન્સ્ટોલ કરેલ છે. દોડવીર એક શેડ્યૂલ પર સ્ક્રિપ્ટ ચલાવે છે જે બેકઅપ પ્રક્રિયાને મોનિટર કરે છે, અને તે બોર્ગ અથવા રેસ્ટિક લોન્ચ કરે છે.

અમને શું મળ્યું? અમલમાંથી પ્રતિસાદ, ફેરફારો પર અનુકૂળ નિયંત્રણ, ભૂલના કિસ્સામાં વિગતો.

અહીં અહીં GitHub પર અમે વિવિધ કાર્યો માટે સ્ક્રિપ્ટના ઉદાહરણો પોસ્ટ કર્યા છે, અને અમે તેને માત્ર નેક્સ્ટક્લાઉડના બેકઅપ સાથે જોડવાનું સમાપ્ત કર્યું છે, પરંતુ અન્ય ઘણી સેવાઓ પણ. ત્યાં એક શેડ્યૂલર પણ છે જો તમે તેને મેન્યુઅલી ગોઠવવા માંગતા નથી (અને અમે નથી માંગતા) અને .gitlab-ci.yml

Gitlab API માં CI/CD સમયસમાપ્તિ બદલવાની કોઈ રીત નથી, પરંતુ તે નાનું છે. તેને વધારવાની જરૂર છે, કહો 1d.

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

હવે રેપર સ્ક્રિપ્ટ વિશે.

અમે આ સ્ક્રિપ્ટ માટે નીચેની શરતો સેટ કરીએ છીએ:

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

સંપૂર્ણ લોગ ગિટલેબમાં આર્ટિફેક્ટ તરીકે સાચવવામાં આવે છે; જો ત્યાં કોઈ ભૂલ ન હોય, તો લોગ કાઢી નાખવામાં આવે છે. અમે બેશમાં સ્ક્રિપ્ટ લખીએ છીએ.

ઓપન સોર્સ સંબંધિત કોઈપણ સૂચનો અને ટિપ્પણીઓને ધ્યાનમાં લેવા માટે અમને આનંદ થશે - સ્વાગત છે.

આ કેવી રીતે કામ કરે છે

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

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

અમે ssh દ્વારા બેકઅપ મોકલવાની સુવિધાનો ઉપયોગ કર્યો નથી. આ સુરક્ષા ઉમેરતું નથી, અને S3 પ્રદાતાની નેટવર્ક ક્ષમતાઓ અમારા એક ssh મશીન કરતાં ઘણી વધારે છે.

તમારા સ્થાનિક મશીનને હેકરથી બચાવવા માટે, કારણ કે તે S3 પરનો ડેટા ભૂંસી શકે છે, તમારે વર્ઝનિંગ સક્ષમ કરવું આવશ્યક છે.
બેકઅપ હંમેશા બેકઅપને એન્ક્રિપ્ટ કરે છે.

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

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

રશિયનમાં રીડમી

મુખ્ય કાર્યો

• prepare તાલીમ
• testcheck તૈયારી તપાસ
• maincommand મુખ્ય ટીમ
• forcepostscript એક કાર્ય કે જે અંતમાં અથવા ભૂલ દ્વારા ચલાવવામાં આવે છે. અમે પાર્ટીશનને અનમાઉન્ટ કરવા માટે તેનો ઉપયોગ કરીએ છીએ.

સેવા કાર્યો

• cleanup અમે ભૂલો રેકોર્ડ કરીએ છીએ અથવા લોગ ફાઇલ ભૂંસી નાખીએ છીએ.
• checklog ભૂલ સાથે લાઇનની ઘટના માટે લોગનું વિશ્લેષણ કરો.
• ret બહાર નીકળો હેન્ડલર.
• checktimeout સમયસમાપ્તિ માટે તપાસો.

પર્યાવરણ

• VERBOSE=1 અમે તરત જ સ્ક્રીન પર ભૂલો પ્રદર્શિત કરીએ છીએ (stdout).
• SAVELOGSONSUCCES=1 સફળતા પર લોગ સાચવો.
• INIT_REPO_IF_NOT_EXIST=1 જો તે અસ્તિત્વમાં ન હોય તો રીપોઝીટરી બનાવો. ડિફૉલ્ટ રૂપે અક્ષમ.
• TIMEOUT મુખ્ય કામગીરી માટે મહત્તમ સમય. તમે તેને અંતે 'm', 'h' અથવા 'd' તરીકે સેટ કરી શકો છો.

જૂની નકલો માટે સ્ટોરેજ મોડ. ડિફૉલ્ટ:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

સ્ક્રિપ્ટની અંદરના ચલો

• ERROR_STRING — ભૂલ માટે ચેક ઇન લોગ માટે શબ્દમાળા.
• EXTRACT_ERROR_STRING — જો ભૂલ હોય તો શબ્દમાળા બતાવો માટે અભિવ્યક્તિ.
• KILL_TIMEOUT_SIGNAL - સમય સમાપ્ત થાય તો મારવા માટેનો સંકેત.
• TAIL - સ્ક્રીન પર ભૂલો સાથે કેટલી તાર.
• COLORMSG - સંદેશનો રંગ (મૂળભૂત પીળો).

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

રેસ્ટિક વિ બોર્ગ

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

અમારા પસંદગીના માપદંડો, પહેલાથી જ ઉલ્લેખિત (ડિડુપ્લિકેશન, ઝડપી પુનઃપ્રાપ્તિ, વગેરે) ઉપરાંત:

• અધૂરા કામ માટે પ્રતિકાર. મારવા માટે તપાસો -9.
• ડિસ્ક પરનું કદ.
• સંસાધનો માટેની આવશ્યકતાઓ (CPU, મેમરી).
• સંગ્રહિત બ્લોબ્સનું કદ.
• S3 સાથે કામ.
• અખંડિતતા તપાસ.

પરીક્ષણ માટે, અમે વાસ્તવિક ડેટા અને કુલ 1,6 TB કદ સાથે એક ક્લાયંટ લીધો.
શરતો.

બોર્ગને S3 સાથે સીધું કેવી રીતે કામ કરવું તે ખબર નથી, અને અમે ડિસ્કને ફ્યુઝ તરીકે માઉન્ટ કરી છે. મૂર્ખ. રેસ્ટિકે તેને S3 પર જ મોકલ્યો.

Goofys ખૂબ જ ઝડપથી અને સારી રીતે કામ કરે છે, અને ત્યાં છે ડિસ્ક કેશ મોડ્યુલ, જે કામને વધુ વેગ આપે છે. તે બીટા તબક્કામાં છે, અને, પ્રમાણિકપણે, અમે પરીક્ષણો (અન્ય) દરમિયાન ડેટા ગુમાવવાથી ક્રેશ થયા. પરંતુ સગવડ એ છે કે બેકઅપ પ્રક્રિયામાં પોતે જ વધુ વાંચવાની જરૂર નથી, પરંતુ મોટે ભાગે લખવાની જરૂર છે, તેથી અમે કેશનો ઉપયોગ ફક્ત અખંડિતતા તપાસ દરમિયાન કરીએ છીએ.

નેટવર્કના પ્રભાવને ઘટાડવા માટે, અમે સ્થાનિક પ્રદાતા - યાન્ડેક્સ ક્લાઉડનો ઉપયોગ કર્યો.

સરખામણી પરીક્ષણ પરિણામો.

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

બેકઅપર
કદ

બોરગ
562GB

રેસ્ટિક
628GB

• CPU દ્વારા
  બોર્ગ પોતે ડિફૉલ્ટ કમ્પ્રેશન સાથે થોડો વપરાશ કરે છે, પરંતુ ગૂફી પ્રક્રિયા સાથે તેનું મૂલ્યાંકન કરવું આવશ્યક છે. કુલ મળીને, તેઓ તુલનાત્મક છે અને સમાન પરીક્ષણ વર્ચ્યુઅલ મશીન પર લગભગ 1,2 કોરોનો ઉપયોગ કરે છે.
• સ્મૃતિ. રેસ્ટિક આશરે 0,5GB છે, બોર્ગ આશરે 200MB છે. પરંતુ સિસ્ટમ ફાઇલ કેશની તુલનામાં આ બધું નજીવું છે. તેથી વધુ મેમરી ફાળવવાની સલાહ આપવામાં આવે છે.
• બ્લોબના કદમાં તફાવત આશ્ચર્યજનક હતો.

બેકઅપર
કદ

બોરગ
લગભગ 500MB

રેસ્ટિક
લગભગ 5MB

• રેસ્ટિકના S3 સાથેનો અનુભવ ઉત્તમ છે. ગૂફી દ્વારા બોર્ગ સાથે કામ કરવાથી કોઈ પ્રશ્નો ઉભા થતા નથી, પરંતુ એ નોંધવામાં આવ્યું છે કે કેશને સંપૂર્ણપણે રીસેટ કરવા માટે બેકઅપ પૂર્ણ થયા પછી umount કરવાની સલાહ આપવામાં આવે છે. S3 ની ખાસિયત એ છે કે અંડર-પમ્પ કરેલા હિસ્સાને ક્યારેય બકેટમાં મોકલવામાં આવશે નહીં, જેનો અર્થ છે કે અપૂર્ણ રીતે ભરેલ ડેટા મોટા નુકસાન તરફ દોરી જાય છે.
• અખંડિતતા તપાસ બંને કિસ્સાઓમાં સારી રીતે કાર્ય કરે છે, પરંતુ ઝડપ નોંધપાત્ર રીતે અલગ છે.
  રેસ્ટિક 3,5 કલાક.
  બોર્ગ, 100GB SSD ફાઇલ કેશ સાથે - 5 કલાકજો ડેટા સ્થાનિક ડિસ્ક પર હોય તો લગભગ સમાન ઝડપનું પરિણામ.
  બોર્ગ કેશ વગર સીધા S3 થી વાંચે છે 33 કલાક. ભયંકર લાંબા.

બોગ લાઇન એ છે કે બોર્ગ સંકુચિત કરી શકે છે અને તેમાં મોટા બ્લોબ્સ છે - જે S3 માં સ્ટોરેજ અને GET/PUT ઑપરેશનને સસ્તું બનાવે છે. પરંતુ આ વધુ જટિલ અને ધીમી ચકાસણીના ખર્ચે આવે છે. પુનઃપ્રાપ્તિ ઝડપ માટે, અમે કોઈ તફાવત નોંધ્યો નથી. રેસ્ટિક અનુગામી બેકઅપ (પ્રથમ પછી) થોડો વધુ સમય લે છે, પરંતુ નોંધપાત્ર રીતે નહીં.

છેલ્લું પરંતુ ઓછામાં ઓછું પસંદગીમાં સમુદાયનું કદ હતું.

અને અમે બોર્ગ પસંદ કર્યો.

કમ્પ્રેશન વિશે થોડાક શબ્દો

બોર્ગ પાસે તેના શસ્ત્રાગારમાં એક ઉત્તમ નવું કમ્પ્રેશન અલ્ગોરિધમ છે - zstd. કમ્પ્રેશન ગુણવત્તા gzip કરતાં વધુ ખરાબ નથી, પરંતુ ઘણી ઝડપી છે. અને ડિફૉલ્ટ lz4 સાથે ઝડપમાં તુલનાત્મક.

ઉદાહરણ તરીકે, MySQL ડેટાબેઝ ડમ્પ સમાન ઝડપે lz4 કરતા બે ગણો વધુ સારી રીતે સંકુચિત થાય છે. જો કે, વાસ્તવિક ડેટા સાથેનો અનુભવ દર્શાવે છે કે નેક્સ્ટક્લાઉડ નોડના કમ્પ્રેશન રેશિયોમાં બહુ ઓછો તફાવત છે.

બોર્ગ પાસે તેના બદલે બોનસ કમ્પ્રેશન મોડ છે - જો ફાઇલમાં ઉચ્ચ એન્ટ્રોપી હોય, તો પછી કમ્પ્રેશન બિલકુલ લાગુ પડતું નથી, જે ઝડપ વધારે છે. બનાવતી વખતે વિકલ્પ દ્વારા સક્ષમ
-C auto,zstd
zstd અલ્ગોરિધમ માટે
તેથી આ વિકલ્પ સાથે, ડિફોલ્ટ કમ્પ્રેશનની સરખામણીમાં, અમને મળ્યું
અનુક્રમે 560Gb અને 562Gb. ઉપરના ઉદાહરણમાંથી ડેટા, ચાલો હું તમને યાદ કરાવું, કમ્પ્રેશન વિના પરિણામ 628Gb છે. 2GB તફાવતના પરિણામથી અમને કંઈક અંશે આશ્ચર્ય થયું, પરંતુ અમે વિચાર્યું કે અમે આખરે તેને પસંદ કરીશું. auto,zstd.

બેકઅપ ચકાસણી પદ્ધતિ

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

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

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

વિવિધ ટૅગ્સ સાથે વિવિધ નોડ્સ પર દોડવીરો ચલાવીને માપનીયતા પ્રાપ્ત થાય છે.
અમારું મોનિટરિંગ એક વિન્ડોમાં GitLab API દ્વારા બેકઅપ સ્થિતિઓ એકત્રિત કરે છે; જો જરૂરી હોય તો, સમસ્યાઓ સરળતાથી ધ્યાનમાં લેવામાં આવે છે અને તેટલી જ સરળતાથી સ્થાનિકીકરણ થાય છે.

નિષ્કર્ષ

પરિણામે, અમે ખાતરીપૂર્વક જાણીએ છીએ કે અમે બેકઅપ્સ બનાવીએ છીએ, કે અમારા બેકઅપ્સ માન્ય છે, તેમની સાથે ઊભી થતી સમસ્યાઓ થોડો સમય લે છે અને ફરજ સંચાલકના સ્તરે ઉકેલાય છે. tar.gz અથવા Bacula ની સરખામણીમાં બેકઅપ ખરેખર થોડી જગ્યા લે છે.

સોર્સ: www.habr.com