Ова напомена о прегледу се наставља
УрБацкуп преглед.
На захтев учесника
У режиму пуне резервне копије добијени су следећи резултати:
Радно време:
Први почетак
Друго лансирање
Треће лансирање
Први тест
8м20с
8м19с
8м24с
Други тест
8м30с
8м34с
8м20с
Трећи тест
8м10с
8м14с
8м12с
У режиму инкременталне резервне копије:
Радно време:
Први почетак
Друго лансирање
Треће лансирање
Први тест
8м10с
8м10с
8м12с
Други тест
3м50с
4м12с
3м34с
Трећи тест
2м50с
2м35с
2м38с
Величина спремишта у оба случаја била је приближно 14 ГБ, што указује на радну дедупликацију на страни сервера. Такође треба напоменути да постоји неслагање између времена креирања резервне копије на серверу и клијенту, што је сасвим јасно видљиво са графикона и представља веома пријатан бонус, пошто веб интерфејс приказује време рада бацкуп процеса на на страни сервера без узимања у обзир
стање клијента. Генерално, графикони за пуне и инкременталне копије се не разликују. Једина разлика је вероватно у томе како се то ради на страни сервера. Такође сам био задовољан ниским оптерећењем процесора на редундантном систему.
БацкупПЦ преглед
На захтев учесника
У режиму прављења пуне резервне копије помоћу рсинц-а добијени су следећи резултати:
Први почетак
Друго лансирање
Треће лансирање
Први тест
12м25с
12м14с
12м27с
Други тест
7м41с
7м44с
7м35с
Трећи тест
10м11с
10м0с
9м54с
Ако користите пуне резервне копије и тар:
Први почетак
Друго лансирање
Треће лансирање
Први тест
12м41с
12м25с
12м45с
Други тест
12м35с
12м45с
12м14с
Трећи тест
12м43с
12м25с
12м5с
У режиму инкременталног прављења резервних копија, морао сам да напустим тар јер резервне копије нису направљене са овим подешавањима.
Резултати креирања инкременталних резервних копија помоћу рсинц-а су:
Први почетак
Друго лансирање
Треће лансирање
Први тест
11м55с
11м50с
12м25с
Други тест
2м42с
2м50с
2м30с
Трећи тест
6м00с
5м35с
5м30с
Генерално, рсинц има малу предност у брзини, рсинц такође ради економичније са мрежом. Ово се може делимично надокнадити мањом употребом ЦПУ-а са тар као резервним програмом. Још једна предност рсинц-а је то што ради са инкременталним копијама. Величина спремишта при креирању пуних резервних копија је иста, 16 ГБ, у случају инкременталних копија - 14 ГБ по покретању, што значи радну дедупликацију.
АМАНДА рецензија
На захтев учесника
Резултати пробног рада са тар као архиватором и омогућеним компресијом су следећи:
Први почетак
Друго лансирање
Треће лансирање
Први тест
9м5с
8м59с
9м6с
Други тест
0м5с
0м5с
0м5с
Трећи тест
2м40с
2м47с
2м45с
Програм у потпуности учитава једно језгро процесора, али због ограниченог ИОПС диска на страни сервера за складиштење резервних копија не може постићи велике брзине преноса података. Генерално, подешавање је било мало проблематичније него за друге учеснике, јер аутор програма не користи ссх као транспорт, већ имплементира сличну шему са кључевима, креирајући и одржавајући пуноправни ЦА. Могуће је широко ограничити клијента и резервног сервера: на пример, ако не могу у потпуности веровати једни другима, онда можете, као опцију, спречити сервер да започне враћање резервне копије тако што ћете поставити вредност одговарајуће променљиве на нулу у датотеку за подешавања. Могуће је повезати веб интерфејс за управљање, али генерално конфигурисани систем може бити потпуно аутоматизован коришћењем малих басх скрипти (или СЦМ, на пример ансибле). Постоји помало нетривијалан систем за подешавање складишта, што је очигледно због подршке за широку листу разних уређаја за складиштење података (ЛТО касете, чврсти дискови, итд.). Такође је вредно напоменути да је од свих програма о којима се говори у овом чланку, АМАНДА једини који је успео да открије преименовање директоријума. Величина спремишта за једно покретање била је 13 ГБ.
Најава
Резервна копија, део 6: Поређење алата за прављење резервних копија
Резервни део 7: Закључци
Извор: ввв.хабр.цом