બેકઅપ, ભાગ 1: હેતુ, પદ્ધતિઓ અને તકનીકોની સમીક્ષા

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

એક આદર્શ પ્રોગ્રામ ઝડપથી ચાલે છે, મેમરી લીક થતો નથી, તેમાં કોઈ છિદ્રો નથી અને અસ્તિત્વમાં નથી.

-અજ્ઞાત

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

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

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

સારા કલાકારો નકલ કરે છે, મહાન કલાકારો ચોરી કરે છે.

- પાબ્લો પિકાસો.

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

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

જો મને ખબર હોત કે તમે ક્યાં પડશો, તો મેં સ્ટ્રો નાખ્યા હોત!

- બેલારુસિયન લોક કહેવત

આનો અર્થ એ છે કે બેકઅપ નકલો તે લોકો માટે મહત્વપૂર્ણ છે જેઓ:

• ન્યૂનતમ ડાઉનટાઇમ સાથે અથવા બિલકુલ વિના પણ તમારી સિસ્ટમના ઑપરેશનને પુનઃસ્થાપિત કરવામાં સક્ષમ બનો
• હિંમતભેર કાર્ય કરો, કારણ કે ભૂલના કિસ્સામાં હંમેશા રોલબેકની શક્યતા રહે છે
• ઇરાદાપૂર્વક ડેટા ભ્રષ્ટાચારના પરિણામોને ઓછું કરો

અહીં થોડો સિદ્ધાંત છે

કોઈપણ વર્ગીકરણ મનસ્વી છે. કુદરત વર્ગીકરણ કરતી નથી. અમે વર્ગીકૃત કરીએ છીએ કારણ કે તે અમારા માટે વધુ અનુકૂળ છે. અને અમે ડેટા અનુસાર વર્ગીકૃત કરીએ છીએ જે અમે મનસ્વી રીતે પણ લઈએ છીએ.

- જીન બ્રુલર

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

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

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

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

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

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

— ત્યાં બે પ્રકારના સિસ્ટમ એડમિનિસ્ટ્રેટર્સ છે, જેઓ બેકઅપ લેતા નથી, અને જેઓ પહેલાથી જ કરે છે.
- વાસ્તવમાં, ત્યાં ત્રણ પ્રકાર છે: એવા પણ છે જેઓ તપાસે છે કે બેકઅપ પુનઃસ્થાપિત કરી શકાય છે.

-અજ્ઞાત

તે સમજવું પણ યોગ્ય છે કે ડેટા બેકઅપ પ્રક્રિયા પોતે જ પ્રોગ્રામ્સ દ્વારા હાથ ધરવામાં આવે છે, તેથી તેમાં અન્ય કોઈપણ પ્રોગ્રામ જેવા જ ગેરફાયદા છે. માનવ પરિબળ, તેમજ લક્ષણો પરની અવલંબનને દૂર કરવા (નાબૂદ નહીં!) - જેની વ્યક્તિગત રીતે મજબૂત અસર નથી, પરંતુ એકસાથે નોંધપાત્ર અસર આપી શકે છે - કહેવાતા નિયમ 3-2-1. તેને કેવી રીતે ડિસિફર કરવું તે માટે ઘણા વિકલ્પો છે, પરંતુ મને નીચેનું અર્થઘટન વધુ સારું ગમ્યું: સમાન ડેટાના 3 સેટ સંગ્રહિત હોવા જોઈએ, 2 સેટ વિવિધ ફોર્મેટમાં સંગ્રહિત હોવા જોઈએ, અને 1 સેટ ભૌગોલિક રીતે દૂરસ્થ સ્ટોરેજમાં સંગ્રહિત હોવો જોઈએ.

સ્ટોરેજ ફોર્મેટને નીચે મુજબ સમજવું જોઈએ:

• જો ભૌતિક સંગ્રહ પદ્ધતિ પર નિર્ભરતા હોય, તો અમે ભૌતિક પદ્ધતિ બદલીએ છીએ.
• જો લોજિકલ સ્ટોરેજ પદ્ધતિ પર નિર્ભરતા હોય, તો અમે તાર્કિક પદ્ધતિ બદલીએ છીએ.

3-2-1 નિયમની મહત્તમ અસર હાંસલ કરવા માટે, સ્ટોરેજ ફોર્મેટને બંને રીતે બદલવાની ભલામણ કરવામાં આવે છે.

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

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

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

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

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

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

ipsos custodes quis custodiet?

(પોતે ચોકીદારની રક્ષા કોણ કરશે? - lat.)

જ્યારે કોઈ બેકઅપ નકલો ન હોય ત્યારે તે ખૂબ જ અપ્રિય છે, પરંતુ જો બેકઅપ કૉપિ બનાવવામાં આવી હોય તેવું લાગે તો તે વધુ ખરાબ છે, પરંતુ જ્યારે પુનઃસ્થાપિત કરવામાં આવે છે ત્યારે તે તારણ આપે છે કે તે પુનઃસ્થાપિત કરી શકાતી નથી કારણ કે:

• સ્ત્રોત ડેટાની અખંડિતતા સાથે ચેડા કરવામાં આવ્યા છે.
• બેકઅપ સ્ટોરેજ ક્ષતિગ્રસ્ત છે.
• પુનઃપ્રાપ્તિ ખૂબ જ ધીરે ધીરે કાર્ય કરે છે; તમે આંશિક રીતે પુનઃપ્રાપ્ત કરવામાં આવેલ ડેટાનો ઉપયોગ કરી શકતા નથી.

યોગ્ય રીતે બાંધવામાં આવેલી બેકઅપ પ્રક્રિયાએ આવી ટિપ્પણીઓને ધ્યાનમાં લેવી જોઈએ, ખાસ કરીને પ્રથમ બે.

સ્ત્રોત ડેટાની અખંડિતતાની ખાતરી ઘણી રીતે આપી શકાય છે. સૌથી વધુ ઉપયોગમાં લેવાતા નીચેનાનો છે: a) બ્લોક સ્તરે ફાઇલ સિસ્ટમના સ્નેપશોટ બનાવવા, b) ફાઇલ સિસ્ટમની સ્થિતિ "ફ્રીઝિંગ", c) સંસ્કરણ સ્ટોરેજ સાથેનું વિશિષ્ટ બ્લોક ઉપકરણ, ડી) ફાઇલોનું ક્રમિક રેકોર્ડિંગ અથવા બ્લોક્સ પુનઃપ્રાપ્તિ દરમિયાન ડેટાની ચકાસણી થાય તેની ખાતરી કરવા માટે ચેકસમ પણ લાગુ કરવામાં આવે છે.

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

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

મસાલાનો નિષ્ણાત તે નથી જે તેને દરેક વાનગીમાં ઉમેરે છે, પરંતુ તે જે ક્યારેય તેમાં વધારાનું કંઈ ઉમેરતું નથી.

-IN. સિન્યાવસ્કી

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

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

બ્લોક ઉપકરણોમાંથી બેકઅપ લેવા માટે નીચેના સામાન્ય પ્રોગ્રામ્સ છે:

• dd, સિસ્ટમ એડમિનિસ્ટ્રેશન વેટરન્સથી પરિચિત છે, આમાં સમાન પ્રોગ્રામ્સનો પણ સમાવેશ થાય છે (ઉદાહરણ તરીકે સમાન dd_rescue).
• કેટલીક ફાઇલ સિસ્ટમમાં બનેલી ઉપયોગિતાઓ જે ફાઇલ સિસ્ટમનો ડમ્પ બનાવે છે.
• સર્વભક્ષી ઉપયોગિતાઓ; ઉદાહરણ તરીકે પાર્ટક્લોન.
• પોતાના, ઘણીવાર માલિકીના, નિર્ણયો; ઉદાહરણ તરીકે, NortonGhost અને પછી.

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

