nAbdullin 21 мая 2019 в 09:02

Резервное копирование, часть 2: Обзор и тестирование rsync-based средств резервного копирования

8 мин

19K

Блог компании СлёрмDevOps*Серверное администрирование*Системное администрирование*

Данной статьей продолжается

цикл о резервном копировании

Резервное копирование, часть 1: Зачем нужно резервное копирование, обзор методов, технологий
Резервное копирование, часть 2: Обзор и тестирование rsync-based средст резервного копирования
Резервное копирование, часть 3: Обзор и тестирование duplicity, duplicati
Резервное копирование, часть 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.

Анонс

Теги:

Хабы: