В тази статия ще се разгледат програмните средства за резервно копие, които, като разделят потока от данни на отделни компоненти (chunks), формират хранилище.
Компонентите на хранилището могат допълнително да се компресират и криптират, а най-важното — да се повторно използват при повтарящи се процеси на резервно копие.
Резервната копия в подобно хранилище е именувана верига от свързани помежду си компоненти, например, въз основа на различни hash-функции.
Има няколко подобни решения, ще се спра на 3: zbackup, borgbackup и restic.
Очаквани резултати
Тъй като всички кандидати по един или друг начин изискват създаване на хранилище, един от най-важните фактори ще бъде оценка на размера на хранилището. В идеалния случай размерът му не трябва да надвишава 13 ГБ според приетата методика, а даже и по-малко — при добра оптимизация.
Също така, изключително желателно е да има възможност за директно създаване на резервни копия на файлове, без да се използват архиватори като tar, както и работа с ssh/sftp без допълнителни средства като rsync и sshfs.
Поведение при създаване на резервни копия:
- Размерът на хранилището ще бъде равен на размера на промените или по-малък.
- Очаква се голямо натоварване на процесора при използване на компресия и/или криптиране, както и вероятно значително натоварване на мрежата и дисковата подсистема, ако процесът на архивиране и/или криптиране работи на сървъра за съхранение на резервни копия.
- Ако хранилището бъде повредено — вероятна е отложена грешка както при създаването на нови резервни копия, така и при опити за възстановяване. Трябва да се планират допълнителни мерки за осигуряване на целостта на хранилището или да се използват вградени средства за проверка на неговата целостност.
Като еталонна стойност е приета работа с tar, както беше показано в една от предишните статии.
Тестване на zbackup
Общият механизъм на работа на zbackup се състои в това, че програмата открива в потока от данни, подаван на входа, области, съдържащи еднакви данни, след което опционално ги компресира, криптира, запазвайки всяка област само 1 път.
За дедупликация се използва 64-битна пръстенна hash-функция със скользящо прозорче за побайтово сравнение с вече съществуващи блокове данни (подобно на това, което е реализирано в rsync).
За компресия се използват lzma и lzo в многопоточен режим, а за криптиране — aes. В последните версии има възможност в бъдеще да се изтриват стари данни от хранилището.
Програмата е написана на C++ с минимални зависимости. Авторът явно е вдъхновен от unix-way, затова програмата приема данни от stdin при създаване на резервни копия, предоставяйки аналогичен поток данни в stdout при възстановяване. По този начин zbackup може да се използва като доста добър «кирпичик» при написването на собствени решения за резервно копиране. Например, за автора на статията тази програма е основното средство за резервно копиране на домашни машини от около 2014 година.
Като поток данни ще се използва обикновен tar, освен ако не е посочено друго.
Нека видим какви ще бъдат резултатите:
Тестовете бяха проведени в 2 варианта:
- създава се хранилище и се стартира zbackup на сървър с изходни данни, след което съдържанието на хранилището се предава на сървъра за съхранение на резервни копия.
- създава се хранилище на сървъра за съхранение на резервни копия, zbackup се стартира чрез ssh на сървъра за съхранение на резервни копия и данните му се предават през pipe.
Резултатите от първия вариант бяха следните: 43m11s — при използване на нешифровано хранилище и компресор lzma, 19m13s — при замяна на компресора с lzo.
Натоварването на сървъра с изходни данни беше следното (показан е пример с lzma, с lzo картината беше подобна, но делът на rsync беше приблизително една четвърт от времето):
Ясно е, че такъв процес за резервно копиране е подходящ само при относително редки и незначителни промени. Също така е изключително желателно да се ограничи работата на zbackup до 1 поток, иначе ще има много висока натовареност на процесора, тъй като програмата много добре може да работи в повече от един поток. Натоварването на диска беше малко, което в цялост при съвременна дискова подсистема на базата на ssd няма да се забележи. Също така, ясно се вижда стартирането на процеса на синхронизация на данните в хранилището на отдалечения сървър, скоростта на работа е сравнима с обикновения rsync и се упира в производителността на дисковата подсистема на сървъра за съхранение на резервни копия. Недостатък на подхода е съхранението на локално хранилище и, следователно, — дублирането на данните.
По-интересен и практически приложим е вторият вариант с извикване на zbackup директно на сървъра за съхранение на резервни копия.
Първо ще се провери работата без използване на криптиране с компресора lzma:
Време на работа на всеки тестов стартиращ процес:
Стартиране 1
Стартиране 2
Стартиране 3
39м45с
40м20с
40м3с
7м36с
8м3с
7м48с
15м35с
15м48с
15м38с
При активиране на криптиране с aes, резултатите са сравнително близки:
Времето на работа с одни и същи данни, с криптиране:
Стартиране 1
Стартиране 2
Стартиране 3
43м40с
44м12с
44м3с
8м3с
8м15с
8м12с
15м0с
15м40с
15м25с
При съчетаване на криптиране с компресия с lzo, се получават следните резултати:
Време на работа:
Стартиране 1
Стартиране 2
Стартиране 3
18м2с
18м15с
18м12с
5м13с
5м24с
5м20с
8м48с
9м3с
8м51с
Размерът на резултиращия репозиторий беше сравнително единен и възлиза на 13ГБ. Това означава, че дедупликацията работи коректно. Освен това, при вече компресирани данни, приложението на lzo дава осезаем ефект, общото време за работа на zbackup се доближава до duplicity/duplicati, но остава зад основаните на librsync от 2 до 5 пъти.
Очевидните предимства са — спестяване на дисково пространство на сървъра за съхранение на резервни копия. Що се отнася до инструментите за проверка на репозитория — те не са предвидени от автора на zbackup и се препоръчва да се използва отказоустойчив масив от дискове или облачен доставчик.
Като цяло, впечатлението е доста добро, въпреки че проектът остава без развитие вече около 3 години (последната заявка за функция е била преди около година, но без отговор).
Тестване на borgbackup
Borgbackup е форк на attic, още една система, подобна на zbackup. Написан е на python, има подобен на zbackup списък от възможности, но допълнително предлага:
- Монтиране на резервни копия чрез fuse
- Проверка на съдържанието на репозитория
- Работа в режим клиент-сървър
- Използване на различни компресори за данни, както и херистично определяне на типа файл при компресия.
- 2 варианта на криптиране, aes и blake
- Вградено средство за
проверка на производителността
borgbackup benchmark crud ssh://backup_server/repo/path local_dir
Резултатите са следните:
C-Z-BIG 96.51 MB/s (10 100.00 MB all-zero files: 10.36s)
R-Z-BIG 57.22 MB/s (10 100.00 MB all-zero files: 17.48s)
U-Z-BIG 253.63 MB/s (10 100.00 MB all-zero files: 3.94s)
D-Z-BIG 351.06 MB/s (10 100.00 MB all-zero files: 2.85s)
C-R-BIG 34.30 MB/s (10 100.00 MB random files: 29.15s)
R-R-BIG 60.69 MB/s (10 100.00 MB random files: 16.48s)
U-R-BIG 311.06 MB/s (10 100.00 MB random files: 3.21s)
D-R-BIG 72.63 MB/s (10 100.00 MB random files: 13.77s)
C-Z-MEDIUM 108.59 MB/s (1000 1.00 MB all-zero files: 9.21s)
R-Z-MEDIUM 76.16 MB/s (1000 1.00 MB all-zero files: 13.13s)
U-Z-MEDIUM 331.27 MB/s (1000 1.00 MB all-zero files: 3.02s)
D-Z-MEDIUM 387.36 MB/s (1000 1.00 MB all-zero files: 2.58s)
C-R-MEDIUM 37.80 MB/s (1000 1.00 MB random files: 26.45s)
R-R-MEDIUM 68.90 MB/s (1000 1.00 MB random files: 14.51s)
U-R-MEDIUM 347.24 MB/s (1000 1.00 MB random files: 2.88s)
D-R-MEDIUM 48.80 MB/s (1000 1.00 MB random files: 20.49s)
C-Z-SMALL 11.72 MB/s (10000 10.00 kB всички нулеви файлове: 8.53с)
R-Z-SMALL 32.57 MB/s (10000 10.00 kB всички нулеви файлове: 3.07с)
U-Z-SMALL 19.37 MB/s (10000 10.00 kB всички нулеви файлове: 5.16с)
D-Z-SMALL 33.71 MB/s (10000 10.00 kB всички нулеви файлове: 2.97с)
C-R-SMALL 6.85 MB/s (10000 10.00 kB случайни файлове: 14.60с)
R-R-SMALL 31.27 MB/s (10000 10.00 kB случайни файлове: 3.20с)
U-R-SMALL 12.28 MB/s (10000 10.00 kB случайни файлове: 8.14с)
D-R-SMALL 18.78 MB/s (10000 10.00 kB случайни файлове: 5.32с)
При тестването ще се използва хевристика при компресия с определяне на типа файл (compression auto), а резултатите ще бъдат следните:
Първо ще проверим работата без шифроване:
Време на работа:
Стартиране 1
Стартиране 2
Стартиране 3
4м6с
4м10с
4м5с
56с
58с
54с
1м26с
1м34с
1м30с
Ако активираме удостоверяване на хранилището (authenticated режим), резултатите ще бъдат близки:
Време на работа:
Стартиране 1
Стартиране 2
Стартиране 3
4м11с
4м20с
4м12с
1м0с
1м3с
1м2с
1м30с
1м34с
1м31с
При активиране на шифроване aes, резултатите не се влошиха значително:
Стартиране 1
Стартиране 2
Стартиране 3
4м55с
5м2с
4м58с
1м0с
1м2с
1м0с
1м49с
1м50с
1м50с
Ако сменим aes с blake, ситуацията ще се подобри:
Време на работа:
Стартиране 1
Стартиране 2
Стартиране 3
4м33с
4м43с
4м40с
59с
1м0с
1м0с
1м38с
1м43с
1м40с
Както и при zbackup, размерът на хранилището е 13гб и дори малко по-малко, което е в съответствие с очакванията. Времето на работа е много добро, сравнимо с решения на базата на librsync, предоставяйки много по-широки възможности. Също така е приятно, че можем да задаваме различни параметри чрез променливи на средата, което предоставя сериозно предимство при използване на borgbackup в автоматичен режим. Освен това натоварването при резервното копиране е приятно: съдейки по натоварването на процесора, borgbackup работи в един поток.
Не бяха открити съществени недостатъци при използване.
Тестване на restic
Въпреки че restic е сравнително ново решение (първите двама кандидати бяха известни още от 2013 година и по-рано), той показва достатъчно добри характеристики. Написан е на Go.
Ако сравним с zbackup, допълнително предлага:
- Проверка на целостта на хранилището (включително частична проверка).
- Огромен списък от поддържани протоколи и доставчици за резервно копиране, както и поддръжка на rclone — rsync за „облачни“ решения.
- Сравнение на 2 резервни копия помежду си.
- Монтиране на хранилището чрез fuse.
В общи линии списъкът с възможности е доста близък до borgbackup, в някои отношения повече, в други по-малко. От особеностите — липсата на възможност за изключване на шифроване, следователно резервните копия ще бъдат винаги шифровани. Нека видим на практика какво можем да изцедим от този софтуер:
Резултатите бяха следните:
Време на работа:
Стартиране 1
Стартиране 2
Стартиране 3
5м25с
5м50с
5м38с
35с
38с
36с
1м54с
2м2с
1м58с
Резултатите от работата също така са сравними с решенията на основата на rsync и, като цяло, са доста близки до borgbackup, но натоварването на процесора е по-високо (работи в няколко потока) и е пилообразно.
Скорее всего, програмата опира на производителността на дисковата подсистема на сървъра за съхранение на данни, както се случи и с rsync. Размерът на хранилището е 13 ГБ, както при zbackup или borgbackup, явни недостатъци при използването на това решение не бяха открити.
Резултати
Всъщност при всички кандидати показателите са близки, но цените са различни. Най-добре се представи borgbackup, малко по-бавен е restic, а zbackup вероятно не си заслужава да се започва да се използва.
А ако вече е използван — да се опита да се смени с borgbackup или restic.
Изводи
Най-перспективното решение изглежда да е restic, тъй като той разполага с най-доброто съотношение между възможности и скорост на работа, но засега няма да бързаме с окончателните изводи.
Borgbackup по принцип не е по-лош, а zbackup вероятно трябва да бъде заменен. Обаче, за осигуряване на работата по правилото 3-2-1, zbackup все още може да се използва. Например, в допълнение към средствата за архивиране на основата на (lib)rsync.
Анонс
Резервно копиране, част 5: Тестване на bacula и veeam backup for linux
Резервно копиране, част 6: Сравнение на инструменти за резервно копиране
Резервно копиране, част 7: Изводи
Автор на публикацията: Павел Демкович
Източник: habr.com
