Тази статия ще сравни инструментите за архивиране, но първо трябва да разберете колко бързо и добре се справят с възстановяването на данни от архиви.
За по-лесно сравнение ще обмислим възстановяване от пълно архивиране, особено след като всички кандидати поддържат този режим на работа. За простота числата вече са осреднени (средната аритметична стойност от няколко серии). Резултатите ще бъдат обобщени в таблица, която ще съдържа и информация за възможностите: наличие на уеб интерфейс, лекота на настройка и работа, възможност за автоматизиране, наличие на различни допълнителни функции (например проверка на целостта на данните) и т.н. Графиките ще показват натоварването на сървъра, където ще се използват данните (а не сървъра за съхранение на резервни копия).
Възстановяване на данни
rsync и tar ще се използват като отправна точка оттогава прости скриптове за създаване на резервни копия.
Rsync се справи с набора от тестови данни за 4 минути и 28 секунди, показвайки
такова натоварване
Процесът на възстановяване се сблъска с ограничение на дисковата подсистема на сървъра за съхранение на резервни копия (графики на трион). Можете също така ясно да видите зареждането на едно ядро без никакви проблеми (low iowait и softirq - няма проблеми с диска и мрежата, съответно). Тъй като другите две програми, а именно rdiff-backup и rsnapshot, са базирани на rsync и също предлагат обикновен rsync като инструмент за възстановяване, те ще имат приблизително същия профил на натоварване и време за възстановяване на архива.
Катран свърши го малко по-бързо
2 минути и 43 секунди:
Общото натоварване на системата беше по-високо средно с 20% поради увеличения softirq - режийните разходи по време на работа на мрежовата подсистема се увеличиха.
Ако архивът бъде допълнително компресиран, времето за възстановяване се увеличава до 3 минути 19 секунди.
с такова натоварване на главния сървър (разопаковане отстрани на главния сървър):
Процесът на декомпресия заема и двете процесорни ядра, тъй като има два изпълнявани процеса. Като цяло това е очакваният резултат. Също така, сравним резултат (3 минути и 20 секунди) беше получен при стартиране на gzip от страна на сървъра с резервни копия; профилът на натоварване на главния сървър беше много подобен на изпълнението на tar без gzip компресора (вижте предишната графика).
В rdiff-резервно копие можете да синхронизирате последното архивиране, което сте направили, като използвате обикновен rsync (резултатите ще бъдат подобни), но по-старите архиви все още трябва да бъдат възстановени с помощта на програмата rdiff-backup, която завърши възстановяването за 17 минути и 17 секунди, показвайки
това натоварване:
Може би това е имало за цел поне да ограничи скоростта на авторите . Самият процес на възстановяване на резервно копие отнема малко по-малко от половината от едно ядро, с пропорционално сравнима производителност (т.е. 2-5 пъти по-бавна) на диск и мрежа с rsync.
Rsnapshot За възстановяване предлага използването на обикновен rsync, така че резултатите ще бъдат подобни. В общи линии така се получи.
Оригвам се Изпълних задачата за възстановяване на резервно копие за 7 минути и 2 секунди с
с това натоварване:
Работи доста бързо и поне е много по-удобно от чистия rsync: не е нужно да помните никакви флагове, прост и интуитивен интерфейс на cli, вградена поддръжка за множество копия - въпреки че е два пъти по-бавно. Ако трябва да възстановите данни от последното архивиране, което сте направили, можете да използвате rsync, с няколко предупреждения.
Програмата показа приблизително същата скорост и натоварване BackupPC при активиране на режима на прехвърляне на rsync, разполагане на резервното копие за
7 минути и 42 секунди:
Но в режим на пренос на данни BackupPC се справи с tar по-бавно: за 12 минути и 15 секунди натоварването на процесора като цяло беше по-ниско
един път и половина:
Лицемерие без криптиране показа малко по-добри резултати, като възстанови резервно копие за 10 минути и 58 секунди. Ако активирате криптиране с помощта на gpg, времето за възстановяване се увеличава до 15 минути и 3 секунди. Освен това, когато създавате хранилище за съхраняване на копия, можете да посочите размера на архива, който ще се използва при разделянето на входящия поток от данни. Като цяло при конвенционалните твърди дискове, също поради еднонишковия режим на работа, няма голяма разлика. Може да се появи с различни размери на блока, когато се използва хибридно съхранение. Натоварването на главния сървър по време на възстановяване беше както следва:
без криптиране
с криптиране
Дубликат показа сравнима скорост на възстановяване, завършвайки го за 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, така че ако го сравните с него, възстановяването е 3 пъти по-бавно. Може да си струва да проверите работата в многонишков режим, с повече от две нишки.
BorgBackup в некриптиран режим беше малко по-бавно от tar, за 2 минути 45 секунди, но за разлика от tar, стана възможно дедупликацията на хранилището. Товарът се оказа
следното:
Ако активирате blake-базирано криптиране, скоростта на възстановяване на архива е малко по-бавна. Времето за възстановяване в този режим е 3 минути 19 секунди и натоварването е изчезнало
като този:
AES криптирането е малко по-бавно, времето за възстановяване е 3 минути 23 секунди, натоварването е особено
не се е променило:
Тъй като Borg може да работи в многопоточен режим, натоварването на процесора е максимално и когато се активират допълнителни функции, времето за работа просто се увеличава. Очевидно си струва да проучите многопоточността по начин, подобен на zbackup.
Рестик се справи с възстановяването малко по-бавно, времето за работа беше 4 минути 28 секунди. Товарът изглеждаше така
така:
Очевидно процесът на възстановяване работи в няколко нишки, но ефективността не е толкова висока, колкото тази на BorgBackup, но сравнима във времето с обикновения rsync.
С urBackup Възстановяването на данните беше възможно за 8 минути и 19 секунди, натоварването беше
такива:
Натоварването все още не е много високо, дори по-ниско от това на катрана. На места има изблици, но не повече от натоварването на едно ядро.
Избор и обосновка на критерии за сравнение
Както беше посочено в една от предишните статии, системата за архивиране трябва да отговаря на следните критерии:
- Лекота на използване
- гъвкавост
- стабилност
- бързина
Струва си да разгледаме всяка точка поотделно по-подробно.
Лекота на работа
Най-добре е, когато има един бутон „Направете всичко добре“, но ако се върнете към реални програми, най-удобното ще бъде някакъв познат и стандартен принцип на работа.
Повечето потребители най-вероятно ще бъдат по-добре, ако не им се налага да помнят куп ключове за cli, да конфигурират куп различни, често неясни опции чрез уеб или tui или да настройват известия за неуспешна операция. Това включва и възможността за лесно „вместване“ на решение за архивиране в съществуващата инфраструктура, както и автоматизация на процеса на архивиране. Има и възможност за инсталиране с помощта на мениджър на пакети или с една или две команди като „изтегляне и разопаковане“. curl ссылка | sudo bash - сложен метод, тъй като трябва да проверите какво пристига през връзката.
Например, от разглежданите кандидати, просто решение е burp, rdiff-backup и restic, които имат мнемонични ключове за различни режими на работа. Малко по-сложни са borg и duplicity. Най-трудна беше АМАНДА. Останалите са някъде по средата по отношение на лекотата на използване. Във всеки случай, ако имате нужда от повече от 30 секунди, за да прочетете ръководството за потребителя или трябва да отидете в Google или друга търсачка и също така да превъртите дълъг лист с помощ, решението е трудно, по един или друг начин.
Някои от разглежданите кандидати са в състояние автоматично да изпратят съобщение чрез e-mailjabber, докато други разчитат на конфигурирани предупреждения в системата. Освен това най-често сложните решения имат не съвсем очевидни настройки за предупреждение. Във всеки случай, ако програмата за архивиране генерира ненулев код за връщане, който ще бъде правилно разбран от системната услуга за периодични задачи (ще бъде изпратено съобщение до системния администратор или директно до мониторинга) - ситуацията е проста. Но ако системата за архивиране, която не работи на резервен сървър, не може да бъде конфигурирана, очевидният начин да се каже за проблема е, че сложността вече е прекомерна. Във всеки случай издаването на предупреждения и други съобщения само към уеб интерфейса или към дневника е лоша практика, тъй като най-често те ще бъдат игнорирани.
Що се отнася до автоматизацията, една проста програма може да чете променливи на средата, които задават нейния режим на работа, или има разработен cli, който може напълно да дублира поведението при работа през уеб интерфейс, например. Това включва и възможността за непрекъсната работа, наличието на възможности за разширение и т.н.
гъвкавост
Отчасти повтаряйки предишния подраздел по отношение на автоматизацията, не би трябвало да представлява особен проблем „вместването“ на процеса на архивиране в съществуващата инфраструктура.
Струва си да се отбележи, че използването на нестандартни портове (е, с изключение на уеб интерфейса) за работа, прилагането на криптиране по нестандартен начин, обменът на данни с помощта на нестандартен протокол са признаци на не - универсално решение. В по-голямата си част всички кандидати ги имат по един или друг начин поради очевидната причина: простотата и гъвкавостта обикновено не вървят заедно. По изключение - оригване, има и други.
Като знак - възможността за работа с обикновен ssh.
Работна скорост
Най-противоречивата и спорна точка. От една страна, стартирахме процеса, той работи възможно най-бързо и не пречи на основните задачи. От друга страна, има скок в трафика и натоварването на процесора по време на периода на архивиране. Също така си струва да се отбележи, че най-бързите програми за правене на копия обикновено са най-бедните по отношение на функциите, които са важни за потребителите. Отново: ако за да получите един злополучен текстов файл с размер на няколко десетки байта с парола и поради това цялата услуга струва (да, да, разбирам, че процесът на архивиране най-често не е виновен тук), и трябва да прочетете отново последователно всички файлове в хранилището или да разширите целия архив - системата за архивиране никога не е бърза. Друг момент, който често се превръща в пречка, е скоростта на разгръщане на резервно копие от архив. Тук има ясно предимство за тези, които могат просто да копират или преместват файлове на желаното място без много манипулации (rsync, например), но най-често проблемът трябва да бъде разрешен по организационен начин, емпирично: чрез измерване на времето за възстановяване на архива и открито информиране на потребителите за това.
стабилност
Трябва да се разбира по следния начин: от една страна, трябва да е възможно резервното копие да се разположи обратно по всякакъв начин, от друга страна, то трябва да е устойчиво на различни проблеми: прекъсване на мрежата, повреда на диска, изтриване на част от хранилище.
Сравнение на инструментите за архивиране
Време за създаване на копие
Време за възстановяване на копието
Лесен монтаж
Лесна настройка
Проста употреба
Проста автоматизация
Имате ли нужда от клиентски сървър?
Проверка на целостта на хранилището
Диференциални копия
Работа чрез тръба
гъвкавост
независимост
Прозрачност на хранилището
Шифрование
компресия
Дедупликация
Уеб интерфейс
Пълнене до облака
Поддръжка на Windows
марка
Rsync
4m15s
4m28s
да
не
не
не
да
не
не
да
не
да
да
не
не
не
не
не
да
6
Катран
чист
3m12s
2m43s
да
не
не
не
не
не
да
да
не
да
не
не
не
не
не
не
да
8,5
GZIP
9m37s
3m19s
да
Rdiff-резервно копие
16m26s
17m17s
да
да
да
да
да
не
да
не
да
не
да
не
да
да
да
не
да
11
Rsnapshot
4m19s
4m28s
да
да
да
да
не
не
да
не
да
не
да
не
не
да
да
не
да
12,5
Оригвам се
11m9s
7m2s
да
не
да
да
да
да
да
не
да
да
не
не
да
не
да
не
да
10,5
Лицемерие
без криптиране
16m48s
10m58s
да
да
не
да
не
да
да
не
не
да
не
да
да
не
да
не
да
11
GPG
17m27s
15m3s
Дубликат
без криптиране
20m28s
13m45s
не
да
не
не
не
да
да
не
не
да
не
да
да
да
да
да
да
11
AES
29m41s
21m40s
GPG
26m19s
16m30s
zbackup
без криптиране
40m3s
11m8s
да
да
не
не
не
да
да
да
не
да
не
да
да
да
не
не
не
10
AES
42m0s
14m1s
aes+lzo
18m9s
6m19s
BorgBackup
без криптиране
4m7s
2m45s
да
да
да
да
да
да
да
да
да
да
не
да
да
да
да
не
да
16
AES
4m58s
3m23s
Блейк2
4m39s
3m19s
Рестик
5m38s
4m28s
да
да
да
да
не
да
да
да
да
да
не
да
не
да
не
да
да
15,5
urBackup
8m21s
8m19s
да
да
да
не
да
не
да
не
да
да
не
да
да
да
да
не
да
12
Аманда
9m3s
2m49s
да
не
не
да
да
да
да
не
да
да
да
да
да
не
да
да
да
13
BackupPC
Rsync
12m22s
7m42s
да
не
да
да
да
да
да
не
да
не
не
да
да
не
да
не
да
10,5
катран
12m34s
12m15s
Легенда на таблицата:
- Зелено, време на работа по-малко от пет минути или отговор „Да“ (с изключение на колоната „Нуждаете се от клиентски сървър?“), 1 точка
- Жълто, време за работа от пет до десет минути, 0.5 точки
- Червено, работното време е повече от десет минути или отговорът е „Не“ (с изключение на колоната „Имате ли нужда от клиентски сървър?“), 0 точки
Според горната таблица най-простият, най-бързият и в същото време удобен и мощен инструмент за архивиране е BorgBackup. Рестич зае второто място, останалите разглеждани кандидати бяха поставени приблизително еднакво с разлика от една или две точки в края.
Благодаря на всички, които прочетоха поредицата до края, каня ви да обсъдите вариантите и да предложите свои, ако има такива. С напредването на дискусията таблицата може да бъде разширена.
Резултатът от поредицата ще бъде последната статия, в която ще има опит да се разработи идеален, бърз и управляем инструмент за архивиране, който ви позволява да разположите копие обратно за възможно най-кратко време и в същото време да бъде удобен и лесен за конфигуриране и поддръжка.
Съобщение
Архивиране, част 6: Сравняване на инструментите за архивиране
Архивиране Част 7: Заключения
Източник: www.habr.com