Овај чланак ће упоредити алате за прављење резервних копија, али прво би требало да сазнате колико брзо и добро се носе са враћањем података из резервних копија.
Ради лакшег поређења, размотрићемо враћање из пуне резервне копије, посебно зато што сви кандидати подржавају овај начин рада. Ради једноставности, бројеви су већ усредњени (аритметичка средина неколико серија). Резултати ће бити сумирани у табели, која ће такође садржати информације о могућностима: присуство веб интерфејса, једноставност подешавања и рада, могућност аутоматизације, присуство разних додатних функција (на пример, провера интегритета података) , итд. Графикони ће показати оптерећење сервера на коме ће се подаци користити (не сервер за чување резервних копија).
Опоравак података
рсинц и тар ће се користити као референтна тачка од једноставне скрипте за прављење резервних копија.
Рсинц се носио са скупом података теста за 4 минута и 28 секунди, показујући
такво оптерећење
Процес опоравка је погодио ограничење дисковног подсистема сервера за складиштење резервних копија (тестернасти графикони). Такође можете јасно видети учитавање једног кернела без икаквих проблема (низак иоваит и софтирк - нема проблема са диском и мрежом, респективно). Пошто су друга два програма, наиме рдифф-бацкуп и рснапсхот, заснована на рсинц-у и такође нуде редован рсинц као алатку за опоравак, они ће имати приближно исти профил учитавања и време опоравка резервне копије.
Тар урадио то мало брже
2 минута и 43 секунде:
Укупно оптерећење система је у просеку било веће за 20% због повећаног софтирк-а – повећани су режијски трошкови током рада мрежног подсистема.
Ако се архива додатно компримује, време опоравка се повећава на 3 минута и 19 секунди.
са таквим оптерећењем на главном серверу (распакивање са стране главног сервера):
Процес декомпресије заузима оба процесорска језгра јер постоје два процеса. Генерално, ово је очекивани резултат. Такође, упоредиви резултат (3 минута и 20 секунди) је добијен када је покренут гзип на страни сервера са резервним копијама; профил учитавања на главном серверу је био веома сличан покретању тар без гзип компресора (погледајте претходни графикон).
В рдифф-бацкуп можете да синхронизујете последњу резервну копију коју сте направили користећи регуларни рсинц (резултати ће бити слични), али старије резервне копије и даље треба да се врате помоћу рдифф-бацкуп програма, који је завршио обнављање за 17 минута и 17 секунди, што показује
ово оптерећење:
Можда је ово било намењено, барем да се ограничи брзина аутора . Сам процес враћања резервне копије траје нешто мање од половине једног језгра, са пропорционално упоредивим перформансама (тј. 2-5 пута споријим) преко диска и мреже са рсинц-ом.
Рснапсхот За опоравак предлаже коришћење редовног рсинц-а, тако да ће његови резултати бити слични. Генерално, овако се испоставило.
Подригивање Задатак враћања резервне копије завршио сам за 7 минута и 2 секунде са
са овим оптерећењем:
Радило је прилично брзо, и барем је много згодније од чистог рсинц-а: не морате да памтите ниједну заставу, једноставан и интуитиван цли интерфејс, уграђену подршку за више копија – иако је два пута спорији. Ако треба да вратите податке из последње резервне копије коју сте направили, можете да користите рсинц, уз неколико упозорења.
Програм је показао приближно исту брзину и оптерећење БацкупПЦ када омогућавате рсинц режим преноса, постављате резервну копију за
7 минута и 42 секунде:
Али у режиму преноса података, БацкупПЦ се спорије носио са тар: за 12 минута и 15 секунди оптерећење процесора је генерално било мање
један и по пута:
Дуплицити без енкрипције показао је нешто боље резултате, враћајући резервну копију за 10 минута и 58 секунди. Ако активирате шифровање помоћу гпг-а, време опоравка се повећава на 15 минута и 3 секунде. Такође, када креирате спремиште за чување копија, можете одредити величину архиве која ће се користити приликом раздвајања долазног тока података. Генерално, на конвенционалним чврстим дисковима, такође због једнонитног режима рада, нема велике разлике. Може се појавити у различитим величинама блокова када се користи хибридно складиште. Оптерећење главног сервера током опоравка било је следеће:
нема енкрипције
са шифровањем
Дупликат показао упоредиву стопу опоравка, завршивши га за 13 минута и 45 секунди. Требало је још око 5 минута да се провери тачност опорављених података (укупно око 19 минута). Оптерећење је било
прилично висок:
Када је аес енкрипција интерно омогућена, време опоравка је било 21 минут и 40 секунди, са максималном искоришћеношћу ЦПУ-а (оба језгра!) током опоравка; Приликом провере података била је активна само једна нит која је заузимала једно језгро процесора. Провера података након опоравка трајала је истих 5 минута (укупно скоро 27 минута).
Резултат
дуплицати је био мало бржи са опоравком када се користи екстерни гпг програм за шифровање, али генерално разлике у односу на претходни режим су минималне. Време рада је било 16 минута и 30 секунди, уз проверу података за 6 минута. Оптерећење је било
такав:
АМАНДА, користећи тар, завршио га је за 2 минута и 49 секунди, што је у принципу веома близу обичном катрану. Оптерећење система у принципу
исти:
Када враћате резервну копију користећи збацкуп добијени су следећи резултати:
енкрипција, лзма компресија
Трајање 11 минута и 8 секунди
АЕС енкрипција, лзма компресија
Радно време 14 минута
АЕС енкрипција, лзо компресија
Трајање 6 минута, 19 секунди
Генерално, није лоше. Све зависи од брзине процесора на бацкуп серверу, што се јасно види из времена рада програма са различитим компресорима. На страни резервног сервера је покренут обичан тар, па ако га упоредите са њим, опоравак је 3 пута спорији. Можда би било вредно проверити рад у вишенитном режиму, са више од две нити.
БоргБацкуп у нешифрованом режиму био је мало спорији од тар-а, за 2 минута и 45 секунди, међутим, за разлику од тар-а, постало је могуће дедуплицирати спремиште. Испоставило се да је оптерећење
следећи:
Ако омогућите шифровање засновано на Блаке-у, брзина опоравка резервне копије је нешто спорија. Време опоравка у овом режиму је 3 минута и 19 секунди, а оптерећење је нестало
овако:
АЕС енкрипција је нешто спорија, време опоравка је 3 минута 23 секунде, оптерећење је посебно
није се променило:
Пошто Борг може да ради у вишенитном режиму, оптерећење процесора је максимално, а када се активирају додатне функције, време рада се једноставно повећава. Очигледно, вреди истражити вишенитност на сличан начин као збацкуп.
Рестиц мало спорије се носио са опоравком, време рада је било 4 минута 28 секунди. Оптерећење је изгледало као
тако:
Очигледно процес опоравка функционише у неколико нити, али ефикасност није тако висока као БоргБацкуп, али је упоредива по времену са редовним рсинц-ом.
Са УрБацкуп Податке је било могуће вратити за 8 минута и 19 секунди, оптерећење је било
такав:
Оптерећење још увек није велико, чак ниже од оног код катрана. На неким местима има рафала, али не више од оптерећења једног језгра.
Избор и оправданост критеријума за поређење
Као што је наведено у једном од претходних чланака, систем резервних копија мора да испуњава следеће критеријуме:
- Лакоћа коришћења
- прилагодљивост
- Стабилност
- Брзина
Вреди детаљније размотрити сваку тачку посебно.
Лакоћа рада
Најбоље је када постоји једно дугме „Уради све добро“, али ако се вратите на праве програме, најпогодније ће бити неки познати и стандардни принцип рада.
Већини корисника ће највероватније бити боље ако не морају да памте гомилу тастера за цли, да конфигуришу гомилу различитих, често нејасних опција путем веба или туи-а, или да подесе обавештења о неуспешном раду. Ово такође укључује могућност лаког „уклапања“ решења за резервну копију у постојећу инфраструктуру, као и аутоматизацију процеса прављења резервних копија. Такође постоји могућност инсталације помоћу менаџера пакета, или у једној или две команде попут „преузми и распакирај“. curl ссылка | sudo bash - сложен метод, пошто треба да проверите шта стиже преко линка.
На пример, од разматраних кандидата, једноставно решење су бурп, рдифф-бацкуп и рестиц, који имају мнемоничке тастере за различите режиме рада. Нешто сложенији су борг и дволичност. Најтеже је било АМАНДИ. Остали су негде у средини у погледу једноставности коришћења. У сваком случају, ако вам је потребно више од 30 секунди да прочитате упутство за употребу, или морате да одете на Гоогле или неки други претраживач, а такође и да прелистате дугачку листу помоћи, одлука је тешка, на овај или онај начин.
Неки од разматраних кандидата могу аутоматски да пошаљу поруку путем е-маиљаббер-а, док се други ослањају на конфигурисана упозорења у систему. Штавише, најчешће сложена решења немају сасвим очигледна подешавања упозорења. У сваком случају, ако програм за резервну копију произведе повратни код различит од нуле, који ће системски сервис исправно разумети за периодичне задатке (порука ће бити послата администратору система или директно надгледању) - ситуација је једноставна. Али ако систем резервних копија, који не ради на резервном серверу, не може да се конфигурише, очигледан начин да се каже о проблему је да је сложеност већ превелика. У сваком случају, издавање упозорења и других порука само на веб интерфејс или дневник је лоша пракса, јер ће најчешће бити игнорисана.
Што се тиче аутоматизације, једноставан програм може да чита променљиве окружења које постављају његов режим рада, или има развијен клиј који може у потпуности да дуплира понашање при раду преко веб интерфејса, на пример. Ово такође укључује могућност континуираног рада, доступност могућности проширења итд.
прилагодљивост
Делимично понављајући претходни пододељак у вези са аутоматизацијом, не би требало да буде посебан проблем „уклопити“ процес резервне копије у постојећу инфраструктуру.
Вреди напоменути да су употреба нестандардних портова (па, осим веб интерфејса) за рад, имплементација шифровања на нестандардан начин, размена података коришћењем нестандардног протокола знаци нестандардног - универзално решење. Углавном, сви кандидати их имају на овај или онај начин из очигледног разлога: једноставност и свестраност обично не иду заједно. Као изузетак - подригивање, постоје и други.
Као знак - способност рада користећи обичан ссх.
Радна брзина
Најконтроверзнија и најконтроверзнија тачка. С једне стране, покренули смо процес, радио је што је брже могуће и није ометао главне задатке. С друге стране, постоји пораст саобраћаја и оптерећења процесора током периода резервне копије. Такође је вредно напоменути да су најбржи програми за прављење копија обично најсиромашнији у погледу функција које су корисницима важне. Опет: ако да бисте добили једну несрећну текстуалну датотеку од неколико десетина бајтова са лозинком и због тога кошта цела услуга (да, да, разумем да процес прављења резервних копија најчешће није крив) и потребно је да поново прочитате узастопно све датотеке у спремишту или да проширите целу архиву - систем резервних копија никада није брз. Још једна ствар која често постаје камен спотицања је брзина постављања резервне копије из архиве. Овде постоји јасна предност за оне који могу једноставно да копирају или преместе датотеке на жељену локацију без много манипулације (рсинц, на пример), али најчешће проблем мора да се реши на организациони начин, емпиријски: мерењем времена опоравка резервне копије и отворено обавештавање корисника о томе.
Стабилност
То треба схватити овако: с једне стране, мора бити могуће да се резервна копија врати на било који начин, с друге стране, она мора бити отпорна на различите проблеме: прекид мреже, квар диска, брисање дијела репозиторијум.
Поређење алата за прављење резервних копија
Време креирања копије
Време опоравка копије
Једноставна инсталација
Простаа настројка
Једноставна употреба
Једноставна аутоматизација
Да ли вам је потребан клијент сервер?
Провера интегритета спремишта
Диференцијалне копије
Рад преко цеви
прилагодљивост
Независност
Транспарентност спремишта
Шифровање
Компресија
Дедупликација
Веб интерфејс
Пуњење до облака
Виндовс подршка
Сцоре
Рсинц
4м15с
4м28с
да
не
не
не
да
не
не
да
не
да
да
не
не
не
не
не
да
6
Тар
чист
3м12с
2м43с
да
не
не
не
не
не
да
да
не
да
не
не
не
не
не
не
да
8,5
Уник
9м37с
3м19с
да
Рдифф-бацкуп
16м26с
17м17с
да
да
да
да
да
не
да
не
да
не
да
не
да
да
да
не
да
11
Рснапсхот
4м19с
4м28с
да
да
да
да
не
не
да
не
да
не
да
не
не
да
да
не
да
12,5
Подригивање
11м9с
7м2с
да
не
да
да
да
да
да
не
да
да
не
не
да
не
да
не
да
10,5
Дуплицити
нема енкрипције
16м48с
10м58с
да
да
не
да
не
да
да
не
не
да
не
да
да
не
да
не
да
11
гпг
17м27с
15м3с
Дупликат
нема енкрипције
20м28с
13м45с
не
да
не
не
не
да
да
не
не
да
не
да
да
да
да
да
да
11
АЕС
29м41с
21м40с
гпг
26м19с
16м30с
Збацкуп
нема енкрипције
40м3с
11м8с
да
да
не
не
не
да
да
да
не
да
не
да
да
да
не
не
не
10
АЕС
42м0с
14м1с
аес+лзо
18м9с
6м19с
БоргБацкуп
нема енкрипције
4м7с
2м45с
да
да
да
да
да
да
да
да
да
да
не
да
да
да
да
не
да
16
АЕС
4м58с
3м23с
блакеКСНУМКС
4м39с
3м19с
Рестиц
5м38с
4м28с
да
да
да
да
не
да
да
да
да
да
не
да
не
да
не
да
да
15,5
УрБацкуп
8м21с
8м19с
да
да
да
не
да
не
да
не
да
да
не
да
да
да
да
не
да
12
Аманда
9м3с
2м49с
да
не
не
да
да
да
да
не
да
да
да
да
да
не
да
да
да
13
БацкупПЦ
рсинц
12м22с
7м42с
да
не
да
да
да
да
да
не
да
не
не
да
да
не
да
не
да
10,5
катран
12м34с
12м15с
Легенда табеле:
- Зелено, време рада мање од пет минута, или одговор са „Да“ (осим колоне „Потребан вам је клијент сервер?“), 1 бод
- Жуто, време рада пет до десет минута, 0.5 поена
- Црвено, време рада је дуже од десет минута, или је одговор „Не“ (осим колоне „Да ли вам треба клијент сервер?“), 0 поена
Према горњој табели, најједноставнији, најбржи, а истовремено погодан и моћан алат за прављење резервних копија је БоргБацкуп. Рестић је заузео друго место, остали разматрани кандидати су пласирани приближно равноправно са размаком од једног или два поена на крају.
Захваљујем се свима који су прочитали серију до краја, позивам вас да разговарате о опцијама и понудите своје, ако их има. Како дискусија буде напредовала, табела се може проширивати.
Резултат серије ће бити завршни чланак, у којем ће се покушати развити идеалан, брз и управљив алат за прављење резервних копија који вам омогућава да вратите копију у најкраћем могућем року и истовремено буде згодан и лак за конфигурисање и одржавање.
Најава
Резервна копија, део 6: Поређење алата за прављење резервних копија
Резервни део 7: Закључци
Извор: ввв.хабр.цом