Съобщението продължава
цикъл за архивиране
- Архивиране, част 2: Преглед и тестване на базирани на rsync средства за архивиране
- Архивиране, част 3: Преглед и тестване на duplicity, duplicaty, deja dup
- Резервно копие, част 4: Преглед и тестване на zbackup, restic, borgbackup
- Резервно копиране, част 5: Тестване на bacula и veeam backup for linux
- Резервно копиране, част 6: Сравнение на инструменти за резервно копиране
- Резервно копиране, част 7: Изводи
Както вече споменахме в първата статия, има доста програми за архивиране, основани на rsync.
От всички, които най-добре отговарят на нашите условия, ще разгледам 3: rdiff-backup, rsnapshot и burp.
Тестови файлови набори
Наборите за тестване ще бъдат еднакви за всички кандидати, включително за бъдещи статии.
Първи набор: 10 ГБ медийни файлове и около 50 МБ — изходен код на сайта на php, размерите на файловете варират от няколко килобайта за изходния код до десетки мегабайти за медийните файлове. Целта е да се имитира статичен сайт.
Втори набор: произлиза от първия при преименуване на поддиректорията с медийните файлове с размер 5 ГБ. Целта е да се проучи поведението на системата за архивиране при преименуване на директория.
Трети набор: произлиза от първия с изтриването на 3 ГБ медийни файлове и добавянето на нови 3 ГБ медийни файлове. Целта е да се проучи поведението на системата за архивиране при типични действия за обновяване на сайта.
Получаване на резултати
Всяко архивиране се извършва минимум 3 пъти и се съпровожда от нулиране на кеша на файловата система с команди sync и echo 3 > /proc/sys/vm/drop_caches както на страната на тестовия сървър, така и на сървъра за съхранение на резервни копия.
На сървъра, който ще бъде източник на резервните копия, е инсталиран софтуер за мониторинг — netdata, с помощта на който ще се оценява натоварването на сървъра при архивиране, необходимо е за оценка на натоварването на сървъра по време на процеса на архивиране.
Смятам също така, че сървърът за съхранение на резервни копия е по-бавен по процесор в сравнение с основния сървър, но разполага с по-големи дискове с относително ниска скорост на произволно записване — най-често срещаната ситуация при архивиране, а поради факта, че архивиращият сървър не трябва да извършва други задачи освен архивиране, няма да следя натоварването му с netdata.
Също така, промених сървърите, на които ще проверявам различни системи за архивиране.
Сега те имат следните характеристикиПроцесор
sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
Изпълнение на теста с следните опции:
Брой нишки: 2
Инициализиране на генератор на случайни числа от текущото време
Граница на простите числа: 20000
Инициализиране на работни нишки...
Нишките стартираха!
Скорост на CPU:
събития в секунда: 1081.62
Обща статистика:
общо време: 30.0013s
общ брой събития: 32453
Забавяне (ms):
мин: 1.48
средно: 1.85
макс: 9.84
95-ти процентил: 2.07
сума: 59973.40
Справедливост на нишките:
събития (средно/стандартно отклонение): 16226.5000/57.50
време на изпълнение (средно/стандартно отклонение): 29.9867/0.00
Оперативна памет, четене…
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=read memory run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
Изпълнение на теста с следните опции:
Брой нишки: 4
Инициализиране на генератор на случайни числа от текущото време
Изпълнение на тест за скорост на паметта с следните опции:
размер на блока: 1KiB
общ размер: 102400MiB
операция: четене
обхват: глобален
Инициализиране на работни нишки...
Нишките стартираха!
Общ брой операции: 104857600 (5837637.63 на секунда)
102400.00 MiB пренесени (5700.82 MiB/сек)
Обща статистика:
общо време: 17.9540s
общ брой събития: 104857600
Забавяне (ms):
мин: 0.00
средно: 0.00
макс: 66.08
95-ти процентил: 0.00
сума: 18544.64
Справедливост на нишките:
събития (средно/стандартно отклонение): 26214400.0000/0.00
време на изпълнение (средно/стандартно отклонение): 4.6362/0.12
… и запис
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=write memory run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
Изпълнение на теста с следните опции:
Брой нишки: 4
Инициализиране на генератор на случайни числа от текущото време
Изпълнение на тест за скорост на паметта с следните опции:
размер на блока: 1KiB
общ размер: 102400MiB
операция: запис
обхват: глобален
Инициализиране на работни нишки...
Нишките стартираха!
Общ брой операции: 91414596 (3046752.56 на секунда)
89272.07 MiB пренесени (2975.34 MiB/сек)
Обща статистика:
общо време: 30.0019s
общ брой събития: 91414596
Забавяне (ms):
мин: 0.00
средно: 0.00
макс: 1022.90
95-ти процентил: 0.00
сума: 66430.91
Справедливост на нишките:
събития (средно/стандартно отклонение): 22853649.0000/945488.53
време на изпълнение (средно/стандартно отклонение): 16.6077/1.76
Диск на сервера-източник на данни
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
Стартиране на теста с следните опции:
Брой на нишките: 4
Инициализиране на генератора на случайни числа от текущото време
Допълнителни флагове за отваряне на файл: (няма)
128 файла, по 8MiB всеки
Обща големина на файла 1GiB
Размер на блока 4KiB
Брой заявка за IO: 0
Съотношение четене/запис за комбиниран случайно IO тест: 1.50
Периодичен FSYNC включен, извикване на fsync() на всеки 100 заявки.
Извикване на fsync() в края на теста, Включен.
Използване на синхронен I/O режим
Извършване на случаен r/w тест
Инициализиране на работни нишки...
Нишките стартираха!
Файлови операции:
четения/s: 4587.95
записи/s: 3058.66
fsyncs/s: 9795.73
Пропускание:
четене, MiB/s: 17.92
записано, MiB/s: 11.95
Обща статистика:
общо време: 60.0241s
общ брой събития: 1046492
Забавяне (ms):
мин: 0.00
средно: 0.23
макс: 14.45
95-ти процентил: 0.94
сума: 238629.34
Справедливост на нишките:
събития (средно/стандартно отклонение): 261623.0000/1849.14
време на изпълнение (средно/стандартно отклонение): 59.6573/0.00
Диск на сървъра за съхранение на резервни копия
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
Стартиране на теста с следните опции:
Брой на нишките: 4
Инициализиране на генератора на случайни числа от текущото време
Допълнителни флагове за отваряне на файл: (няма)
128 файла, по 8MiB всеки
Обща големина на файла 1GiB
Размер на блока 4KiB
Брой заявка за IO: 0
Съотношение четене/запис за комбиниран случайно IO тест: 1.50
Периодичен FSYNC включен, извикване на fsync() на всеки 100 заявки.
Извикване на fsync() в края на теста, Включен.
Използване на синхронен I/O режим
Извършване на случаен r/w тест
Инициализиране на работни нишки...
Нишките стартираха!
Файлови операции:
четения/s: 11.37
записи/s: 7.58
fsyncs/s: 29.99
Пропускане:
четене, MiB/s: 0.04
записано, MiB/s: 0.03
Обща статистика:
общо време: 73.8868s
общ брой събития: 3104
Забавяне (ms):
мин: 0.00
средно: 78.57
макс: 3840.90
95-ти процентил: 297.92
сума: 243886.02
Справедливост на нишките:
събития (средно/стандартно отклонение): 776.0000/133.26
време на изпълнение (средно/стандартно отклонение): 60.9715/1.59
Скорост на мрежата между сървърите
iperf3 -c backup
Свързвам се с хоста backup, порт 5201
[ 4] локален x.x.x.x порт 59402 свързан с y.y.y.y порт 5201
[ ID] Интервал Пренос Пропусквателна способност Retr Cwnd
[ 4] 0.00-1.00 сек 419 MBytes 3.52 Gbits/сек 810 182 KBytes
[ 4] 1.00-2.00 сек 393 MBytes 3.30 Gbits/сек 810 228 KBytes
[ 4] 2.00-3.00 сек 378 MBytes 3.17 Gbits/сек 810 197 KBytes
[ 4] 3.00-4.00 сек 380 MBytes 3.19 Gbits/сек 855 198 KBytes
[ 4] 4.00-5.00 сек 375 MBytes 3.15 Gbits/сек 810 182 KBytes
[ 4] 5.00-6.00 сек 379 MBytes 3.17 Gbits/сек 765 228 KBytes
[ 4] 6.00-7.00 сек 376 MBytes 3.15 Gbits/сек 810 180 KBytes
[ 4] 7.00-8.00 сек 379 MBytes 3.18 Gbits/сек 765 253 KBytes
[ 4] 8.00-9.00 сек 380 MBytes 3.19 Gbits/сек 810 239 KBytes
[ 4] 9.00-10.00 сек 411 MBytes 3.44 Gbits/сек 855 184 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Интервал Пренос Пропусквателна способност Retr
[ 4] 0.00-10.00 сек 3.78 GBytes 3.25 Gbits/сек 8100 изпращач
[ 4] 0.00-10.00 сек 3.78 GBytes 3.25 Gbits/сек получател
Методология на тестването
- На тестовия сървър се подготвя файловата система с първия тестов набор, на сървъра за архивиране при необходимост се инициализира хранилището.
Започва процесът на архивиране и се измерва времето му. - На тестовия сървър се извършва миграция на файловете до втория тестов набор. Започва процесът на архивиране и се измерва времето му.
- На тестовия сървър се извършва миграция до третия тестов набор. Започва процесът на архивиране и се измерва времето му.
- Полученият трети тестов набор се приема за нов първи; точки 1-3 се повтарят още 2 пъти.
- Данните се вписват в обобщаваща таблица, добавят се графики с netdata.
- Съставя се отчет за отделния метод на архивиране.
Очаквани резултати
Тъй като всичките 3 кандидата са базирани на една и съща технология (rsync), се очаква, че резултатите ще бъдат близки до обичайния rsync, включително всички негови предимства, а именно:
- Файловете в хранилището ще се съхраняват "както са".
- Размерът на хранилището ще нараства само с включването на разликата между архивите.
- Ще има сравнително голямо натоварване на мрежата при пренос на данни, както и малко натоварване на процесора.
Тестовият прогон на обикновен rsync ще се използва като еталон, неговите резултати
са следните
Тясното място беше на сървъра за съхранение на резервни данни под формата на диск на базата на HDD, което е достатъчно ясно видимо на графиките под формата на трион.
Данните бяха копирани за 4 минути и 15 секунди.
Тестът на rdiff-backup
Първият кандидат е rdiff-backup, скрипт на Python, който извършва архивиране на една директория в друга. В този случай текущото архивиране се съхранява „както е“, а предишните архиви се съхраняват инкрементално в специална поддиректория, спестявайки по този начин място.
Ще проверим типичния режим на работа, т.е. стартирането на процеса на архивиране се инициира от клиента самостоятелно, а от страната на сървъра се стартира процес, който приема данните за архивиране.
Нека погледнем, какво може той в нашите условия.
Време на работа на всеки тестов стартиращ процес:
Първо стартиране
Второ стартиране
Трето стартиране
Първи набор
16m32s
16m26s
16m19s
Втори набор
2h5m
2h10m
2h8m
Трети набор
2h9m
2h10m
2h10m
Rdiff-backup реагира доста болезнено на всякакви значителни промени в данните, също така не усвоява напълно мрежата.
Тестове на rsnapshot
Вторият кандидат е rsnapshot, който представлява скрипт на Perl, като основното изискване за ефективна работа е поддръжката на твърди връзки. По този начин се спестява място на диска. Непроменените файлове от предишното архивиране ще посочват оригиналния файл чрез твърди връзки.
Също така е инвертирана логиката на процеса на архивиране: сървърът активно „обикаля“ из клиентите си и събира данните.
Резултати от тестуването
Получиха се следните
Първо стартиране
Второ стартиране
Трето стартиране
Първи набор
4m22s
4m19s
4m16s
Втори набор
2m6s
2m10s
2m6s
Трети набор
1m18s
Работи изключително бързо, много по-бързо от rdiff-backup и много близо до чистия rsync.
Работи изключително бързо, много по-бързо от rdiff-backup и много близо до чистия rsync.
Тестове на burp
Още един вариант е реализация на C над librsync — burp, с клиент-сървърна архитектура, включваща авторизация на клиенти, а също така наличието на уеб интерфейс (не влиза в основния пакет). Още едно интересно предимство е архивирането без право на възстановяване от клиентите.
Нека погледнем на
11m21sпроизводителност.
Първо стартиране
Второ стартиране
Трето стартиране
Първи набор
11m10s
10m56s
5m37s
Втори набор
5m40s
3m33s
5m35s
Трети набор
3m24s
3m40s
Работи два пъти по-бавно от rsnapshot, обаче също е достатъчно бърз и със сигурност по-бърз от rdiff-backup. Графиките са леко зъбчати — производителността отново зависи от дисковата система на сървъра за архивиране, въпреки че това не е толкова изразено, колкото при rsnapshot.
Работеше два пъти по-бавно от rsnapshot, но все пак е достатъчно бързо и определено по-бързо от rdiff-backup. Графиките са малко стъпаловидни - производителността отново зависи от дисковата подсистема на сървъра за резервни копия, макар че не е толкова изразена, както при rsnapshot.
Резултати
Размерът на репозиторите при всички кандидати беше приблизително еднакъв — първо нарастване до 10 ГБ, след това до 15 ГБ, а след това до 18 ГБ и т.н., което е свързано с особеностите на работата на rsync. Също така е важно да се отбележи, че всички кандидати работят в един поток (натоварването на процесора е около 50% при двуядрена машина). Всички трима кандидати предоставиха възможност за възстановяване на последната резервна копия „както е“, т.е. файловете можеха да се възстановят без използването на каквито и да било външни програми, включително тези, използвани за създаването на репозиториите. Това също е „родово наследство“ на rsync.
Изводи
Колкото по-сложна е системата за резервно копиране и колкото повече различни възможности има — толкова по-бавно ще работи, но за не много взискателни проекти, всяка от тях ще е подходяща, с изключение, може би, на rdiff-backup.
Анонс
Тази бележка продължава цикъла за резервно копиране
Архивиране, част 2: Преглед и тестване на инструменти за архивиране на базата на rsync
Архивиране, част 3: Преглед и тестване на duplicity, duplicaty, deja dup
Резервно копие, част 4: Преглед и тестване на zbackup, restic, borgbackup
Резервно копиране, част 5: Тестване на bacula и veeam backup for linux
Резервно копиране, част 6: Сравнение на инструменти за резервно копиране
Резервно копиране, част 7: Изводи
Автор на публикацията: Павел Демкович
Източник: habr.com