• Rsync, ફાઇલ સિસ્ટમની સ્થિતિને સિંક્રનાઇઝ કરવા માટેનો સામાન્ય હેતુનો પ્રોગ્રામ અને પ્રોટોકોલ.
• બિલ્ટ-ઇન આર્કાઇવિંગ ટૂલ્સ (ZFS).
• તૃતીય પક્ષ આર્કાઇવિંગ સાધનો; સૌથી લોકપ્રિય પ્રતિનિધિ ટાર છે. ત્યાં અન્ય છે, ઉદાહરણ તરીકે, ડાર - આધુનિક સિસ્ટમોને ધ્યાનમાં રાખીને ટાર માટે રિપ્લેસમેન્ટ.

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

• ફાઇલ સિસ્ટમને ફક્ત-વાંચવા માટેના મોડમાં માઉન્ટ કરવી (ઓનલી વાંચવા), અથવા ફાઇલ સિસ્ટમને ફ્રીઝ કરવી (ફ્રીઝ) - પદ્ધતિ મર્યાદિત લાગુ પડે છે.
• ફાઇલ સિસ્ટમો અથવા બ્લોક ઉપકરણોની સ્થિતિના સ્નેપશોટ બનાવી રહ્યા છે (LVM, ZFS).
• છાપ ગોઠવવા માટે તૃતીય-પક્ષ સાધનોનો ઉપયોગ, એવા કિસ્સામાં પણ કે જ્યાં અગાઉના મુદ્દાઓ અમુક કારણોસર પ્રદાન કરી શકાતા નથી (હોટકોપી જેવા પ્રોગ્રામ્સ).
• કૉપિ-ઑન-ચેન્જ ટેકનિક (CopyOnWrite), જો કે, તે મોટાભાગે ઉપયોગમાં લેવાતી ફાઇલ સિસ્ટમ (BTRFS, ZFS) સાથે જોડાયેલી હોય છે.

તેથી, નાના સર્વર માટે તમારે બેકઅપ સ્કીમ પ્રદાન કરવાની જરૂર છે જે નીચેની આવશ્યકતાઓને પૂર્ણ કરે છે:

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

જેઓ વધુ કે ઓછા જરૂરિયાતોને પૂર્ણ કરે છે તેમના અરજદારો:

• rdiff-બેકઅપ
• rsnapshot
• ઓડકાર
• ડુપ્લિકેટ
• ડુપ્લિકેટ
• ચાલવા દો
• દર
• zbackup
• રેસ્ટિક
• બોર્ગબેકઅપ

નીચેની લાક્ષણિકતાઓ સાથે વર્ચ્યુઅલ મશીન (XenServer પર આધારિત) નો ઉપયોગ ટેસ્ટ બેન્ચ તરીકે કરવામાં આવશે:

• 4 કોર 2.5 GHz,
• 16 જીબી રેમ,
• 50 જીબી હાઇબ્રિડ સ્ટોરેજ (વર્ચ્યુઅલ ડિસ્ક સાઈઝના 20% SSD પર કેશીંગ સાથે સ્ટોરેજ સિસ્ટમ) પાર્ટીશન કર્યા વિના અલગ વર્ચ્યુઅલ ડિસ્કના સ્વરૂપમાં,
• 200 Mbits ઈન્ટરનેટ ચેનલ.

લગભગ સમાન મશીનનો ઉપયોગ બેકઅપ રીસીવર સર્વર તરીકે કરવામાં આવશે, ફક્ત 500 GB હાર્ડ ડ્રાઈવ સાથે.

ઓપરેટિંગ સિસ્ટમ - Centos 7 x64: પ્રમાણભૂત પાર્ટીશન, વધારાના પાર્ટીશનનો ઉપયોગ ડેટા સ્ત્રોત તરીકે કરવામાં આવશે.

