🥇Резервно копие, част 4: Преглед и тестване на zbackup, restic, borgbackup

В тази статия ще се разгледат софтуерни средства за резервно копиране, които разделят потока от данни на отделни компоненти (chunks) и формират репозитория.

Компонентите на репозитория могат допълнително да бъдат компресирани и криптирани, а най-важното е, че при повторни процеси на резервно копиране — да се реизползват.

Резервната копия в подобен репозиторий е именувана верига от свързани компоненти помежду си, например, на основата на различни hash-функции.

Има няколко подобни решения, ще се спра на 3: zbackup, borgbackup и restic.

Очаквани резултати

Тъй като всички кандидати по един или друг начин изискват създаването на репозитория, един от най-важните фактори ще бъде оценката на размера на репозитория. В идеалния случай размерът му не трябва да надвишава 13 гб съгласно приетата методика, а дори и по-малко — при условие за добра оптимизация.

Също така е крайно желателно да имате възможност за създаване на резервни копия на файлове директно, без да се използват архиватори като tar, а също така да работите с ssh/sftp без допълнителни средства като rsync и sshfs.

Поведение при създаване на резервни копия:

Размерът на репозитория ще бъде равен на размера на промените или по-малко.
Очаква се висока натовареност на процесора при използване на компресия и/или криптиране, както и вероятна доста голяма натовареност на мрежата и дисковата подсистема, ако процесът на архивиране и/или криптиране работи на сървър за съхранение на резервни копия.
Ако репозитория бъде повреден — вероятна е отложена грешка както при създаване на нови резервни копия, така и при опит за възстановяване. Трябва да се планират допълнителни мерки за осигуряване на целостта на репозитория или да се използват вградени средства за проверка на неговата целост.

Като еталонна стойност е приета работата с tar, както бе показано в една от предишните статии.

Тестване на zbackup

Основният механизъм на работа на zbackup е, че програмата намира в потока от данни, подаван на входа, области, съдържащи еднакви данни, след което опционално ги компресира, криптира, запазвайки всяка област само 1 път.

За дедупликацията се използва 64-битна кръгова hash-функция с плъзгащ се прозорец за побайтово проверяване на съвпадения с вече съществуващи блокове данни (подобно на това, което е реализирано в rsync).

За компресия се използват lzma и lzo в многопоточен режим, а за криптиране — aes. В последните версии има възможност в бъдеще да се изтриват стари данни от репозитория.
Програмата е написана на C++ с минимални зависимости. Авторът очевидно е вдъхновен от подхода на unix, затова програмата приема данни от stdin при създаване на резервни копия, предоставяйки подобен поток данни в stdout при възстановяване. Така zbackup може да се използва като отличен "кирпичик" при разработването на собствени решения за резервно копиране. Например, за автора на статията тази програма е основното средство за резервно копиране на домашни машини от около 2014 година.

Като поток данни ще се използва обикновен tar, освен ако не е указано друго.

Нека видим какви ще са резултатите:

Тестовете на работата бяха проведени в 2 варианта:

създава се репозиторий и zbackup се стартира на сървъра с изходни данни, след което съдържанието на репозитория се прехвърля на сървъра за съхранение на резервни копия.
създава се репозиторий на сървъра за съхранение на резервни копия, zbackup се стартира през ssh на сървъра за съхранение, като се предоставят данните чрез pipe.

Резултатите от първия вариант бяха следните: 43m11s — при използване на нешифрован репозиторий и компресор lzma, 19m13s — при смяна на компресора с lzo.

Натоварването на сървъра с изходни данни беше следното (показан е пример с lzma, с lzo беше почти същата картина, но делът на rsync беше около една четвърт от времето):

Очевидно е, че подобен процес на резервно копиране е подходящ само при относително редки и малки изменения. Също така е много желателно да се ограничи работата на zbackup до 1 поток, в противен случай натоварването на процесора ще бъде доста високо, тъй като програмата е много добра в работа с множество потоци. Натоварването на диска беше незначително, което в общи линии при съвременна дискова подсистема на база SSD ще бъде незабележимо. Също така е ясно видимо стартиране на процеса на синхронизация на данните от репозитория на отдалечения сървър, скоростта на работа е сравнима с обикновен rsync и зависи от производителността на дискoвата подсистема на сървъра за съхранение на резервни копия. Недостатък на подхода е съхранението на локален репозиторий и, следователно, дублирането на данните.

По-интересен и приложим на практика е вторият вариант с стартиране на zbackup директно на сървъра за съхранение на резервни копия.

