company_banner

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


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


    Как мы уже писали в первой статье, есть весьма большое число программ резервного копирования, основанных на 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. На тестовом сервере подготавливается файловая система с первым тестовым набором, на сервере хранения резервных копий при необходимости инициализируется репозиторий.
      Запускается процесс резервного копирования и замеряется его время.
    2. На тестовом сервере производится миграция файлов до второго тестового набора. Запускается процесс резервного копирования и замеряется его время.
    3. На тестовом сервере производится миграция до третьего тестового набора. Запускается процесс резервного копирования и замеряется его время.
    4. Полученный третий тестовый набор принимается новым первым; пункты 1-3 повторяются еще 2 раза.
    5. Данные заносятся в сводную таблицу, добавляются графики с netdata.
    6. Составляется отчет по отдельному методу резервного копирования.

    Ожидаемые результаты


    Так как все 3 кандидата основаны на одной и той же технологии (rsync), ожидается, что результаты будут близки к обычному rsync, включая все его преимущества, а именно:

    1. Файлы в репозитории будут храниться «как есть».
    2. Размер репозитория будет расти только включая разницу между резервными копиями.
    3. Будет сравнительно большая нагрузка на сеть при передаче данных, а также небольшая нагрузка на процессор.

    Тестовый прогон обычного 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.

    Анонс


    Данная заметка продолжает цикл о резервном копировании

    Резервное копирование, часть 1: Зачем нужно резервное копирование, обзор методов, технологий
    Резервное копирование, часть 2: Обзор и тестирование rsync-based средств резервного копирования
    Резервное копирование, часть 3: Обзор и тестирование duplicity, duplicati
    Резервное копирование, часть 4: Обзор и тестирование zbackup, restic, borgbackup
    Резервное копирование, часть 5: Тестирование Bacula и Veeam Backup for Linux
    Резервное копирование: часть по просьбам читателей: обзор AMANDA, UrBackup, BackupPC
    Резервное копирование, часть 6: Сравнение средств резервного копирования
    Резервное копирование, часть 7: Выводы

    Автор публикации: Finnix
    Southbridge
    529.22
    Обеспечиваем стабильную работу highload-проектов
    Share post

    Comments 6

      0
      Планируется ли обзор backuppc?
        0
        Добрый день! Возможно, в 6-й части рассмотрим.
        0
        urbackup я так понимаю пролетает по всем фронтам..? :(
          0
          В шестой части увидим и его тоже :)
          0
          Тестовый набор сделан немного нечестно по отношению к rdiff-backup. Его преимущество из этой тройки проявляется в ситуациях типа «каждый из 1000 10мб файлов изменяется на 1 бит каждый день, надо хранить копии за три месяца».
            +2
            Что касается тестового набора — давайте подождем ситуацию с borgbackup сотоварищи :)

          Only users with full accounts can post comments. Log in, please.