В тази статия ще бъде направено сравнение на средствата за резервно копиране, но първо е важно да разберем как те бързо и ефективно се справят с възстановяването на данни от резервни копия.
За улеснение на сравнението ще се разглежда възстановяване от пълна резервна копия, предвид че този режим на работа поддържат всички кандидати. За удобство, числата са взети като средни (аритметична средна от няколко стартирания). Резултатите ще бъдат обобщени в таблица, в която ще има и информация за възможностите: наличие на уеб интерфейс, простота при настройка и работа, способност за автоматизация, наличие на различни допълнителни възможности (например, проверка на целостта на данните) и т.н. Графиките ще показват натоварването на сървъра, където данните ще бъдат прилагани (а не на сървъра за съхранение на резервни копия).
Възстановяване на данни
Като опорна точка ще бъдат използвани rsync и tar, тъй като най-простите скриптове за създаване на резервни копия.
Rsync справи се с тестовия набор от данни за 4 минути и 28 секунди, показвайки
такова натоварване.
Процесът на възстановяване се сблъска с ограниченията на дисковата подсистема на сървъра за съхранение на резервни копия (синусоидни графики). Също така е видно натоварването на ядрото без особени проблеми (ниско iowait и softirq — няма проблеми с диска и мрежата съответно). Тъй като двете други програми, а именно rdiff-backup и rsnapshot, са базирани на rsync и също предлагат обикновен rsync като средство за възстановяване, те ще имат приблизително такъв същия профил на натоварване и време за възстановяване на резервната копия.
Tar се справи малко по-бързо, за
2 минути и 43 секунди:
Общото натоварване на системата беше по-високо средно с 20% поради увеличения softirq — нараснали разходите при работа на мрежовата подсистема.
Ако архивът бъде допълнително компресиран, времето за възстановяване нараства до 3 минути и 19 секунди с
такова натоварване на основния сървър (разархивиране на страната на основния сървър):
Процесът на разархивиране използва и двете процесорни ядра, тъй като работи с два процеса. Като цяло — очакван резултат. Сравним резултат (3 минути и 20 секунди) бе получен и при стартиране на gzip на сървъра с резервни копия; профилът на натоварването на основния сървър беше доста подобен на стартиране на tar без компресора gzip (вж. предишната графика).
В rdiff-backup може да синхронизира последната направена резервна копия с помощта на обикновен rsync (резултатите ще бъдат аналогични), но по-старите резервни копия все пак трябва да се възстановяват с помощта на програмата rdiff-backup, която се справи с възстановяването за 17 минути и 17 секунди, показвайки
такава натовареност:
Възможно е това да е било предвидено, поне що се отнася до ограничаване на скоростта, авторите . Самият процес на възстановяване на резервна копия отнема малко по-малко от половината ядро, с пропорционално сравнима производителност (т.е. 2-5 пъти по-бавно) по диска и мрежата спрямо rsync.
Rsnapshot предлага за възстановяване да се използва обикновен rsync, така че резултатите му ще бъдат аналогични. Като цяло, така и стана.
Burp се справи с възстановяването на резервна копия за 7 минути и 2 секунди с
такава натовареност:
Сработи доста бързо и, поне, значително по-удобно от чистия rsync: не е необходимо да помните флагове, прост и интуитивен cli интерфейс, вградена поддръжка на няколко копия — разбира се, около два пъти по-бавно. Ако данните трябва да се възстановят от последно направената резервна копия — можете да използвате rsync, с малки уговорки.
Приблизително такава скорост и натоварване показа програмата BackupPC при включване на режим на предаване rsync, разгръщайки резервната копия за
7 минути и 42 секунди:
А в режим на предаване на данни с tar, BackupPC се справи по-бавно: за 12 минути и 15 секунди, натоварването на процесора в този случай беше по-ниско
половин и половина:
Duplicity Без криптиране на изпитанията бяха постигнати малко по-добри резултати, справяйки се с възстановяването на резервната копие за 10 минути и 58 секунди. Когато активирате криптиране с помощта на gpg, времето за възстановяване се увеличава до 15 минути и 3 секунди. При създаване на хранилище за копия можете да зададете размер на архива, който ще се използва за разделяне на потока входящи данни. Общо взето, на обикновените твърди дискове, както и във връзка с еднопоточния режим на работа, няма съществена разлика. Тя може да се появи при различни размери на блоковете, когато се използват хибридни хранилища. Натоварването на основния сървър по време на възстановяване беше такова:
без криптиране
с криптиране
Duplicati показва сравнима скорост на възстановяване, справяйки се за 13 минути и 45 секунди. Още около 5 минути отне проверката на коректността на възстановените данни (общо около 19 минути). Натоварването при това беше
достатъчно високо:
Когато криптирането aes беше включено с вътрешни средства, времето за възстановяване беше 21 минути и 40 секунди, като натоварването на процесора беше максимално (и двете ядра!) по време на възстановяване; при проверката на данните беше активен само един поток, използващ едно ядро на процесора. Проверката на данните след възстановяване отне същите 5 минути (общо почти 27 минути).
Резултат
Чуть по-бързо duplicati успя да се справи с възстановяването, използвайки външна програма gpg за криптиране, но като цяло разликите от предишния режим са минимални. Времето на работа беше 16 минути и 30 секунди, с проверка на данните за 6 минути. Натоварването беше
такова:
AMANDA, използваща tar, се справи за 2 минути и 49 секунди, което всъщност е доста близо до обикновен tar. Натоварването на системата всъщност
е същото:
При възстановяване на резервна копие с инструменти zbackup бяха постигнати следните резултати:
криптиране, компресия lzma
Време на работа 11 минути и 8 секунди
криптиране aes, компресия lzma
Време на работа 14 минути
криптиране aes, компресия lzo
Време на работа 6 минути и 19 секунди
Като цяло, не е лошо. Всичко зависи от скоростта на процесора на резервния сървър, което е ясно видимо по времето за работа на програмата с различни компресори. От страна на резервния сървър беше стартиран обикновен tar, така че ако сравним с него – възстановяването работи три пъти по-бавно. Може би си струва да проверим работата в многопоточен режим с повече от два потока.
BorgBackup в режим без криптиране справи се малко по-бавно от tar, за 2 минути и 45 секунди, но за разлика от tar, се появи възможност за дедупликация на репозитория. Натоварването в този случай беше
следното:
Ако активирате криптиране на основата на blake, тогава скоростта на възстановяване на резервната копия леко се забавя. Времето за възстановяване в този режим е 3 минути и 19 секунди, а натоварването е
такова:
Криптирането aes работи малко по-бавно, времето за възстановяване е 3 минути и 23 секунди, а натоварването не
се променя особено:
Понеже Borg може да работи в многопоточен режим – натоварването на процесора е максимално, при активиране на допълнителни функции просто времето за работа расте. Явно е, че е нужно да се проучи многопоточността на работата, аналогично на zbackup.
Restic се справи с възстановяването малко по-бавно, времето за работа беше 4 минути и 28 секунди. Натоварването в този случай изглеждаше
така:
Явно процесът на възстановяване работи в няколко потока, но ефективността не е толкова висока, колкото при BorgBackup, но е сравнима по време с обикновения rsync.
С помощта на UrBackup успяхме да възстановим данните за 8 минути и 19 секунди, като натоварването в този случай беше
такова:
Все още е видно, че натоварването не е особено високо, дори по-ниско от това на tar. На места имаше пикове, но не повече от натоварването на едно ядро.
Избор и обосноваване на критериите за сравнение
Както беше споменато в една от предишните статии, системата за резервно копиране трябва да отговаря на следните критерии:
- Леснота при работа
- Универсалност
- Стабилност
- Бързина
Струва си да разгледаме всеки пункт поотделно по-подробно.
Леснота на работа
Най-добре е, когато има един бутон 'Направи всичко добре', но ако се върнем към реалните програми – най-удобно ще бъде да има известен познат и стандартен принцип на работа.
На повечето потребители, вероятно, ще им бъде по-добре, ако не трябва да помнят куп ключове за cli, да конфигурират различни, често неясни опции чрез уеб или tui, да настройват известия за неуспешно изпълнение. Сюда също спада възможността лесно да "впишем" решение за архивиране в съществуващата инфраструктура, както и автоматизация на процеса на архивиране. Тук е и възможността за инсталация с пакетен мениджър или с една-две команди от типа "изтегли и разархивирай". curl линк | sudo bash — сложен метод, тъй като трябва да проверите какво идва по линка.
Например, от разгледаните кандидати, простото решение е burp, rdiff-backup и restic, които имат мнемонично запомнящи се ключове за различни режими на работа. Малко по-сложно е с borg и duplicity. Най-сложното беше AMANDA. Останалите по простота на използване са някъде между.
Част от разгледаните кандидати могат автоматично да изпращат съобщение по e-mailjabber, докато други разчитат на настроени известия в системата. Въпреки това, сложните решения често имат не съвсем очевидни настройки за известия. Във всеки случай, ако програмата за архивиране издаде ненулев код за връщане, който системната услуга за периодични задачи интерпретира правилно (изпраща съобщение на системния администратор или директно в мониторинга) — ситуацията е проста. Но ако системата за архивиране, която не работи на сървъра за архивиране, не може без настройка, очевидно да посочи проблема — сложността вече е излишна. Във всеки случай, издаването на предупреждения и други съобщения само в уеб интерфейса и/или в журнала е лоша практика, тъй като най-често те ще бъдат пренебрегнати.
Що се отнася до автоматизацията — простата програма може да чете променливи на средата, задаващи режима на работа, или разполага с развит cli, способен напълно да дублира поведението при работа през уеб интерфейс, например. Сюда също спада възможността за потокова работа, наличието на възможности за разширяване и др.
Универсалност
Частично се припокрива с предишния подраздел относно автоматизация, не би трябвало да има особени проблеми с "вписването" на процеса на резервно копиране в съществуващата инфраструктура.
Важно е да се отбележи, че използването на нестандартни портове (освен уеб интерфейса) за работа, реализиране на криптиране по нестандартен начин, обмен на данни с нестандартен протокол — са признаци на неуниверсално решение. По-голямата част от кандидатите притежават такива характеристики по очевидни причини: простота и универсалност обикновено не са съвместими. Изключение от правилото е burp, съществуват и други.
Като признак — възможността за работа с обикновен ssh.
Скорост на работа
Най-противоречивият и спорен пункт. От една страна — стартирали сме процес, той е работил максимално бързо и не пречи на основните задачи. От друга страна — изблици на трафик и натоварване на процесора по време на резервното копиране. Освен това, най-бързите програми за създаване на копия обикновено имат най-малко функции, важни за потребителите. Отново: ако за да извлечем един нещастен текстов файл с размери няколко десетки байта с паролата, а заради него цялата услуга спира (да-да, разбирам, че тук процесът на резервно копиране най-често не е виновен), и трябва да прочетем последователно всички файлове в репозитория или да разархивираме цял архив — системата за резервно копиране не е бърза. Още един пункт, който често става камък на спъване — скоростта на възстановяване на резервната копия от архива. Тук явното предимство е при тези, които могат просто да копират или преместят файловете на нужното място без особени манипулации (например rsync), но най-често проблемът трябва да се решава организационно, емпирически: да измерваме времето за възстановяване на резервната копия и открито да съобщаваме на потребителите.
Стабилност
Трябва да се разбере по следния начин: от една страна, трябва да е възможно да се възстанови резервната копия по какъвто и да е начин, от друга страна — устойчивост на различни проблеми: прекъсване на мрежата, отказ на диск, изтриване на част от репозитория.
Сравнение на средства за резервно копиране
Време за създаване на копие
Време за възстановяване на копие
Лесна инсталация
Лесна настройка
Лесно използване
Лесна автоматизация
Нужен ли клиент-сервер?
Проверка целостности репозитория
Разностные копии
Работа чрез pipe
Универсалност
Самостоятельност
Прозрачност на репозитория
Шифроване
Сжатие
Дедупликация
Web-интерфейс
Заливка в облак
Подкрепа за Windows
Балл
Rsync
4m15s
4m28s
да
не
не
не
да
не
не
да
не
да
да
не
не
не
не
не
да
6
Tar
pure
3m12s
2m43s
да
не
не
не
не
не
да
да
не
да
не
не
не
не
не
не
да
8,5
gzip
9m37s
3m19s
да
Rdiff-backup
16m26s
17m17s
да
да
да
да
да
не
да
не
да
не
да
не
да
да
да
не
да
11
Rsnapshot
4m19s
4m28s
да
да
да
да
не
не
да
не
да
не
да
не
не
да
да
не
да
12,5
Burp
11m9s
7m2s
да
не
да
да
да
да
да
не
да
да
не
не
да
не
да
не
да
10,5
Duplicity
no encryption
16m48s
10m58s
да
да
не
да
не
да
да
не
не
да
не
да
да
не
да
не
да
11
gpg
17m27s
15m3s
Duplicati
no encryption
20m28s
13m45s
не
да
не
не
не
да
да
не
не
да
не
да
да
да
да
да
да
11
aes
29m41s
21m40s
gpg
26m19s
16m30s
Zbackup
no encryption
40m3s
11m8s
да
да
не
не
не
да
да
да
не
да
не
да
да
да
не
не
не
10
aes
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgBackup
no encryption
4m7s
2m45s
да
да
да
да
да
да
да
да
да
да
не
да
да
да
да
не
да
16
aes
4m58s
3m23s
blake2
4m39s
3m19s
Restic
5m38s
4m28s
да
да
да
да
не
да
да
да
да
да
не
да
не
да
не
да
да
15,5
UrBackup
8m21s
8m19s
да
да
да
не
да
не
да
не
да
да
не
да
да
да
да
не
да
12
Amanda
9m3s
2m49s
да
не
не
да
да
да
да
не
да
да
да
да
да
не
да
да
да
13
BackupPC
rsync
12m22s
7m42s
да
не
да
да
да
да
да
не
да
не
не
да
да
не
да
не
да
10,5
tar
12m34s
12m15s
Легенда на таблицата:
- Зелен, време за работа под пет минути, или отговор «Да» (освен в колоната «Нужен клиент-сервер?»), 1 балл
- Жълт, време за работа пет-десет минути, 0.5 балла
- Червен, време за работа над десет минути, или отговор «Не» (освен в колоната «Нужен клиент-сервер?»), 0 балла
Според горепосочената таблица, най-простият, бърз и в същото време удобен и мощен инструмент за резервно копиране е BorgBackup. Второто място зае Restic, а другите разгледани кандидати се подредиха приблизително еднакво с разлики от един-два бала в края.
Благодаря на всички, които прочетоха цикъла до края, предлагам да обсъдим варианти и да предложите свои, ако имате. С течение на обсъждането, таблицата може да бъде допълнена.
Резултатът от цикъла ще бъде заключителна статия, в която ще се опитаме да изведем идеално, бързо и управляемо средство за резервно копиране, което позволява бързо възстановяване на копието и в същото време – да има удобство и простота в настройката и поддръжката.
Анонс
Резервно копиране, част 6: Сравнение на средствата за резервно копиране
Резервно копиране, част 7: Изводи
Източник: habr.com
