ક્ષમતા ટાયર (અથવા આપણે તેને Vim - captir ની અંદર કહીએ છીએ) આર્કાઈવ ટાયર નામ હેઠળ Veeam બેકઅપ અને પ્રતિકૃતિ 9.5 અપડેટ 4 ના દિવસોમાં દેખાયા. તેની પાછળનો વિચાર કહેવાતા ઓપરેશનલ રિસ્ટોર વિન્ડોની બહાર પડી ગયેલા બેકઅપને ઑબ્જેક્ટ સ્ટોરેજમાં ખસેડવાનું શક્ય બનાવવાનો છે. આનાથી તે વપરાશકર્તાઓ માટે ડિસ્ક સ્પેસ સાફ કરવામાં મદદ મળી કે જેમની પાસે તે ઓછી હતી. અને આ વિકલ્પને મૂવ મોડ કહેવામાં આવતું હતું.

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

પરંતુ VBR v10 માં, ખ્યાલને નવા કાર્યો સાથે પૂરક બનાવવામાં આવ્યો હતો - કોપી મોડ, સીલ કરેલ મોડ અને એક વસ્તુ જેમાં ઉચ્ચારવામાં અઘરું નામ અવિચલન દેખાય છે.

આ તે રસપ્રદ બાબતો છે જેના વિશે આજે આપણે વાત કરીશું. પ્રથમ, તે VBR9.5u4 માં કેવી રીતે કાર્ય કરે છે તે વિશે, અને પછી દસમા સંસ્કરણમાં ફેરફારો વિશે.

અને શુદ્ધ ભાષાના ચેમ્પિયન્સ મને માફ કરી શકે છે, પરંતુ ઘણી બધી શરતો છે જેનો અનુવાદ કરી શકાતો નથી.
તેથી અહીં એક ટન અંગ્રેજીવાદ હશે.
અને ઘણી બધી gif.
અને ચિત્રો.

• સહેજ પણ અફસોસ વિના. લેખના લેખક.

જેવું હતું તેવું

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

જેમ આપણે ચિત્રમાં જોઈએ છીએ, અમારી પાસે ડેટા બ્લોક્સ સાથે એક પ્રકારની બેકઅપ સાંકળ છે, જે રીપોઝીટરીના પરફોર્મન્સ ટાયર SOBR પર સ્થિત છે જેની સાથે ક્ષમતા ટાયર જોડાયેલ છે. અમારી ઓપરેશનલ બેકઅપ વિન્ડો ત્રણ દિવસની છે.

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

પરંતુ સીલબંધ સાંકળનો અર્થ શું હતો અને અપડેટ 4 માં ક્ષમતા શૂટિંગ રેન્જમાં શું મોકલી શકાય?

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

વિપરીત કિસ્સામાં, આ બધી ફાઇલો છે જે ઑપરેટિંગ વિંડોમાં આવતી નથી.

રોલબેક સાથે ફોરવર્ડ ઇન્ક્રીમેન્ટના કિસ્સામાં, આ બધા રોલબેક છે અને .vbk, જો કામગીરીની હદ પર અન્ય .vbk હોય તો

હવે ચાલો બેકઅપ કોપી સાંકળો સાથે કામ કરવાના વિકલ્પને ધ્યાનમાં લઈએ. માત્ર GFS રીટેન્શન હેઠળ આવતી વસ્તુઓ અહીં પરિવહન કરવામાં આવી હતી. કારણ કે તાજેતરની બેકઅપ કોપી ચેઇન્સમાં સંગ્રહિત દરેક વસ્તુને એક અથવા બીજી રીતે બદલી શકાય છે.

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

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

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

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

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

એ કેવી રીતે થયું?

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

કૉપિ મોડ

તે મોટાભાગે હાલની તકનીકો પર આધારિત છે, પરંતુ તેનો ઉપયોગ સંપૂર્ણપણે અલગ તર્ક ધરાવે છે. 

આ મોડનો હેતુ એ સુનિશ્ચિત કરવાનો છે કે સ્થાનિક હદ પર સ્થિત તમામ ડેટાની ક્ષમતા ડેશમાં નકલ છે.

