Тази статия ще обсъди софтуерни инструменти за архивиране, които чрез разделяне на потока от данни на отделни компоненти (частове) образуват хранилище.
Компонентите на хранилището могат да бъдат допълнително компресирани и криптирани и най-важното е, че по време на повтарящи се процеси на архивиране те могат да бъдат използвани повторно.
Резервно копие в такова хранилище е наречена верига от компоненти, свързани помежду си, например въз основа на различни хеш функции.
Има няколко подобни решения, аз ще се спра на 3: zbackup, borgbackup и restic.
Очаквани резултати
Тъй като всички кандидати изискват създаването на хранилище по един или друг начин, един от най-важните фактори ще бъде размерът на хранилището. В идеалния случай неговият размер трябва да бъде не повече от 13 GB според приетата методика или дори по-малко - при добра оптимизация.
Също така е много желателно да можете да архивирате файлове директно, без да използвате архиватори като tar, както и да работите с ssh / sftp без допълнителни инструменти като rsync и sshfs.
Поведение при създаване на резервни копия:
- Размерът на хранилището ще бъде равен на размера на промените или по-малък.
- Очаква се голямо използване на процесора при използване на компресия и/или криптиране и е вероятно доста тежко натоварване на мрежата и дисковата подсистема, ако процесът на архивиране и/или криптиране се изпълнява на сървъра за архивиране.
- Ако хранилището е повредено, вероятно е забавена грешка както при създаване на нови архиви, така и при опит за възстановяване. Трябва да планирате допълнителни мерки, за да гарантирате целостта на хранилището или да използвате вградените средства за проверка на целостта.
Работата с tar се приема като референтна стойност, както беше показано в една от предишните статии.
Тестване на zbackup
Общият механизъм на работа zbackup е, че програмата намира области, съдържащи същите данни във входния поток от данни, след което по избор ги компресира и криптира, като записва всяка област само 1 път.
За дедупликация се използва 64-битова хеш пръстенна функция за плъзгащ се прозорец, за да се провери байт по байт за съвпадение спрямо вече съществуващи блокове данни (подобно на начина, по който се прилага в rsync).
За компресиране се използват lzma и lzo при многонишково изпълнение, а за криптиране се използва aes. В най-новите версии е възможно в бъдеще да изтриете стари данни от хранилището.
Програмата е написана на C++ с минимални зависимости. Авторът очевидно е бил вдъхновен от unix-way, така че програмата получава данни на stdin при създаване на резервни копия, издавайки подобен поток от данни на stdout при възстановяване. По този начин zbackup може да се използва като много добра "тухла", когато пишете свои собствени решения за архивиране. Например, за автора на статията тази програма е основният инструмент за архивиране на домашни машини от около 2014 г.
Нормалният tar ще се използва като поток от данни, освен ако не е отбелязано друго.
Да видим какви ще са резултатите:
Работата е проверена в 2 версии:
- създава се хранилище и zbackup се изпълнява на сървъра с оригиналните данни, след което съдържанието на хранилището се прехвърля към сървъра за съхранение на резервни копия.
- създава се хранилище на сървъра за съхранение на резервни копия, zbackup се стартира чрез ssh на сървъра за съхранение на резервни копия, данните му се подават през канала.
Резултатите от първия вариант бяха следните: 43m11s - при използване на некриптирано хранилище и компресор lzma, 19m13s - при смяна на компресора с lzo.
Натоварването на сървъра с първоначалните данни беше както следва (показан е пример с lzma, с lzo беше приблизително същата картина, но делът на rsync беше около една четвърт от времето):
Ясно е, че такъв процес на архивиране е подходящ само за сравнително редки и малки промени. Също така е много желателно да ограничите работата на zbackup до 1 нишка, в противен случай ще има много голямо натоварване на процесора, т.к. Програмата може много добре да работи в множество нишки. Натоварването на диска беше малко, което като цяло с модерна дискова подсистема, базирана на ssd, няма да се забележи. Можете също така ясно да видите началото на процеса на синхронизиране на данните от хранилището към отдалечен сървър, скоростта на работа е сравнима с обичайния rsync и зависи от производителността на дисковата подсистема на сървъра за резервно съхранение. Недостатъкът на подхода е съхранението на локално хранилище и в резултат на това дублиране на данни.
По-интересен и приложим на практика е вторият вариант с стартиране на zbackup веднага на резервния сървър за съхранение.
Като начало работата ще бъде проверена без използване на криптиране с компресора lzma:
Продължителност на всяко тестово изпълнение:
Стартиране 1
Стартиране 2
Стартиране 3
39m45s
40m20s
40m3s
7m36s
8m3s
7m48s
15m35s
15m48s
15m38s
Ако активирате криптиране с помощта на aes, резултатите са доста близки:
Време за работа със същите данни, с криптиране:
Стартиране 1
Стартиране 2
Стартиране 3
43m40s
44m12s
44m3s
8m3s
8m15s
8m12s
15m0s
15m40s
15m25s
Ако криптирането се комбинира с компресия на lzo, се оказва така:
Работно време:
Стартиране 1
Стартиране 2
Стартиране 3
18m2s
18m15s
18m12s
5m13s
5m24s
5m20s
8m48s
9m3s
8m51s
Размерът на полученото хранилище беше относително същият при 13 GB. Това означава, че дедупликацията работи правилно. Също така, върху вече компресирани данни, използването на lzo дава осезаем ефект, по отношение на общото време на работа, zbackup е много близо до duplicity / duplicati, но изостава от тези, базирани на librsync с 2-5 пъти.
Ползите са очевидни - спестяване на дисково пространство на резервния сървър за съхранение. Що се отнася до инструментите за проверка на хранилището, те не се предоставят от автора на zbackup, препоръчва се да се използва устойчив на грешки дисков масив или облачен доставчик.
Като цяло, много добро впечатление, въпреки факта, че проектът стои неподвижен от около 3 години (последната заявка за функция беше преди около година, но без отговор).
borgbackup тестване
Borgbackup е разклонение на тавана, друга система, подобна на zbackup. Написан на python, има списък с функции, подобни на zbackup, но освен това може:
- Монтирайте резервни копия с предпазител
- Проверете съдържанието на хранилището
- Работа в режим клиент-сървър
- Използвайте различни компресори за данни, както и евристично определяне на типа на файла при компресирането му.
- 2 опции за криптиране, aes и blake
- Вграден инструмент за
проверки на ефективността
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Резултатите излязоха така:
CZ-BIG 96.51 MB/s (10 100.00 MB всички нулеви файлове: 10.36 s)
RZ-BIG 57.22 MB/s (10 100.00 MB всички нулеви файлове: 17.48 s)
UZ-BIG 253.63 MB/s (10 100.00 MB всички нулеви файлове: 3.94 s)
DZ-BIG 351.06 MB/s (10 100.00 MB всички нулеви файлове: 2.85 s)
CR-BIG 34.30 MB/s (10 100.00 MB произволни файлове: 29.15 s)
RR-BIG 60.69 MB/s (10 100.00 MB произволни файлове: 16.48 s)
UR-BIG 311.06 MB/s (10 100.00 MB произволни файлове: 3.21 s)
DR-BIG 72.63 MB/s (10 100.00 MB произволни файлове: 13.77 s)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB всички нулеви файлове: 9.21 s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB всички нулеви файлове: 13.13 s)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB всички нулеви файлове: 3.02 s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB всички нулеви файлове: 2.58 s)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB произволни файлове: 26.45 s)
RR-MEDIUM 68.90 MB/s (1000 1.00 MB произволни файлове: 14.51 s)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB произволни файлове: 2.88 s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB произволни файлове: 20.49 s)
CZ-SMALL 11.72 MB/s (10000 10.00 kB всички нулеви файлове: 8.53 s)
RZ-SMALL 32.57 MB/s (10000 10.00 kB всички нулеви файлове: 3.07 s)
UZ-SMALL 19.37 MB/s (10000 10.00 kB всички нулеви файлове: 5.16 s)
DZ-SMALL 33.71 MB/s (10000 10.00 kB всички нулеви файлове: 2.97 s)
CR-SMALL 6.85 MB/s (10000 10.00 kB произволни файлове: 14.60 s)
RR-SMALL 31.27 MB/s (10000 10.00 kB произволни файлове: 3.20 s)
UR-SMALL 12.28 MB/s (10000 10.00 kB произволни файлове: 8.14 s)
DR-SMALL 18.78 MB/s (10000 10.00 kB произволни файлове: 5.32 s)
При тестване ще се използва евристика по време на компресия с дефиницията на типа на файла (автоматична компресия) и резултатите ще бъдат както следва:
Първо, нека проверим работата без криптиране:
Работно време:
Стартиране 1
Стартиране 2
Стартиране 3
4m6s
4m10s
4m5s
56s
58s
54s
1m26s
1m34s
1m30s
Ако активирате упълномощаване на хранилище (режим на удостоверяване), резултатите ще бъдат близки:
Работно време:
Стартиране 1
Стартиране 2
Стартиране 3
4m11s
4m20s
4m12s
1m0s
1m3s
1m2s
1m30s
1m34s
1m31s
При активиране на aes криптиране резултатите не се влошиха много:
Стартиране 1
Стартиране 2
Стартиране 3
4m55s
5m2s
4m58s
1m0s
1m2s
1m0s
1m49s
1m50s
1m50s
И ако промените aes на blake, ситуацията ще се подобри напълно:
Работно време:
Стартиране 1
Стартиране 2
Стартиране 3
4m33s
4m43s
4m40s
59s
1m0s
1m0s
1m38s
1m43s
1m40s
Както в случая на zbackup, размерът на хранилището беше 13 GB и дори малко по-малко, което като цяло се очаква. Бях много доволен от времето за изпълнение, то е сравнимо с решенията, базирани на librsync, предоставяйки много повече възможности. Доволен останах и от възможността да задавам различни параметри чрез променливи на средата, което дава много сериозно предимство при използване на borgbackup в автоматичен режим. Също така бях доволен от натоварването по време на архивиране: съдейки по натоварването на процесора, borgbackup работи в 1 нишка.
Нямаше особени недостатъци при използването му.
restic тестване
Въпреки факта, че restic е сравнително ново решение (първите 2 кандидата са известни от 2013 г. и по-стари), той има доста добри характеристики. Написано на Go.
В сравнение със zbackup, той допълнително дава:
- Проверка на целостта на хранилището (включително проверка на части).
- Огромен списък от поддържани протоколи и доставчици за съхранение на архиви, както и поддръжка за rclone - rsync за облачни решения.
- Сравнение на 2 резервни копия един с друг.
- Монтиране на хранилище с предпазител.
Като цяло списъкът с функции е доста близък до borgbackup, понякога повече, понякога по-малко. От характеристиките - невъзможността за деактивиране на криптирането и следователно архивите винаги ще бъдат криптирани. Нека да видим на практика какво може да се изтръгне от този софтуер:
Резултатите са както следва:
Работно време:
Стартиране 1
Стартиране 2
Стартиране 3
5m25s
5m50s
5m38s
35s
38s
36s
1m54s
2m2s
1m58s
Резултатите също са сравними с базираните на rsync решения и като цяло са много близки до borgbackup, но натоварването на процесора е по-високо (работят множество нишки) и зъб на трион.
Най-вероятно програмата се основава на производителността на дисковата подсистема на сървъра за съхранение, какъвто беше случаят с rsync. Размерът на хранилището беше 13 GB, като zbackup или borgbackup, нямаше очевидни недостатъци при използването на това решение.
резултати
Всъщност всички кандидати получиха подобни резултати, но на различни цени. borgbackup се оказа най-добрият, малко по-бавен - restic, zbackup, вероятно, не трябва да започвате да използвате,
и ако вече се използва, опитайте да го промените на borgbackup или restic.
Данни
Restic изглежда най-обещаващото решение, т.к именно той има най-добро съотношение на възможности към скорост, но засега няма да бързаме с генерални заключения.
Borgbackup не е по-лош принципно, но zbackup вероятно е по-добре да се замени. Въпреки това, правилото 3-2-1 на zbackup все още може да се използва, за да работи. Например, в допълнение към (lib)rsync базирани инструменти за архивиране.
Съобщение
Архивиране, част 5: Тестване на bacula и veeam архивиране за linux
Архивиране, част 6: Сравняване на инструментите за архивиране
Архивиране Част 7: Заключения
Автор на публикацията: Павел Демкович
Източник: www.habr.com