બેકઅપ ભાગ 6: બેકઅપ સાધનોની સરખામણી

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

માહિતી પુનઃ પ્રાપ્તિ

rsync અને tar ત્યારથી સંદર્ભ બિંદુ તરીકે ઉપયોગમાં લેવાશે તેઓ સામાન્ય રીતે તેમના પર આધારિત છે બેકઅપ નકલો બનાવવા માટે સરળ સ્ક્રિપ્ટો.

રૂ 4 મિનિટ અને 28 સેકન્ડમાં સેટ કરેલા ટેસ્ટ ડેટા સાથે સામનો, દર્શાવે છે

આવો ભાર

પુનઃપ્રાપ્તિ પ્રક્રિયા બેકઅપ સ્ટોરેજ સર્વરની ડિસ્ક સબસિસ્ટમની મર્યાદાને અસર કરે છે (sawtooth ગ્રાફ્સ). તમે કોઈપણ સમસ્યા વિના એક કર્નલનું લોડિંગ સ્પષ્ટપણે જોઈ શકો છો (ઓછી iowait અને softirq - અનુક્રમે ડિસ્ક અને નેટવર્ક સાથે કોઈ સમસ્યા નથી). અન્ય બે પ્રોગ્રામ્સ, જેમ કે rdiff-backup અને rsnapshot, rsync પર આધારિત હોવાથી અને પુનઃપ્રાપ્તિ સાધન તરીકે નિયમિત rsync પણ ઓફર કરે છે, તેમની પાસે લગભગ સમાન લોડ પ્રોફાઇલ અને બેકઅપ પુનઃપ્રાપ્તિ સમય હશે.

તાર તેને થોડું ઝડપી કર્યું

2 મિનિટ અને 43 સેકન્ડ:

વધતા સોફ્ટિર્કને કારણે કુલ સિસ્ટમ લોડ સરેરાશ 20% વધારે હતો - નેટવર્ક સબસિસ્ટમના સંચાલન દરમિયાન ઓવરહેડ ખર્ચમાં વધારો થયો હતો.

જો આર્કાઇવને વધુ સંકુચિત કરવામાં આવે છે, તો પુનઃપ્રાપ્તિ સમય વધીને 3 મિનિટ 19 સેકન્ડ થાય છે.
મુખ્ય સર્વર પર આવા ભાર સાથે (મુખ્ય સર્વરની બાજુ પર અનપેક કરવું):

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

В rdiff-બેકઅપ તમે નિયમિત rsync નો ઉપયોગ કરીને બનાવેલા છેલ્લા બેકઅપને સિંક્રનાઇઝ કરી શકો છો (પરિણામો સમાન હશે), પરંતુ જૂના બેકઅપને હજુ પણ rdiff-બેકઅપ પ્રોગ્રામનો ઉપયોગ કરીને પુનઃસ્થાપિત કરવાની જરૂર છે, જેણે 17 મિનિટ અને 17 સેકન્ડમાં પુનઃસ્થાપન પૂર્ણ કર્યું હતું, જે દર્શાવે છે.

આ ભાર:

કદાચ આનો હેતુ લેખકોની ગતિને મર્યાદિત કરવાનો હતો આવા ઉકેલ ઓફર કરે છે. rsync સાથે ડિસ્ક અને નેટવર્ક પર પ્રમાણસર તુલનાત્મક કામગીરી (એટલે ​​​​કે 2-5 ગણી ધીમી) સાથે, બેકઅપ કોપી પુનઃસ્થાપિત કરવાની પ્રક્રિયા પોતે એક કોરના અડધા કરતા થોડો ઓછો સમય લે છે.

રૂનેપશોટ પુનઃપ્રાપ્તિ માટે, તે નિયમિત rsync નો ઉપયોગ કરવાનું સૂચન કરે છે, તેથી તેના પરિણામો સમાન હશે. સામાન્ય રીતે, તે આ રીતે બહાર આવ્યું છે.

ઓડકાર મેં 7 મિનિટ અને 2 સેકન્ડમાં બેકઅપ પુનઃસ્થાપિત કરવાનું કાર્ય પૂર્ણ કર્યું
આ ભાર સાથે:

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

પ્રોગ્રામ લગભગ સમાન ઝડપ અને લોડ દર્શાવે છે બેકઅપપીસી જ્યારે rsync ટ્રાન્સફર મોડને સક્ષમ કરી રહ્યા હોય, ત્યારે માટે બેકઅપ જમાવતા

7 મિનિટ અને 42 સેકન્ડ:

પરંતુ ડેટા ટ્રાન્સફર મોડમાં, બેકઅપપીસીએ ટારનો વધુ ધીમેથી સામનો કર્યો: 12 મિનિટ અને 15 સેકન્ડમાં, પ્રોસેસર લોડ સામાન્ય રીતે ઓછો હતો