પ્રારંભિક ડેટા તરીકે, ચાલો 40 GB મીડિયા ફાઇલો અને mysql ડેટાબેઝ સાથે વર્ડપ્રેસ સાઇટ લઈએ. વર્ચ્યુઅલ સર્વર્સ લાક્ષણિકતાઓમાં મોટા પ્રમાણમાં બદલાતા હોવાથી અને વધુ સારી પ્રજનનક્ષમતા માટે, અહીં છે

sysbench નો ઉપયોગ કરીને સર્વર પરીક્ષણ પરિણામો.sysbench --threads=4 --time=30 --cpu-max-prime=20000 cpu રન
sysbench 1.1.0-18a9f86 (બંડલ કરેલ LuaJIT 2.1.0-beta3 નો ઉપયોગ કરીને)
નીચેના વિકલ્પો સાથે પરીક્ષણ ચલાવવું:
થ્રેડોની સંખ્યા: 4
વર્તમાન સમયથી રેન્ડમ નંબર જનરેટર શરૂ કરી રહ્યા છીએ

પ્રાઇમ નંબરની મર્યાદા: 20000

વર્કર થ્રેડ શરૂ કરી રહ્યાં છીએ...

દોરા શરૂ થયાં!

સીપીયુ ગતિ:
ઇવેન્ટ્સ પ્રતિ સેકન્ડ: 836.69

થ્રુપુટ:
ઇવેન્ટ/સે (ઇપીએસ): 836.6908
સમય વીત્યો: 30.0039
ઇવેન્ટની કુલ સંખ્યા: 25104

લેટન્સી (ms):
મિનિટ: 2.38
સરેરાશ: 4.78
મહત્તમ: 22.39
95મી પર્સેન્ટાઇલ: 10.46
સરવાળો: 119923.64

થ્રેડો નિષ્પક્ષતા:
ઇવેન્ટ્સ (avg/stddev): 6276.0000/13.91
અમલનો સમય (avg/stddev): 29.9809/0.01

sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=read મેમરી રન
sysbench 1.1.0-18a9f86 (બંડલ કરેલ LuaJIT 2.1.0-beta3 નો ઉપયોગ કરીને)
નીચેના વિકલ્પો સાથે પરીક્ષણ ચલાવવું:
થ્રેડોની સંખ્યા: 4
વર્તમાન સમયથી રેન્ડમ નંબર જનરેટર શરૂ કરી રહ્યા છીએ

નીચેના વિકલ્પો સાથે મેમરી સ્પીડ ટેસ્ટ ચલાવો:
બ્લોક કદ: 1KiB
કુલ કદ: 102400MiB
ઓપરેશન: વાંચો
અવકાશ: વૈશ્વિક

વર્કર થ્રેડ શરૂ કરી રહ્યાં છીએ...

દોરા શરૂ થયાં!

કુલ કામગીરી: 50900446 (1696677.10 પ્રતિ સેકન્ડ)

49707.47 MiB ટ્રાન્સફર (1656.91 MiB/sec)

થ્રુપુટ:
ઇવેન્ટ/સે (ઇપીએસ): 1696677.1017
સમય વીત્યો: 30.0001
ઇવેન્ટની કુલ સંખ્યા: 50900446

લેટન્સી (ms):
મિનિટ: 0.00
સરેરાશ: 0.00
મહત્તમ: 24.01
95મી પર્સેન્ટાઇલ: 0.00
સરવાળો: 39106.74

થ્રેડો નિષ્પક્ષતા:
ઇવેન્ટ્સ (avg/stddev): 12725111.5000/137775.15
અમલનો સમય (avg/stddev): 9.7767/0.10

sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=write memory run
sysbench 1.1.0-18a9f86 (બંડલ કરેલ LuaJIT 2.1.0-beta3 નો ઉપયોગ કરીને)
નીચેના વિકલ્પો સાથે પરીક્ષણ ચલાવવું:
થ્રેડોની સંખ્યા: 4
વર્તમાન સમયથી રેન્ડમ નંબર જનરેટર શરૂ કરી રહ્યા છીએ

નીચેના વિકલ્પો સાથે મેમરી સ્પીડ ટેસ્ટ ચલાવો:
બ્લોક કદ: 1KiB
કુલ કદ: 102400MiB
ઓપરેશન: લખો
અવકાશ: વૈશ્વિક

વર્કર થ્રેડ શરૂ કરી રહ્યાં છીએ...

દોરા શરૂ થયાં!

કુલ કામગીરી: 35910413 (1197008.62 પ્રતિ સેકન્ડ)

35068.76 MiB ટ્રાન્સફર (1168.95 MiB/sec)

થ્રુપુટ:
ઇવેન્ટ/સે (ઇપીએસ): 1197008.6179
સમય વીત્યો: 30.0001
ઇવેન્ટની કુલ સંખ્યા: 35910413

લેટન્સી (ms):
મિનિટ: 0.00
સરેરાશ: 0.00
મહત્તમ: 16.90
95મી પર્સેન્ટાઇલ: 0.00
સરવાળો: 43604.83

થ્રેડો નિષ્પક્ષતા:
ઇવેન્ટ્સ (avg/stddev): 8977603.2500/233905.84
અમલનો સમય (avg/stddev): 10.9012/0.41

sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G ફાઇલિયો રન
sysbench 1.1.0-18a9f86 (બંડલ કરેલ LuaJIT 2.1.0-beta3 નો ઉપયોગ કરીને)
નીચેના વિકલ્પો સાથે પરીક્ષણ ચલાવવું:
થ્રેડોની સંખ્યા: 4
વર્તમાન સમયથી રેન્ડમ નંબર જનરેટર શરૂ કરી રહ્યા છીએ

વધારાની ફાઇલ ઓપન ફ્લેગ્સ: (કોઈ નહીં)
128 ફાઇલો, દરેક 8MiB
1GiB કુલ ફાઇલ કદ
બ્લોક કદ 4KiB
IO વિનંતીઓની સંખ્યા: 0
સંયુક્ત રેન્ડમ IO ટેસ્ટ માટે વાંચન/લખવાનો ગુણોત્તર: 1.50
સામયિક FSYNC સક્ષમ છે, દરેક 100 વિનંતીઓને fsync() કૉલ કરે છે.
પરીક્ષણના અંતે fsync() ને કૉલ કરવું, સક્ષમ.
સિંક્રનસ I/O મોડનો ઉપયોગ
રેન્ડમ r/w ટેસ્ટ કરી રહ્યા છીએ
વર્કર થ્રેડ શરૂ કરી રહ્યાં છીએ...

દોરા શરૂ થયાં!

થ્રુપુટ:
વાંચો: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
લખો: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98

લેટન્સી (ms):
મિનિટ: 0.00
સરેરાશ: 0.27
મહત્તમ: 18.01
95મી પર્સેન્ટાઇલ: 1.08
સરવાળો: 238469.45

આ નોંધ એક મોટી શરૂઆત કરે છે

બેકઅપ વિશે લેખોની શ્રેણી

1. બેકઅપ, ભાગ 1: શા માટે બેકઅપની જરૂર છે, પદ્ધતિઓ, તકનીકોની ઝાંખી
2. બેકઅપ ભાગ 2: rsync-આધારિત બેકઅપ સાધનોની સમીક્ષા અને પરીક્ષણ
3. બેકઅપ ભાગ 3: ડુપ્લીસીટી, ડુપ્લીકેટી, ડીજા ડુપની સમીક્ષા અને પરીક્ષણ
4. બેકઅપ ભાગ 4: ઝેડબેકઅપ, રેસ્ટિક, બોર્ગબેકઅપની સમીક્ષા અને પરીક્ષણ
5. બેકઅપ ભાગ 5: લિનક્સ માટે બેક્યુલા અને વીમ બેકઅપનું પરીક્ષણ
6. બેકઅપ ભાગ 6: બેકઅપ સાધનોની સરખામણી
7. બેકઅપ ભાગ 7: તારણો

સોર્સ: www.habr.com