જો તમે મૂવ અને કોપી મોડ્સની હેડ-ઓન સરખામણી કરો છો, તો તે આના જેવું દેખાશે:

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

નવા મોડને ધ્યાનમાં લેતા, હું સરળ ઉદાહરણોમાંથી જટિલ મુદ્દાઓ તરફ જવાનો પ્રસ્તાવ મૂકું છું.

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

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

પ્રશ્ન ઊભો થાય છે - જો તમે UI ને જુઓ છો, તો એક જ સમયે બંને વિકલ્પો પસંદ કરવાની તક છે. આવા સંયુક્ત મોડ કેવી રીતે કાર્ય કરશે?

ચાલો તેને આકૃતિ કરીએ.

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

આ તમામ રસપ્રદ તર્ક ઈન્ટરફેસમાં માત્ર એક ચેકબૉક્સ માટે જવાબદાર છે: ઑબ્જેક્ટ સ્ટોરેજમાં બૅકઅપ બનાવતાની સાથે જ કૉપિ કરો.

આપણને આ કોપી મોડની શા માટે જરૂર છે?

પ્રશ્નને આ રીતે ફરીથી લખવો તે વધુ સારું છે: તેની સહાયથી આપણે કયા જોખમોથી સુરક્ષિત છીએ? તે આપણને કઈ સમસ્યા હલ કરવામાં મદદ કરે છે?

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

તો ચાલો શક્ય દૃશ્યોમાંથી પસાર થઈએ, સરળથી વધુ જટિલ સુધી.

સૌથી સરળ કમનસીબી જે આપણા માથા પર પડી શકે છે તે બેકઅપ સાંકળમાંની એક ફાઇલની અગમ્યતા છે.

એક દુઃખદ વાર્તા એ છે કે અમારા SOBR ભંડારની એક હદ તૂટી ગઈ છે.

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

હવે ચાલો દરેક પરિસ્થિતિને અલગથી જોઈએ.

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

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

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

આ કેસનો પેટા પ્રકાર એ છે કે સમગ્ર SOBR રીપોઝીટરી અપ્રાપ્ય બની ગઈ છે. આ કિસ્સામાં, અમારી પાસે સ્થાનિક સ્ટોરેજમાંથી કૉપિ કરવા માટે કંઈ નથી, અને બધા બ્લોક્સ ક્લાઉડમાંથી ડાઉનલોડ થાય છે.

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

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

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

આ કદાચ કૉપિ મોડ વિશે છે અને અમે આગળ વધીએ છીએ

સીલ કરેલ મોડ

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

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

તદનુસાર, ઑપરેશનનો સિદ્ધાંત એકદમ સરળ છે: તમામ લેખન ઑપરેશન્સ (નવા ડેટાનો દેખાવ) પર પ્રતિબંધ મૂકવો જરૂરી છે, વાંચવા (પુનઃસ્થાપન) અને કાઢી નાખવું (રીટેન્શન) છોડી દો.

બંને મોડ્સ એકસાથે વાપરી શકાય છે, પરંતુ ધ્યાનમાં રાખો કે જાળવણીને ઉચ્ચ પ્રાથમિકતા છે.

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

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

રિવર્સ ઇન્ક્રીમેન્ટલ સાથે વસ્તુઓ સરળ છે. તેમાં, સૌથી જૂના મુદ્દાઓ કંઈપણ પર આધાર રાખતા નથી અને સુરક્ષિત રીતે કાઢી શકાય છે. તેથી, જેમ જ નવી હદ પર નવું .vbk બનાવવામાં આવશે, જૂના .vrbs એક પછી એક કાઢી નાખવામાં આવશે.

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

ક્ષમતા શૂટિંગ શ્રેણી સાથે વસ્તુઓ વધુ જટિલ છે.

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