દોઢ વખત:

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

કોઈ એન્ક્રિપ્શન નથી

એન્ક્રિપ્શન સાથે

ડુપ્લિકેટ 13 મિનિટ અને 45 સેકન્ડમાં પૂર્ણ કરીને તુલનાત્મક પુનઃપ્રાપ્તિ દર દર્શાવ્યો. પુનઃપ્રાપ્ત ડેટાની શુદ્ધતા તપાસવામાં લગભગ 5 મિનિટ લાગી (કુલ લગભગ 19 મિનિટ). ભાર હતો

તદ્દન ઊંચું:

જ્યારે aes એન્ક્રિપ્શન આંતરિક રીતે સક્ષમ કરવામાં આવ્યું હતું, ત્યારે પુનઃપ્રાપ્તિ સમય 21 મિનિટ 40 સેકન્ડનો હતો, પુનઃપ્રાપ્તિ દરમિયાન CPU નો મહત્તમ ઉપયોગ (બંને કોરો!) સાથે; ડેટા તપાસતી વખતે, માત્ર એક થ્રેડ સક્રિય હતો, જે એક પ્રોસેસર કોર પર કબજો કરે છે. પુનઃપ્રાપ્તિ પછી ડેટા તપાસવામાં સમાન 5 મિનિટનો સમય લાગ્યો (કુલ લગભગ 27 મિનિટ).

પરિણામ

એન્ક્રિપ્શન માટે બાહ્ય gpg પ્રોગ્રામનો ઉપયોગ કરતી વખતે ડુપ્લિકેટી પુનઃપ્રાપ્તિ સાથે થોડી ઝડપી હતી, પરંતુ સામાન્ય રીતે અગાઉના મોડથી તફાવતો ન્યૂનતમ છે. ઓપરેટિંગ સમય 16 મિનિટ 30 સેકન્ડનો હતો, 6 મિનિટમાં ડેટા વેરિફિકેશન સાથે. ભાર હતો

જેમ કે

અમાન્દા, ટારનો ઉપયોગ કરીને, તેને 2 મિનિટ 49 સેકન્ડમાં પૂર્ણ કર્યું, જે, સૈદ્ધાંતિક રીતે, નિયમિત ટારની ખૂબ નજીક છે. સિદ્ધાંતમાં સિસ્ટમ પર લોડ કરો

સમાન:

ઉપયોગ કરીને બેકઅપ પુનઃસ્થાપિત કરતી વખતે zbackup નીચેના પરિણામો પ્રાપ્ત થયા:

એન્ક્રિપ્શન, lzma કમ્પ્રેશન

દોડવાનો સમય 11 મિનિટ અને 8 સેકન્ડ

AES એન્ક્રિપ્શન, lzma કમ્પ્રેશન

ઓપરેટિંગ સમય 14 મિનિટ

AES એન્ક્રિપ્શન, lzo કમ્પ્રેશન

દોડવાનો સમય 6 મિનિટ, 19 સેકન્ડ

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

બોર્ગબેકઅપ અનએન્ક્રિપ્ટેડ મોડમાં તે ટાર કરતાં થોડું ધીમું હતું, 2 મિનિટ 45 સેકન્ડમાં, જો કે, ટારથી વિપરીત, રિપોઝીટરીનું ડુપ્લિકેટ કરવું શક્ય બન્યું. ભાર નીકળ્યો

નીચે મુજબ:

જો તમે બ્લેક-આધારિત એન્ક્રિપ્શનને સક્ષમ કરો છો, તો બેકઅપ પુનઃપ્રાપ્તિ ઝડપ થોડી ધીમી છે. આ મોડમાં પુનઃપ્રાપ્તિ સમય 3 મિનિટ 19 સેકન્ડ છે, અને લોડ ગયો છે

આની જેમ:

AES એન્ક્રિપ્શન થોડું ધીમું છે, પુનઃપ્રાપ્તિ સમય 3 મિનિટ 23 સેકન્ડ છે, ભાર ખાસ કરીને

બદલાયું નથી:

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

રેસ્ટિક પુનઃપ્રાપ્તિ સાથે થોડો વધુ ધીમેથી સામનો કર્યો, ઓપરેટિંગ સમય 4 મિનિટ 28 સેકન્ડ હતો. ભાર જેવો દેખાતો હતો

તેથી

દેખીતી રીતે પુનઃપ્રાપ્તિ પ્રક્રિયા અનેક થ્રેડોમાં કાર્ય કરે છે, પરંતુ કાર્યક્ષમતા બોર્ગબેકઅપ જેટલી ઊંચી નથી, પરંતુ નિયમિત rsync સાથે સમયસર તુલનાત્મક છે.

