Тази бележка обсъжда инструменти за архивиране, които извършват архивиране чрез създаване на архиви на сървър за архивиране.
Сред тези, които отговарят на изискванията, са 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 в тръба. За справка ще има команда като тази:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"Резултатите излязоха така:
Времето за изпълнение се оказа 10m30s, тъй като 2 процеса се изпълняват от приемащата страна - тясното място отново е компресор с една нишка, плюс малки разходи за криптиране.
UPS: По молба на bliznezz добавям тестове с pigz. Ако използвате само компресора, това ще отнеме 6m30s, ако добавите и криптиране, ще бъде около 7m. Спадът в долната графика е непочистен дисков кеш:
Дублиране на тестване
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 GB), но възможността за използване на ненадежден сървър за архивиране ясно покрива това поведение.
Дублиране на тестване
Този софтуер е написан на C# и работи с помощта на набор от библиотеки от Mono. Има GUI, както и CLI версия.
Приблизителният списък на основните функции е подобен на дублирането, включително различни доставчици на резервно хранилище, но за разлика от дублирането повечето функции са достъпни без инструменти на трети страни. Дали това е плюс или минус зависи от конкретния случай, но за начинаещи най-вероятно е по-лесно да имат списък с всички функции пред себе си наведнъж, вместо да се налага да инсталират допълнителни пакети за python, както е случаят с двуличието.
Друг малък нюанс - програмата активно пише локална база данни 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, има напредък, поне при дубликатите. Цената на такъв напредък също е ясна - осезаемо бреме
процесор. Като цяло няма специални отклонения при прогнозиране на резултатите.
Данни
Ако не е нужно да бързате никъде и също така имате резервен процесор, всяко от разгледаните решения ще свърши работа, във всеки случай е свършена доста работа, която не трябва да се повтаря чрез писане на скриптове за обвивка върху tar . Наличието на криптиране е много необходимо свойство, ако на сървъра за съхранение на резервни копия не може да се вярва напълно.
В сравнение с базираните на решения - производителността може да бъде няколко пъти по-лоша, въпреки факта, че в чистата си форма tar работи с 20-30% по-бързо от rsync.
Има спестявания от размера на хранилището, но само с дубликати.
Съобщение
Архивиране, част 3: Преглед и тестване на дублиране, дублиране, дублиране
Архивиране Част 4: Преглед и тестване на zbackup, restic, borgbackup
Архивиране, част 5: Тестване на bacula и veeam архивиране за linux
Архивиране, част 6: Сравняване на инструментите за архивиране
Архивиране Част 7: Заключения
Автор на публикацията: Павел Демкович
Източник: www.habr.com