В тази статия ще направим сравнение на софтуерите за архивиране, но първо трябва да разберем как те бързо и ефективно възстановяват данни от архиви.
За опростяване на сравнението ще се разглежда възстановяване от пълно архивиране, тъй като този режим се поддържа от всички кандидати. За опростяване цифрите са взети уже средноаритметично (средно от няколко старта). Резултатите ще бъдат представени в таблица, в която също ще има информация за възможностите: наличие на уеб интерфейс, простота в настройката и използването, способност за автоматизация, наличието на различни допълнителни функции (например, проверка на целостта на данните) и т.н. Графиките ще покажат натоварването на сървъра, където данните ще бъдат прилагани (не на сървера за съхранение на архиви).
Възстановяване на данни
Като отправна точка ще се използват 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. Останалите по простота на използване са някъде по средата. Във всеки случай, ако имате нужда от повече от 30 секунди за четене на ръководството на потребителя или трябва да отидете в Google или друга търсачка, както и да прегледате дълъг документ с помощ — решението е по-сложно, каквото и да е.
Част от разгледаните кандидати могат автоматично да изпратят съобщение по e-mailjabber, докато други разчитат на настроени известия в системата. В същото време, най-често сложните решения имат не напълно очевидни настройки за известия. Във всеки случай, ако програмата за резервно копиране върне ненулев код за статус, който системната услуга за периодични задачи е настроена да разбира (ще изпрати съобщение на системния администратор или директно в мониторинга) — ситуацията е проста. Но ако системата за резервно копиране, работеща не на сървъра за резервни копия, не може без настройка да съобщи за проблема по очевиден начин — трудността става излишна. Във всеки случай, издаването на предупреждения и други съобщения само във уеб интерфейса и/или в журнала — е лоша практика, тъй като най-често те ще бъдат игнорирани.
Що се отнася до автоматизацията — простата програма може да чете средни променливи, които задават нейния режим на работа, или има развит CLI, способен напълно да дублира поведението при работа чрез уеб интерфейса, например. Тук влиза и възможността за работа в поток, наличието на възможности за разширение и т.н.
Универсалност
Частично съвпада с предишната подглава относно автоматизацията и не би трябвало да е особен проблем да 'впишете' процеса на резервно копие в съществуващата инфраструктура.
Следва да се отбележи, че използването на нестандартни портове (освен уеб интерфейса) за работа, реализирането на криптиране по нестандартен начин и обмена на данни чрез нестандартен протокол — признаци на неуниверсално решение. По-голямата част от кандидатите ги притежават по очевидна причина: простота и универсалност обикновено не са съвместими. Като изключение — burp, има и други.
Както знак — възможността за работа с обикновен ssh.
Скорост на работа
Най-противоречивата и спорна точка. От една страна — стартирали сме процеса, той е завършил максимално бързо и не пречи на основните задачи. От друга страна — повишение на трафика и натоварване на процесора по време на резервното копиране. Препоръчва се да се отбележи, че най-бързите програми за резервни копия обикновено са най-бедни на функции, важни за потребителите. Отново: ако за да извлечете един нещастен текстов файл с размери на десетки байтове с парола, и заради него целият сервис спира (да, разбирам, че тук процесът на резервно копие рядко е виновен), и трябва да прегледате последователно всички файлове в репозитория или да разширите цял архив — системата за резервно копиране изобщо не е бърза. Друг пункт, който често е камък на раздора — скоростта на възстановяване на резервното копие от архива. Тук явното предимство е у онези, които могат просто да копират или преместят файловете в нужната посока без особени манипулации (например rsync), но най-често проблемът трябва да се решава организационно, емпирично: да се измери времето за възстановяване на резервното копие и да се комуникира за това открито с потребителите.
Стабилност
Трябва да се разбира така: от една страна, трябва да има възможност за възстановяване на резервното копие по всяко време, от друга — устойчивост на различни проблеми: прекъсване на мрежата, отказ на диск, изтриване на част от репозитория.
Сравнение на средствата за резервно копиране
Време за създаване на копие
Време за възстановяване на копие
Лесна инсталация
Лесна настройка
Лесно използване
Лесна автоматизация
Нужен ли е клиент-сървър?
Проверка целостността на репозитория
Различни копия
Работа чрез pipe
Универсалност
Самостоятелност
Прозрачност на репозитория
Шифриране
Сжатие
Дедупликация
Web интерфейс
Качване в облака
Поддръжка на Windows
Бал
Rsync
4м15с
4м28с
да
недостъпен
недостъпен
недостъпен
да
недостъпен
недостъпен
да
недостъпен
да
да
недостъпен
недостъпен
недостъпен
недостъпен
недостъпен
да
6
Tar
pure
3м12с
2м43с
да
недостъпен
недостъпен
недостъпен
недостъпен
недостъпен
да
да
недостъпен
да
недостъпен
недостъпен
недостъпен
недостъпен
недостъпен
недостъпен
да
8,5
gzip
9м37с
3м19с
да
Rdiff-backup
16m26s
17м17с
да
да
да
да
да
недостъпен
да
недостъпен
да
недостъпен
да
недостъпен
да
да
да
недостъпен
да
11
Rsnapshot
4m19s
4м28с
да
да
да
да
недостъпен
недостъпен
да
недостъпен
да
недостъпен
да
недостъпен
недостъпен
да
да
недостъпен
да
12,5
Burp
11м9с
7м2с
да
недостъпен
да
да
да
да
да
недостъпен
да
да
недостъпен
недостъпен
да
недостъпен
да
недостъпен
да
10,5
Duplicity
без шифроване
16м48с
10м58с
да
да
недостъпен
да
недостъпен
да
да
недостъпен
недостъпен
да
недостъпен
да
да
недостъпен
да
недостъпен
да
11
gpg
17м27с
15м3с
Duplicati
без шифроване
20м28с
13м45с
недостъпен
да
недостъпен
недостъпен
недостъпен
да
да
недостъпен
недостъпен
да
недостъпен
да
да
да
да
да
да
11
aes
29м41с
21м40с
gpg
26м19с
16м30с
Zbackup
без шифроване
40м3с
11м8с
да
да
недостъпен
недостъпен
недостъпен
да
да
да
недостъпен
да
недостъпен
да
да
да
недостъпен
недостъпен
недостъпен
10
aes
42м0с
14м1с
aes+lzo
18м9с
6м19с
BorgBackup
без шифроване
4м7с
2m45s
да
да
да
да
да
да
да
да
да
да
недостъпен
да
да
да
да
недостъпен
да
16
aes
4м58с
3м23с
blake2
4м39с
3м19с
Restic
5м38с
4м28с
да
да
да
да
недостъпен
да
да
да
да
да
недостъпен
да
недостъпен
да
недостъпен
да
да
15,5
UrBackup
8м21с
8м19с
да
да
да
недостъпен
да
недостъпен
да
недостъпен
да
да
недостъпен
да
да
да
да
недостъпен
да
12
Amanda
9м3с
2м49с
да
недостъпен
недостъпен
да
да
да
да
недостъпен
да
да
да
да
да
недостъпен
да
да
да
13
BackupPC
rsync
12м22с
7м42с
да
недостъпен
да
да
да
да
да
недостъпен
да
недостъпен
недостъпен
да
да
недостъпен
да
недостъпен
да
10,5
tar
12м34с
12м15с
Легенда на таблицата:
- Зелен, време на работа под пет минути, или отговор «Да» (с изключение на колоната «Нужен ли е клиент-сервер?»), 1 бал
- Жълт, време на работа пет-десет минути, 0.5 бал
- Червен, време на работа над десет минути, или отговор «Не» (с изключение на колоната «Нужен ли е клиент-сервер?»), 0 бал
Според горната таблица, най-простият, бърз и удобен инструмент за резервно копиране е BorgBackup. Второ място заема Restic, а останалите разгледани кандидати са с доста близки резултати в рамките на един-два бала.
Благодаря на всички, които прочетоха поредицата до края, предлагам да обсъдим варианти и да предложите свои, ако имате. С времето, при обсъждане, таблицата може да бъде допълнена.
Резултатът от поредицата ще бъде заключителна статия, в която ще се опитаме да изведем идеалния, бърз и управляем инструмент за резервно копиране, който позволява бързо възстановяване на копия и същевременно предлага удобство и простота в настройката и поддръжката.
Анонс
Резервно копиране, част 6: Сравнение на инструменти за резервно копиране
Резервно копиране, част 7: Изводи
Източник: habr.com