ની મદદ સાથે Bરબેકઅપ 8 મિનિટ અને 19 સેકન્ડમાં ડેટા પુનઃસ્થાપિત કરવાનું શક્ય હતું, લોડ હતો

જેમ કે

ભાર હજુ પણ ખૂબ ઊંચો નથી, ટાર કરતાં પણ ઓછો છે. કેટલાક સ્થળોએ વિસ્ફોટો છે, પરંતુ એક કોરના ભારથી વધુ નહીં.

સરખામણી માટે માપદંડોની પસંદગી અને સમર્થન

અગાઉના લેખોમાંના એકમાં જણાવ્યા મુજબ, બેકઅપ સિસ્ટમ નીચેના માપદંડોને પૂર્ણ કરતી હોવી જોઈએ:

• ઉપયોગની સરળતા
• વર્સેટિલિટી
• સ્થિરતા
• ઝડપીતા

દરેક મુદ્દાને વધુ વિગતવાર ધ્યાનમાં લેવા યોગ્ય છે.

કામગીરીમાં સરળતા

જ્યારે "બધું સારું કરો" બટન હોય ત્યારે તે શ્રેષ્ઠ છે, પરંતુ જો તમે વાસ્તવિક પ્રોગ્રામ્સ પર પાછા ફરો, તો સૌથી અનુકૂળ વસ્તુ કેટલાક પરિચિત અને પ્રમાણભૂત ઓપરેટિંગ સિદ્ધાંત હશે.
મોટા ભાગના વપરાશકર્તાઓ મોટે ભાગે વધુ સારું રહેશે જો તેઓએ cli માટે કીનો સમૂહ યાદ રાખવો ન પડે, વેબ અથવા tui દ્વારા વિવિધ, ઘણીવાર અસ્પષ્ટ વિકલ્પોનો સમૂહ ગોઠવવો, અથવા અસફળ કામગીરી વિશે સૂચનાઓ સેટ કરવી ન પડે. આમાં હાલના ઈન્ફ્રાસ્ટ્રક્ચરમાં બેકઅપ સોલ્યુશનને સરળતાથી "ફીટ" કરવાની ક્ષમતા તેમજ બેકઅપ પ્રક્રિયાના ઓટોમેશનનો પણ સમાવેશ થાય છે. પેકેજ મેનેજરનો ઉપયોગ કરીને અથવા "ડાઉનલોડ અને અનપેક" જેવા એક અથવા બે આદેશોમાં ઇન્સ્ટોલેશનની શક્યતા પણ છે. curl ссылка | sudo bash - એક જટિલ પદ્ધતિ, કારણ કે તમારે લિંક દ્વારા શું આવે છે તે તપાસવાની જરૂર છે.

ઉદાહરણ તરીકે, ધ્યાનમાં લેવાયેલા ઉમેદવારોમાંથી, એક સરળ ઉકેલ burp, rdiff-બેકઅપ અને રેસ્ટિક છે, જેમાં વિવિધ ઓપરેટિંગ મોડ્સ માટે નેમોનિક કી છે. સહેજ વધુ જટિલ બોર્ગ અને ડુપ્લીસીટી છે. સૌથી મુશ્કેલ અમાન્ડા હતું. બાકીના ઉપયોગની સરળતાના સંદર્ભમાં મધ્યમાં ક્યાંક છે. કોઈ પણ સંજોગોમાં, જો તમારે વપરાશકર્તા માર્ગદર્શિકા વાંચવા માટે 30 સેકન્ડથી વધુ સમયની જરૂર હોય, અથવા તમારે Google અથવા અન્ય સર્ચ એન્જિન પર જવાની જરૂર હોય, અને મદદની લાંબી શીટ દ્વારા સ્ક્રોલ કરવાની પણ જરૂર હોય, તો નિર્ણય મુશ્કેલ છે, એક રીતે અથવા બીજી રીતે.

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

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

વર્સેટિલિટી

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

નિશાની તરીકે - નિયમિત ssh નો ઉપયોગ કરીને કામ કરવાની ક્ષમતા.

કામની ઝડપ

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

સ્થિરતા

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

બેકઅપ સાધનોની સરખામણી

બનાવટ સમયની નકલ કરો
પુનઃપ્રાપ્તિ સમયની નકલ કરો
સરળ સ્થાપન
સરળ સેટઅપ
સરળ ઉપયોગ
સરળ ઓટોમેશન
શું તમને ક્લાયંટ સર્વરની જરૂર છે?
રીપોઝીટરીની અખંડિતતા તપાસી રહ્યું છે
વિભેદક નકલો
પાઇપ દ્વારા કામ
વર્સેટિલિટી
સ્વતંત્રતા
રિપોઝીટરી પારદર્શિતા
એન્ક્રિપ્શન
કમ્પ્રેશન
ડુપ્લિકેશન
વેબ ઈન્ટરફેસ
વાદળમાં ભરવું
વિન્ડોઝ સપોર્ટ
સ્કોર

