Тази бележка продължава
цикълът за резервно копиране
- Резервно копиране, част 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 тест
Инициализиране на работещите потоци...
Потоковете стартираха!
Операции с файлове:
reads/s: 4587.95
writes/s: 3058.66
fsyncs/s: 9795.73
Пропускна способност:
четене, MiB/s: 17.92
записано, MiB/s: 11.95
Обща статистика:
общо време: 60.0241s
общ брой събития: 1046492
Забавяне (ms):
min: 0.00
avg: 0.23
max: 14.45
95-ти процентил: 0.94
сума: 238629.34
Справедливост на потоковете:
събития (avg/stddev): 261623.0000/1849.14
време на изпълнение (avg/stddev): 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 тест
Инициализиране на работещите потоци...
Потоковете стартираха!
Операции с файлове:
reads/s: 11.37
writes/s: 7.58
fsyncs/s: 29.99
Пропускна способност:
четене, MiB/s: 0.04
записано, MiB/s: 0.03
Обща статистика:
общо време: 73.8868s
общ брой събития: 3104
Забавяне (ms):
min: 0.00
avg: 78.57
max: 3840.90
95-ти процентил: 297.92
сума: 243886.02
Справедливост на потоковете:
събития (avg/stddev): 776.0000/133.26
време на изпълнение (avg/stddev): 60.9715/1.59
Скорост на мрежата между сървърите
iperf3 -c backup
Connecting to host backup, port 5201
[ 4] local x.x.x.x port 59402 connected to y.y.y.y port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 419 MBytes 3.52 Gbits/sec 810 182 KBytes
[ 4] 1.00-2.00 sec 393 MBytes 3.30 Gbits/sec 810 228 KBytes
[ 4] 2.00-3.00 sec 378 MBytes 3.17 Gbits/sec 810 197 KBytes
[ 4] 3.00-4.00 sec 380 MBytes 3.19 Gbits/sec 855 198 KBytes
[ 4] 4.00-5.00 sec 375 MBytes 3.15 Gbits/sec 810 182 KBytes
[ 4] 5.00-6.00 sec 379 MBytes 3.17 Gbits/sec 765 228 KBytes
[ 4] 6.00-7.00 sec 376 MBytes 3.15 Gbits/sec 810 180 KBytes
[ 4] 7.00-8.00 sec 379 MBytes 3.18 Gbits/sec 765 253 KBytes
[ 4] 8.00-9.00 sec 380 MBytes 3.19 Gbits/sec 810 239 KBytes
[ 4] 9.00-10.00 sec 411 MBytes 3.44 Gbits/sec 855 184 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec 8100 sender
[ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec receiver
Методика на тестване
- На тестовия сървър се подготвя файловата система с първия тестови набор, а на сървъра за резервни копия при необходимост се инициализира хранилището.
Започва процесът на резервно копиране и времето му се измерва. - На тестовия сървър се извършва миграция на файловете до втория тестови набор. Започва процесът на резервно копиране и времето му се измерва.
- На тестовия сървър се извършва миграция до третия тестови набор. Започва процесът на резервно копиране и времето му се измерва.
- Полученият трети тестови набор става новият първи; стъпки 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
1m10s
1m10s
Работи много бързо, многократно по-бързо от rdiff-backup и много близо до чистия rsync.
Тестиране на burp
Още един вариант — реализация на C върху librsync — burp, с клиент-сървърна архитектура, включително удостоверяване на клиенти, а също така наличието на уеб интерфейс (не влиза в основния пакет). Една интересна особеност — резервно копиране без права за възстановяване на клиентите.
Нека погледнем напроизводителността.
Първо стартиране
Второ стартиране
Трето стартиране
Първи набор
11m21s
11m10s
10m56s
Втори набор
5m37s
5m40s
5m35s
Трети набор
3m33s
3m24s
3m40s
Работи два пъти по-бавно от rsnapshot, но също така е достатъчно бързо и със сигурност по-бързо от rdiff-backup. Графиките са малко зъбати — производителността отново е ограничена от дисковата подсистема на сървъра за резервни копия, макар че не е толкова изразена, колкото при rsnapshot.
Резултати
Размерите на репозиториите на всички кандидати бяха приблизително еднакви, т.е. първо растеж до 10 ГБ, след това до 15 ГБ, а след това до 18 ГБ и т.н., което е свързано с особеностите на работата на rsync. Също така е важно да се отбележи еднопоточността на всички кандидати (натоварването на процесора около 50% при двойноядрена машина). Всички 3 кандидата предлагаха възможност за възстановяване на последната резервна копия „както е“, т.е. можеше да се възстановяват файлове без използване на каквито и да било трети страни програми, включително тези, които са използвани за създаване на репозиториите. Това също е „родово наследство“ на rsync.
Изводи
Колкото по-сложна е системата за резервно копиране и колкото повече различни възможности предлага — толкова по-бавно ще работи, но за не толкова взискателни проекти всяка от тях ще е подходяща, освен, възможно, rdiff-backup.
Анонс
Тази бележка продължава цикъла за резервно копиране
Резервно копиране, част 2: Преглед и тест на средства за резервно копиране, базирани на rsync
Резервно копиране, част 3: Преглед и тестване на duplicity, duplicaty, deja dup
Резервно копиране, част 4: Преглед и тест на zbackup, restic, borgbackup
Резервно копиране, част 5: Тест на bacula и veeam backup for linux
Резервно копиране, част 6: Сравнение на средствата за резервно копиране
Резервно копиране, част 7: Изводи
Автор на публикацията: Павел Демкович
Източник: habr.com
