Ова напомена говори о алатима за прављење резервних копија који врше прављење резервних копија креирањем архива на серверу у стању приправности.
Од оних који испуњавају услове - дупличност (која има леп интерфејс у виду деја дупа) и дупликати.
Још један веома изванредан алат за прављење резервних копија је дар, али пошто има веома широку листу опција – методологија тестирања покрива једва 10% онога за шта је способна – не тестирамо је у оквиру тренутног циклуса.
Очекивани резултати
Пошто оба кандидата на овај или онај начин креирају архиве, обичан тар се може користити као водич.
Поред тога, хајде да проценимо колико је добро складиштење података на серверу за складиштење оптимизовано креирањем резервних копија које садрже само разлику између пуне копије и тренутног стања датотека, или између прошлих и тренутних архива (инкременталне, декременталне, итд.).
Понашање приликом прављења резервних копија:
- Релативно мали број датотека на серверу за складиштење резервних копија (упоредиво са бројем резервних копија или величином података у ГБ), али је њихова величина прилично велика (десетине до стотине мегабајта).
- Величина спремишта ће укључивати само промене - неће се чувати дупликати, тако да ће величина спремишта бити мања него када се покреће софтвер заснован на рсинц-у.
- Очекује се велика употреба ЦПУ-а када се користи компресија и/или шифровање, и вероватно прилично велико оптерећење на мрежи и подсистему диска ако се процес архивирања и/или шифровања покреће на серверу за складиштење резервних копија.
Као референтну вредност, покрените следећу команду:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Резултати извршења су следећи:
Трајање 3м12с. Види се да је брзина почивала на дисковном подсистему сервера за чување резервних копија, као у примеру са . Само мало брже, јер. снимак иде у једну датотеку.
Такође, да бисмо проценили компресију, покренимо исту опцију, али омогућимо компресију на страни резервног сервера:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Резултати су:
Рунтиме 10м11с. Највероватније, уско грло је компресор са једним навојем на пријемној страни.
Иста команда, али са преносом компресије на сервер са почетним подацима за тестирање хипотезе да је уско грло једнонитни компресор.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Испало је овако:
Време извршења је било 9м37с. Јасно се види оптерећење једног језгра компресором, јер. брзина мрежног преноса и оптерећење на подсистему изворног диска су слични.
Да бисте проценили шифровање, можете користити опенссл или гпг, укључујући додатну команду openssl или gpg у цеви. За референцу, постојаће таква команда:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Резултати су изашли овако:
Испоставило се да је време извршења 10м30с, пошто 2 процеса покрећу на пријемној страни - уско грло је опет једнонитни компресор, плус мали додатни трошкови за шифровање.
УПД: На захтев близнезза, додајем тестове са пигзом. Ако користите само компресор - испоставило се за 6м30с, ако додате и шифровање - око 7м. Пад у доњем графикону је неиспрани кеш диск:
испитивање дупличности
Дуплицити је Питхон софтвер за прављење резервних копија за креирање шифрованих тар архива.
За инкременталне архиве се користи либрсинц, тако да можете очекивати понашање описано у .
Резервне копије могу бити шифроване и потписане помоћу гнупг-а, што је важно када се користе различити провајдери за чување резервних копија (с3, бацкблазе, гдриве, итд.)
Да видимо какви ће бити резултати:
Ово су резултати добијени када се ради без шифровања
спојлер
Трајање сваког пробног рада:
Покрени 1
Покрени 2
Покрени 3
16м33с
17м20с
16м30с
8м29с
9м3с
8м45с
5м21с
6м04с
5м53с
А ево резултата када је омогућено гнупг шифровање, са величином кључа од 2048 бита:
Време рада на истим подацима, са шифровањем:
Покрени 1
Покрени 2
Покрени 3
17м22с
17м32с
17м28с
8м52с
9м13с
9м3с
5м48с
5м40с
5м30с
Означена је величина блока - 512 мегабајта, што је јасно видљиво на графиконима; Искоришћеност ЦПУ-а је заправо задржана на 50%, што значи да програм не користи више од једног језгра процесора.
Принцип рада програма је такође прилично јасно видљив: узели су део података, протресли га, послали на резервни сервер за складиштење, што може бити прилично споро.
Друга карактеристика је предвидљиво време рада програма, које зависи само од величине промењених података.
Омогућавање шифровања није значајно повећало време рада програма, али је повећало оптерећење процесора за око 10%, што може бити веома леп бонус.
Нажалост, овај програм није успео да исправно открије ситуацију са преименовањем директоријума, а резултирајућа величина спремишта се показала као једнака величини промена (тј. свих 18 ГБ), али могућност коришћења непоузданог сервера за сигурносна копија јасно превазилази ово понашање.
дуплицати тестинг
Овај софтвер је написан у Ц# и ради помоћу скупа библиотека из Моно-а. Постоји ГУИ, као и Цли верзија.
Груба листа главних карактеристика је близу дупличности, укључујући различите добављаче резервних копија, међутим, за разлику од дупличности, већина функција је доступна без алата треће стране. Да ли је ово плус или минус зависи од конкретног случаја, међутим, за почетнике је највероватније лакше имати списак свих функција одједном пред очима него да инсталирате додатне пакете за Питхон, као што је случај са дволичношћу.
Још једна мала нијанса је да програм активно уписује локалну склите базу података у име корисника који покреће резервну копију, тако да је потребно додатно пратити тачну индикацију жељене базе података сваки пут када покренете процес користећи цли. Када радите кроз ГУИ или ВЕБГУИ, детаљи ће бити скривени од корисника.
Да видимо које показатеље ово решење може дати:
Ако искључите шифровање (а ВЕБГУИ не препоручује да то радите), резултати су следећи:
Радно време:
Покрени 1
Покрени 2
Покрени 3
20м43с
20м13с
20м28с
5м21с
5м40с
5м35с
7м36с
7м54с
7м49с
Када је шифровање омогућено, користећи аес, то изгледа овако:
Радно време:
Покрени 1
Покрени 2
Покрени 3
29м9с
30м1с
29м54с
5м29с
6м2с
5м54с
8м44с
9м12с
9м1с
А ако користите спољни програм гнупг, добићете следеће резултате:
Покрени 1
Покрени 2
Покрени 3
26м6с
26м35с
26м17с
5м20с
5м48с
5м40с
8м12с
8м42с
8м15с
Као што видите, програм може да ради у неколико нити, али то га не чини продуктивнијим решењем, а ако упоредимо рад шифровања, покретање екстерног програма
испоставило се да је брже од коришћења библиотеке из Моно скупа. Можда је то због чињенице да је екстерни програм више оптимизован.
Пријатан тренутак је била и чињеница да величина спремишта заузима тачно онолико колико су стварни подаци промењени, тј. дуплицати је открио преименовање директоријума и исправно решио ситуацију. Ово се може видети када се покрене други тест.
Генерално, прилично позитиван утисак о програму, укључујући довољно љубазности према почетницима.
Налази
Оба кандидата су радила прилично споро, али генерално, у поређењу са уобичајеним катраном, има помака, бар за дупликате. Јасна је и цена таквог напретка – приметан терет
процесор. Генерално, нема посебних одступања у предвиђању резултата.
Налази
Ако нема потребе никуда журити, а постоји и маргина за процесор, било које од разматраних решења ће учинити, у сваком случају, доста посла је урађено, што не треба понављати писањем омотача преко тар. Присуство енкрипције је веома неопходно својство ако се серверу за чување резервних копија не може у потпуности веровати.
У поређењу са решењима заснованим на - перформансе могу бити неколико пута лошије, упркос чињеници да је у свом чистом облику тар радио 20-30% брже од рсинц-а.
Постоји уштеда на величини спремишта, али само за дупликате.
Најава
Бацкуп Део 3: Преглед и тестирање дупликата, дупликати, деја дуп
Бацкуп Део 4: Прегледање и тестирање збацкуп, рестиц, боргбацкуп
Бацкуп Део 5: Тестирање бацула и вееам резервне копије за линук
Резервна копија, део 6: Поређење алата за прављење резервних копија
Резервни део 7: Закључци
Аутор поста: Павел Демковицх
Извор: ввв.хабр.цом