રૂ
4m15 સે
4m28 સે
હા
કોઈ
કોઈ
કોઈ
હા
કોઈ
કોઈ
હા
કોઈ
હા
હા
કોઈ
કોઈ
કોઈ
કોઈ
કોઈ
હા
6

તાર
શુદ્ધ
3m12 સે
2m43 સે
હા
કોઈ
કોઈ
કોઈ
કોઈ
કોઈ
હા
હા
કોઈ
હા
કોઈ
કોઈ
કોઈ
કોઈ
કોઈ
કોઈ
હા
8,5

જીઝીપ
9m37 સે
3m19 સે
હા

Rdiff-બેકઅપ
16m26 સે
17m17 સે
હા
હા
હા
હા
હા
કોઈ
હા
કોઈ
હા
કોઈ
હા
કોઈ
હા
હા
હા
કોઈ
હા
11

રૂનેપશોટ
4m19 સે
4m28 સે
હા
હા
હા
હા
કોઈ
કોઈ
હા
કોઈ
હા
કોઈ
હા
કોઈ
કોઈ
હા
હા
કોઈ
હા
12,5

ઓડકાર
11m9 સે
7m2 સે
હા
કોઈ
હા
હા
હા
હા
હા
કોઈ
હા
હા
કોઈ
કોઈ
હા
કોઈ
હા
કોઈ
હા
10,5

ડુપ્લિકેશન
કોઈ એન્ક્રિપ્શન નથી
16m48 સે
10m58 સે
હા
હા
કોઈ
હા
કોઈ
હા
હા
કોઈ
કોઈ
હા
કોઈ
હા
હા
કોઈ
હા
કોઈ
હા
11

જી.પી.જી.
17m27 સે
15m3 સે

ડુપ્લિકેટ
કોઈ એન્ક્રિપ્શન નથી
20m28 સે
13m45 સે
કોઈ
હા
કોઈ
કોઈ
કોઈ
હા
હા
કોઈ
કોઈ
હા
કોઈ
હા
હા
હા
હા
હા
હા
11

એઇએસ
29m41 સે
21m40 સે

જી.પી.જી.
26m19 સે
16m30 સે

ઝબbackકઅપ
કોઈ એન્ક્રિપ્શન નથી
40m3 સે
11m8 સે
હા
હા
કોઈ
કોઈ
કોઈ
હા
હા
હા
કોઈ
હા
કોઈ
હા
હા
હા
કોઈ
કોઈ
કોઈ
10

એઇએસ
42m0 સે
14m1 સે

aes+lzo
18m9 સે
6m19 સે

બોર્ગબેકઅપ
કોઈ એન્ક્રિપ્શન નથી
4m7 સે
2m45 સે
હા
હા
હા
હા
હા
હા
હા
હા
હા
હા
કોઈ
હા
હા
હા
હા
કોઈ
હા
16

એઇએસ
4m58 સે
3m23 સે

બ્લેક2
4m39 સે
3m19 સે

રેસ્ટિક
5m38 સે
4m28 સે
હા
હા
હા
હા
કોઈ
હા
હા
હા
હા
હા
કોઈ
હા
કોઈ
હા
કોઈ
હા
હા
15,5

Bરબેકઅપ
8m21 સે
8m19 સે
હા
હા
હા
કોઈ
હા
કોઈ
હા
કોઈ
હા
હા
કોઈ
હા
હા
હા
હા
કોઈ
હા
12

અમાન્દા
9m3 સે
2m49 સે
હા
કોઈ
કોઈ
હા
હા
હા
હા
કોઈ
હા
હા
હા
હા
હા
કોઈ
હા
હા
હા
13

બેકઅપપીસી
rsync
12m22 સે
7m42 સે
હા
કોઈ
હા
હા
હા
હા
હા
કોઈ
હા
કોઈ
કોઈ
હા
હા
કોઈ
હા
કોઈ
હા
10,5

ટાર
12m34 સે
12m15 સે

કોષ્ટક દંતકથા:

• લીલો, ઓપરેટિંગ સમય પાંચ મિનિટથી ઓછો, અથવા જવાબ "હા" ("ક્લાયન્ટ સર્વરની જરૂર છે?" કૉલમ સિવાય), 1 પોઇન્ટ
• પીળો, કાર્યકારી સમય પાંચથી દસ મિનિટ, 0.5 પોઈન્ટ
• લાલ, કામનો સમય દસ મિનિટથી વધુ છે, અથવા જવાબ છે "ના" (સ્તંભ સિવાય "શું તમારે ક્લાયંટ સર્વરની જરૂર છે?"), 0 પોઈન્ટ

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

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

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

ઘોષણા

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

સોર્સ: www.habr.com