લગભગ આ જ વસ્તુ મૂવ મોડમાં થાય છે - અમે રિટચની રાહ જોઈએ છીએ, સ્થાનિક સ્ટોરેજમાં જૂનાને કાઢી નાખીએ છીએ અને ઑબ્જેક્ટ સ્ટોરેજમાં સંગ્રહિત એકને કાઢી નાખીએ છીએ.

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

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

તે મૂળભૂત રીતે તે બધા છે. તો ચાલો સૌથી હાર્ડકોર ફીચર તરફ આગળ વધીએ -

અપરિવર્તનશીલતા

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

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

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

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

અમારી બ્લોક જનરેશન ટેક્નોલોજીને સમજાવવાનો હવે સારો સમય છે. અથવા બ્લોક જનરેશન. આ કરવા માટે, તેના દેખાવ તરફ દોરી ગયેલી પરિસ્થિતિને ધ્યાનમાં લો.

ચાલો છ દિવસનો ટાઈમ સ્કેલ લઈએ અને નીચે આપણે અપરિવર્તનની અપેક્ષિત સમાપ્તિના સમયને ચિહ્નિત કરીશું. પ્રથમ દિવસે અમે ડેટા બ્લોક એ અને તેના મેટાડેટા ધરાવતી ફાઇલ લઈએ છીએ અને બનાવીએ છીએ. જો અપરિવર્તનક્ષમતા ત્રણ દિવસ પર સેટ કરેલ હોય, તો ચોથા દિવસે ડેટા અનલૉક અને કાઢી નાખવામાં આવશે તેવું માનવું તાર્કિક છે. બીજા દિવસે આપણે એક નવી ફાઇલ2 ઉમેરીશું, જેમાં સમાન સેટિંગ્સ સાથે બ્લોક બીનો સમાવેશ થાય છે. બ્લોકને ચોથા દિવસે દૂર કરવાની જરૂર છે. પરંતુ ત્રીજા દિવસે કંઈક ભયંકર બને છે - એક ફાઇલ3 ફાઇલ બનાવવામાં આવે છે, જેમાં એક નવો બ્લોક ડી અને જૂના બ્લોકની લિંકનો સમાવેશ થાય છે. આનો અર્થ એ છે કે બ્લોક અને તેની અપરિવર્તનક્ષમતા ધ્વજ માટે નવી તારીખ પર રીસેટ થવો જોઈએ, જે છઠ્ઠા દિવસે ખસેડવામાં આવે છે. અને અહીં એક સમસ્યા ઊભી થાય છે - વાસ્તવિક બેકઅપ્સમાં આવા બ્લોક્સની વિશાળ સંખ્યા છે. અને તેમની અપરિવર્તનક્ષમતા અવધિને વધારવા માટે, તમારે દર વખતે મોટી સંખ્યામાં વિનંતીઓ કરવાની જરૂર છે. અને વાસ્તવમાં, આ લગભગ અનંત દૈનિક પ્રક્રિયા હશે, કારણ કે ઉચ્ચ સ્તરની સંભાવના સાથે અમને દરેક નકલ સાથે ડુપ્લિકેટેડ બ્લોક્સના ભારે સ્ટેક્સ મળશે. ઑબ્જેક્ટ સ્ટોરેજ પ્રદાતાઓની મોટી સંખ્યામાં વિનંતીઓનો અર્થ શું છે? અધિકાર! મહિનાના અંતે જંગી બિલ.

અને નોંધપાત્ર પૈસા માટે તમારા મનપસંદ ક્લાયંટને વાદળી બહાર ન લાવવા માટે, બ્લોક જનરેશન મિકેનિઝમની શોધ કરવામાં આવી હતી. આ એક વધારાનો સમયગાળો છે જે અમે સેટ અપરિવર્તનશીલતા સમયગાળામાં ઉમેરીએ છીએ. નીચેના ઉદાહરણમાં, આ સમયગાળો બે દિવસનો છે. પરંતુ આ માત્ર એક ઉદાહરણ છે. વાસ્તવમાં, તેઓ તેમના પોતાના ફોર્મ્યુલાનો ઉપયોગ કરે છે, જે માસિક લૉક દરમિયાન આશરે દસ વધારાના દિવસો આપે છે.

