В тази бележка са разгледани средства за бекъп, които извършват резервно копиране чрез създаване на архиви на резервен сървър.
От тези, които отговарят на изискванията, са 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
16m30s
8m29s
9m3s
8m45s
5m21s
6m04s
5m53s
А ето резултатите при включване на криптиране с gnupg, с размер на ключа 2048 бита:
Времето за работа с същите данни, с криптиране:
Стартиране 1
Стартиране 2
Стартиране 3
17m22s
17m32s
17m28s
8m52s
9m13s
9m3s
5m48s
5m40s
5m30s
Беше зададен размер на блока - 512 мегабайта, което е ясно видимо на графиците; натоварването на процесора всъщност се е задържало на ниво 50%, т.е. програмата използва не повече от едно процесорно ядро.
Също така е доста ясно видимо принципът на работа на програмата: взели сме парче данни, компресирали сме го, изпратили сме го на сървъра за съхранение на резервни копия, който може да бъде доста бавен.
Още една особеност е предсказуемото време за работа на програмата, което зависи само от величината на променените данни.
Включването на шифроване не увеличи особено времето на работа на програмата, но повиши натоварването на процесора с около 10%, което може да се окаже доста приятно предимство.
За съжаление, тази програма не успя да открие правилно ситуацията с преименуването на директорията, и резултантният размер на репозитория се оказа равен на размера на промените (т.е. всичките 18 ГБ), но възможността да се използва недоверен сървър за архивиране определено компенсира такова поведение.
Тестване на duplicati
Това софтуерно приложение е написано на C#, стартира се с помощта на комплект библиотеки от Mono. Има GUI, а също така и версия на командния ред (cli).
Приблизителен списък с основните функции е близък до duplicity, включително различни доставчици за съхранение на резервни копия, но за разлика от duplicity, повечето функции са налични без външни средства. Плюс или минус - зависи от конкретния случай, но за начинаещите вероятно е по-лесно да имат пред очите си списък с всички функции, вместо да инсталират пакети за python, както е в случая с duplicity.
Още един малък нюанс - програмата активно записва локална база sqlite от името на потребителя, който стартира архивирането, затова е необходимо допълнително да се следи за правилното указване на необходимата база при всяко стартиране на процеса, използвайки cli. При работа през GUI или WEBGUI детайлите ще бъдат скрити от потребителя.
Нека видим какви показатели може да предостави това решение:
Ако изключите шифроването (като WEBGUI не препоръчва това), резултатите са следните:
Време на работа:
Стартиране 1
Стартиране 2
Стартиране 3
20m43s
20m13s
20m28s
5m21s
5m40s
5m35s
7m36s
7m54s
7m49s
С включено шифроване, използвайки aes, резултатите са:
Време на работа:
Стартиране 1
Стартиране 2
Стартиране 3
29m9s
30m1s
29m54s
5m29s
6m2s
5m54s
8m44s
9m12s
9m1s
А ако се използва външната програма gnupg, получаваме следните резултати:
Стартиране 1
Стартиране 2
Стартиране 3
26m6s
26m35s
26m17s
5m20s
5m48s
5m40s
8m12s
8m42s
8m15s
Както виждате, програмата може да работи в множество потоци, но от това не става по-продуктивно решение, а ако сравняваме работата на шифроването - стартирането на външната програма
се оказа по-бързо от използването на библиотеката от комплекта 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
