Данной заметкой продолжается
цикл о резервном копировании
- Резервное копирование, часть 2: Обзор и тестирование rsync-based средст резервного копирования
- Резервное копирование, часть 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)
Running the test with following options:
Number of threads: 2
Initializing random number generator from current time
Prime numbers limit: 20000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 1081.62
General statistics:
total time: 30.0013s
total number of events: 32453
Latency (ms):
min: 1.48
avg: 1.85
max: 9.84
95th percentile: 2.07
sum: 59973.40
Threads fairness:
events (avg/stddev): 16226.5000/57.50
execution time (avg/stddev): 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)
Running the test with following options:
Number of threads: 4
Initializing random number generator from current time
Running memory speed test with the following options:
block size: 1KiB
total size: 102400MiB
operation: read
scope: global
Initializing worker threads...
Threads started!
Total operations: 104857600 (5837637.63 per second)
102400.00 MiB transferred (5700.82 MiB/sec)
General statistics:
total time: 17.9540s
total number of events: 104857600
Latency (ms):
min: 0.00
avg: 0.00
max: 66.08
95th percentile: 0.00
sum: 18544.64
Threads fairness:
events (avg/stddev): 26214400.0000/0.00
execution time (avg/stddev): 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)
Running the test with following options:
Number of threads: 4
Initializing random number generator from current time
Running memory speed test with the following options:
block size: 1KiB
total size: 102400MiB
operation: write
scope: global
Initializing worker threads...
Threads started!
Total operations: 91414596 (3046752.56 per second)
89272.07 MiB transferred (2975.34 MiB/sec)
General statistics:
total time: 30.0019s
total number of events: 91414596
Latency (ms):
min: 0.00
avg: 0.00
max: 1022.90
95th percentile: 0.00
sum: 66430.91
Threads fairness:
events (avg/stddev): 22853649.0000/945488.53
execution time (avg/stddev): 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)
Running the test with following options:
Number of threads: 4
Initializing random number generator from current time
Extra file open flags: (none)
128 files, 8MiB each
1GiB total file size
Block size 4KiB
Number of IO requests: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads...
Threads started!
File operations:
reads/s: 4587.95
writes/s: 3058.66
fsyncs/s: 9795.73
Throughput:
read, MiB/s: 17.92
written, MiB/s: 11.95
General statistics:
total time: 60.0241s
total number of events: 1046492
Latency (ms):
min: 0.00
avg: 0.23
max: 14.45
95th percentile: 0.94
sum: 238629.34
Threads fairness:
events (avg/stddev): 261623.0000/1849.14
execution time (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)
Running the test with following options:
Number of threads: 4
Initializing random number generator from current time
Extra file open flags: (none)
128 files, 8MiB each
1GiB total file size
Block size 4KiB
Number of IO requests: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads...
Threads started!
File operations:
reads/s: 11.37
writes/s: 7.58
fsyncs/s: 29.99
Throughput:
read, MiB/s: 0.04
written, MiB/s: 0.03
General statistics:
total time: 73.8868s
total number of events: 3104
Latency (ms):
min: 0.00
avg: 78.57
max: 3840.90
95th percentile: 297.92
sum: 243886.02
Threads fairness:
events (avg/stddev): 776.0000/133.26
execution time (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, имеет клиент-серверную архитектуру включая авторизацию клиентов, а также наличие web-интерфейса (не входит в базовую поставку). Еще одна интересная особенность — резервное копирование без права восстановления у клиентов.
Давайте посмотрим напроизводительность.
Первый запуск
Второй запуск
Третий запуск
Первый набор
11m21s
11m10s
10m56s
Второй набор
5m37s
5m40s
5m35s
Третий набор
3m33s
3m24s
3m40s
Отработал в 2 раза медленнее, чем rsnapshot, однако тоже достаточно быстро, и уж точно быстрее rdiff-backup. Графики немного пилообразны — производительность опять же упирается в дисковую подсистему сервера хранения резервных копий, хотя это и не так выражено, как у rsnapshot.
Результаты
Размер репозиториев у всех кандидатов был примерно одинаковым, т. е. сначала рост до 10 гб, потом рост до 15 гб, потом рост до 18 гб и т.д., что связано с особенностью работы rsync. Также стоит отметить однопоточность всех кандидатов (загрузка по процессору около 50% при двухядерной машине). Все 3 кандидата предоставляли возможность восстановления последней резервной копии «как есть», то есть можно было восстанавливать файлы без применения каких-либо сторонних программ включая те, которые применялись для создания репозиториев. Это также «родовое наследие» rsync.
Выводы
Чем сложнее система резервного копирования и чем больше у нее различных возможностей — тем медленнее она будет работать, но для не сильно требовательных проектов подойдет любая из них, кроме, возможно, rdiff-backup.
Анонс
Данная заметка продолжает цикл о резервном копировании
Резервное копирование, часть 2: Обзор и тестирование rsync-based средств резервного копирования
Резервное копирование, часть 3: Обзор и тестирование duplicity, duplicaty, deja dup
Резервное копирование, часть 4: Обзор и тестирование zbackup, restic, borgbackup
Резервное копирование, часть 5: Тестирование bacula и veeam backup for linux
Резервное копирование, часть 6: Сравнение средств резервного копирования
Резервное копирование, часть 7: Выводы
Автор публикации: Павел Демкович
Источник: habr.com