ચાલો સમાન પરિસ્થિતિને ધ્યાનમાં લેવાનું ચાલુ રાખીએ, પરંતુ બ્લોક જનરેશન સાથે. પ્રથમ દિવસે આપણે બ્લોક એ અને મેટાડેટામાંથી ફાઇલ1 બનાવીએ છીએ. અમે જનરેશન અવધિ અને અપરિવર્તનશીલતા ઉમેરીએ છીએ - આનો અર્થ એ છે કે ફાઇલને કાઢી નાખવાની તક છઠ્ઠા દિવસે હશે. જો બીજા દિવસે આપણે ફાઇલ2 બનાવીએ, જેમાં બ્લોક b અને બ્લોક aને બ્લોક કરવાની લિંક હોય, તો અપેક્ષિત કાઢી નાખવાની તારીખથી કંઈ થતું નથી. તે છઠ્ઠા દિવસે જેમ ઊભી રહી હતી. અને આમ અમે વિનંતીઓની સંખ્યા પર નાણાં બચાવવા પ્રયાસ કરી રહ્યા છીએ. જો જનરેશન પિરિયડ સમાપ્ત થઈ ગયો હોય તો જ ડેડલાઈન શિફ્ટ કરી શકાય છે. એટલે કે, જો ત્રીજા દિવસે નવી File3 એ બ્લોક કરવા માટેની લિંક ધરાવે છે, તો જનરેશન 2 ઉમેરવામાં આવશે કારણ કે Gen1 પહેલેથી જ સમાપ્ત થઈ ગયું છે. અને બ્લોક a કાઢી નાખવાની અપેક્ષિત તારીખ આઠમા દિવસે શિફ્ટ થશે. આનાથી અમને ડિડુપ્લિકેટ બ્લોક્સના જીવનકાળને લંબાવવાની વિનંતીઓની સંખ્યામાં નાટકીય રીતે ઘટાડો કરવાની મંજૂરી મળે છે, જે ક્લાયન્ટને ઘણા પૈસા બચાવે છે.

ટેક્નોલોજી પોતે S3 અને S3-સુસંગત હાર્ડવેરના વપરાશકર્તાઓ માટે ઉપલબ્ધ છે, જેના ઉત્પાદકો ખાતરી આપે છે કે તેમના અમલીકરણ એમેઝોન કરતા અલગ નથી. આથી કાયદેસર પ્રશ્નનો જવાબ શા માટે એઝ્યુરને સમર્થન નથી - તેમની પાસે સમાન લક્ષણ છે, પરંતુ તે કન્ટેનરના સ્તરે કાર્ય કરે છે, વ્યક્તિગત વસ્તુઓ નહીં. માર્ગ દ્વારા, એમેઝોન પોતે બે મોડમાં ઑબ્જેક્ટ લૉક ધરાવે છે: પાલન અને શાસન. બીજા કિસ્સામાં, એવી શક્યતા રહે છે કે ઑબ્જેક્ટ લૉક હોવા છતાં, ઑબ્જેક્ટ લૉક હોવા છતાં, ઑબ્જેક્ટ લૉક હોવા છતાં, એડમિન્સથી ઉપરના સૌથી મહાન એડમિન અને રુટ ઉપરના રુટ. અનુપાલનના કિસ્સામાં, બધું જ ચુસ્તપણે ખીલેલું છે અને કોઈ પણ બેકઅપ કાઢી શકતું નથી. એમેઝોન એડમિન્સ પણ (તેમના સત્તાવાર નિવેદનો અનુસાર). આ તે મોડ છે જેને અમે સપોર્ટ કરીએ છીએ.

અને, હંમેશની જેમ, કેટલીક ઉપયોગી લિંક્સ:

• પર બ્લોક જનરેશન દરેક વિગતમાં.
• વિશેની તમામ માહિતી વીમ બેકઅપ અને પ્રતિકૃતિ 10 તેના શ્રેષ્ઠમાં
• О ક્ષમતા ટાયર વિગતવાર

સોર્સ: www.habr.com