Първо ще бъде проверена работата без използване на криптиране с компресор lzma:

Времето на работа на всяко тестово стартиране:

Стартиране 1
Стартиране 2
Стартиране 3

39м45с
40м20с
40m3s

7m36s
8м3с
7м48с

15м35с
15м48с
15м38с

Ако активирате криптиране с aes, резултатите са доста близки:

Времето за работа с същите данни, с криптиране:

Стартиране 1
Стартиране 2
Стартиране 3

43м40с
44м12с
44м3с

8м3с
8m15s
8m12s

15м0с
15м40с
15м25с

Ако съчетаете криптирането с компресия на lzo, се получава следното:

Време на работа:

Стартиране 1
Стартиране 2
Стартиране 3

18м2с
18м15с
18м12с

5м13с
5м24с
5m20s

8м48с
9m3s
8м51с

Размерът на полученото хранилище беше относително един и същ и беше 13GB. Това означава, че дедупликацията работи коректно. Също така, при вече компресирани данни, приложението на 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.53s)
R-Z-SMALL 32.57 MB/s (10000 10.00 kB файлови без нули: 3.07s)
U-Z-SMALL 19.37 MB/s (10000 10.00 kB файлови без нули: 5.16s)
D-Z-SMALL 33.71 MB/s (10000 10.00 kB файлови без нули: 2.97s)
C-R-SMALL 6.85 MB/s (10000 10.00 kB произволни файлове: 14.60s)
R-R-SMALL 31.27 MB/s (10000 10.00 kB произволни файлове: 3.20s)
U-R-SMALL 12.28 MB/s (10000 10.00 kB произволни файлове: 8.14s)
D-R-SMALL 18.78 MB/s (10000 10.00 kB произволни файлове: 5.32s)

При тестовете ще се използва хевристика при компресия с определяне на типа на файла (compression auto), а резултатите ще са следните:

Първо проверяваме работата без криптиране:

Време на работа:

Стартиране 1
Стартиране 2
Стартиране 3

4m6s
4m10s
4m5s

56s
58s
54s

1m26s
1m34s
1m30s

Ако активирате авторизацията на репозитория (режим authenticated), резултатите ще бъдат сходни:

Време на работа:

Стартиране 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 работи в един поток.

Не бяха установени особени недостатъци при използването.

Тестване на restic

Въпреки че restic е относително ново решение (първите два кандидата са известни още от 2013 година и по-стари), той притежава доста прилични характеристики. Написан е на Go.

Ако сравняваме с zbackup, допълнително предлага:

Проверка на целостта на репозитория (включително проверка по части).
Огромен списък от поддържани протоколи и доставчици за съхранение на резервни копия, а също и поддръжка на rclone — rsync за 'облачни' решения.
Сравнение на две резервни копия помежду им.
Монтиране на репозитория чрез fuse.

В общи линии списъкът от възможности е доста близък до borgbackup, на места повече, на места по-малко. От особеностите — липсата на възможност за изключване на криптирането, следователно, резервните копия винаги ще бъдат криптирани. Нека видим на практика какво можем да извлечем от този софтуер:

Резултатите са следните:

Време на работа:

Стартиране 1
Стартиране 2
Стартиране 3

5m25s
5m50s
5m38s

35s
38s
36s

1m54s
2m2s
1m58s

Резултатите от работата също са сравними с решенията, базирани на rsync, и като цяло са доста близки до borgbackup, но натоварването на процесора е по-високо (работят няколко потока) и е зигзагообразно.

Най-вероятно програмата попада на производителността на дисковата подсистема на сървъра за съхранение на данни, както вече беше с rsync. Размерът на репозитория е 13GB, точно като при zbackup или borgbackup, не бяха открити явни минуси при използването на това решение.

Резултати

На практика всички кандидати показаха близки показатели, но с различна цена. Най-добре се представи borgbackup, малко по-бавен е restic, докато zbackup вероятно не си струва да бъде използван,
а ако вече се използва — да опитате да преминете на borgbackup или restic.

Изводи

Най-перспективното решение изглежда да е restic, тъй като той притежава най-добро съотношение между възможности и скорост на работа, но все още нека не бързаме с общите заключения.

Borgbackup в принципе не е по-лош, но zbackup вероятно е по-добре да бъде заменен. Въпреки това, за да се осигури работа по правилото 3-2-1, zbackup все още може да бъде използван. Например, в допълнение на резервните средства, базирани на (lib)rsync.