В тази бележка се разглеждат средства за архивиране, които извършват резервно копиране чрез създаване на архиви на резервен сървър.
От тези, които отговарят на изискванията, са duplicity (към който има удобен интерфейс под формата на deja dup) и duplicati.
Още едно доста забележително средство за архивиране е dar, но тъй като има доста обширен списък от опции — методът на тестване покрива едва 10% от това, на което е способен — не го тестваме в рамките на текущия цикъл.
Очаквани резултати
Тъй като и двата кандидата така или иначе създават архиви, ориентиранието може да бъде обикновеният tar.
Допълнително ще оценим колко добре се оптимизира съхранението на данни на сървъра за съхранение чрез създаване на резервни копия, съдържащи само разликата между пълно копие и текущото състояние на файловете, или между предишни и текущи архиви (инкрементални, декрементални и т.н.).
Поведение при създаване на резервни копия:
- Сравнително малко на брой файлове на сървъра за съхранение на резервни копия (сравнимо с броя на резервните копия или размера на данните в GB), но с достатъчно голям размер (десетки до стотици мегабайти).
- Размерът на репозитория ще включва само промените — дубликатите няма да се съхраняват, така че размерът на репозитория ще бъде по-малък в сравнение с работата на софтуера на базата на rsync.
- Очаква се голямо натоварване на процесора при използване на компресия и/или криптиране, както и вероятно достатъчно голямо натоварване на мрежата и дисковата подсистема, ако процесът на архивиране и/или криптиране работи на сървъра за съхранение на резервни копия.
Като еталонна стойност ще стартираме следната команда:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"Резултатите от изпълнението са следните:
Времето за изпълнение е 3m12s. Ясно е, че скоростта е уплътнена от дисковата подсистема на сървъра за съхранение на резервни копия, както и в примера с . Само малко по-бързо, тъй като записът става в един файл.
Също така, за оценка на компресията, ще стартираме същия вариант, но ще включим компресия на страната на сървъра за резервно копие:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"Резултатите са такива:
Времето за изпълнение е 10m11s. Вероятно, тясното място е еднопоточният компресор на входящата страна.
Същият екип, но с преминаване на компресията на сървъра с изходните данни, за да се провери хипотезата, че тясното място е однопоточният компресор.
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"Получиха се така:
Времето за изпълнение беше 9m37s. Ясно се вижда натоварването на едното ядро от компресора, тъй като скоростта на предаване по мрежата и натоварването на дисковата подсистема на источника са сходни.
За оценка на криптирането можете да използвате openssl или gpg, добавяйки допълнителна команда openssl или gpg в pipe. За ориентир ще бъде такава команда:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Резултатите излязоха такива:
Времето за изпълнение се оказа 10m30s, тъй като бяха стартирани 2 процеса на приемащата страна – отново тясното място е однопоточният компресор, плюс малки разходи за криптиране.
UPD: По молба на bliznezz добавям тестовете с pigz. Ако се използва само компресор – получи се за 6m30s, а ако добавим и криптиране – около 7m. Провалът на долната графика – неосвободен дисков кеш:
Тестване на duplicity
Duplicity е софтуер на python за резервно копиране, чрез създаване на криптирани архиви във формат tar.
За инкрементални архиви се прилага librsync, следователно, можем да очакваме поведение, описано в .
Резервните копия могат да бъдат криптирани и подписвани с помощта на gnupg, което е важно при използването на различни доставчици за съхранение на резервни копия (s3, backblaze, gdrive и т.н.)
Нека видим какви ще бъдат резултатите:
Така изглеждат резултатите при стартиране без криптиране
спойлер
Време на работа на всеки тестов стартиращ процес:
Стартиране 1
Стартиране 2
Стартиране 3
16m33s
17m20s
16м30с
8m29s
9м3с
8m45s
5m21s
6m04s
5m53s
А ето резултатите при включено криптиране gnupg, с ключ размер 2048 бита:
Времето на работа с одни и същи данни, с криптиране:
Стартиране 1
Стартиране 2
Стартиране 3
17m22s
17m32s
17m28s
8m52s
9m13s
9м3с
5m48s
3m33s
5m30s
Беше указан размерът на блока – 512 мегабайта, което ясно се вижда на графиките; натоварването на процесора фактически се задържа на ниво 50%, така че програмата използва не повече от едно процесорно ядро.
Също така, доста добре се вижда принципът на работа на програмата: взеха се парче данни, компресираха го, изпратиха го на сървъра за съхранение на резервни копия, който може да бъде доста бавен.
Още една особеност – предсказуемото време на работа на програмата, което зависи само от размера на променените данни.
Включването на криптиране не увеличи особено времето за работа на програмата, но увеличи натоварването на процесора с около 10%, което може да се счита за доста приятен бонус.
За съжаление, тази програма не успя коректно да открие ситуацията с прекръстването на директорията, и полученият размер на репозиторията се оказа равен на размера на промените (т.е. всички 18гб), но възможността за използване на неподписан сървър за архивиране однозначно компенсира такова поведение.
Тестване на duplicati
Този софтуер е написан на C# и се стартира, използвайки библиотеките на Mono. Има GUI, както и CLI версия.
Примерният списък с основни функции е близък до duplicity, включително различни доставчици за съхранение на резервни копия, но, за разлика от duplicity, повечето функции са достъпни без допълнителни средства. Дали това е плюс или минус — зависи от конкретния случай, но за новаците вероятно е по-лесно да имат пред себе си списък с всички функции, отколкото да инсталират пакети за python, както е в случая с duplicity.
Още един малък нюанс — програмата активно записва локална база sqlite от името на потребителя, който стартира архивирането, затова е нужно допълнително внимание при задаването на правилната база всеки път при стартиране на процеса с CLI. При работа чрез GUI или WEBGUI детайлите ще бъдат скрити от потребителя.
Нека видим какви показатели може да предостави това решение:
Ако изключим криптирането (което WEBGUI не препоръчва), резултатите са следните:
Време на работа:
Стартиране 1
Стартиране 2
Стартиране 3
20м43с
20м13с
20м28с
5m21s
3m33s
5m35s
7м36с
7м54с
7м49с
С включено криптиране, използвайки aes, получаваме следните резултати:
Време на работа:
Стартиране 1
Стартиране 2
Стартиране 3
29м9с
30м1с
29м54с
5м29с
6м2с
5м54с
8м44с
9м12с
9м1с
Ако се използва външна програма gnupg, резултатите са следните:
Стартиране 1
Стартиране 2
Стартиране 3
26м6с
26м35с
26м17с
5м20с
5m48s
3m33s
8м12с
8м42с
8м15с
Както се вижда — програмата може да работи в няколко потока, но от това не става по-производителна, а при сравняване на работата на криптиране — стартирането на външна програма
беше по-бързо от използването на библиотеката от комплекта Mono. Вероятно това се дължи на факта, че външната програма е по-добре оптимизирана.
Приятен е фактът, че размерът на репозитория заема точно толкова, колкото реално бяха променените данни, т.е. duplicati откри преименуването на директорията и коректно обработи тази ситуация. Това може да се види при изпълнението на втория тест.
Като цяло, впечатленията от програмата са достатъчно положителни, включително достатъчна дружелюбност към новаците.
Резултати
И двамата кандидати работиха сравнително бавно, но в сравнение с обикновения tar, има напредък, поне при duplicati. Цената на този напредък също е ясна — значителна натовареност
на процесора. Като цяло, няма особени отклонения в прогнозиране на резултатите.
Изводи
Ако не е необходимо да бързате, и също така имате резерв по процесора — подхожда всяко от разгледаните решения, във всеки случай е извършена достатъчно голяма работа, която не трябва да се повтаря чрез написването на обвиващи скриптове над tar. Наличието на криптиране е изключително необходимо свойство, ако сървърът за съхранение на резервни копия няма как да бъде напълно доверен.
Ако сравняваме с решения, основани на — производителността може да бъде няколко пъти по-лоша, въпреки че чистият tar работи по-бързо от rsync с 20-30%.
Има икономия на размера на репозитория, но само при duplicati.
Анонс
Резервно копиране, част 3: Преглед и тестване на duplicity, duplicati, deja dup
Резервно копие, част 4: Преглед и тестване на zbackup, restic, borgbackup
Резервно копиране, част 5: Тестване на bacula и veeam backup for linux
Резервно копиране, част 6: Сравнение на инструменти за резервно копиране
Резервно копиране, част 7: Изводи
Автор на публикацията: Павел Демкович
Източник: habr.com
