Резервное копирование, часть 4: Обзор и тестирование zbackup, restic, borgbackup


    В данной статье будут рассматриваться программные средства для резервного копирования, которые путем разбиения потока данных на отдельные компоненты (chunks), формируют репозиторий.


    Компоненты репозитория могут дополнительно сжиматься и шифроваться, а самое главное — при повторных процессах резервного копирования — переиспользоваться повторно.


    Резервная копия в подобном репозитории — именованная цепочка связанных друг с другом компонентов, например, на основе различных hash-функций.


    Есть несколько подобных решений, я остановлюсь на 3: zbackup, borgbackup и restic.


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


    Поскольку все претенденты так или иначе требуют создания репозитория, одним из важнейших факторов будет оценка размера репозитория. В идеальном случае его размер должен быть не более 13 гб согласно принятой методике, а то и меньше — при условии хорошей оптимизации.


    Также крайне желательно иметь возможность создавать резервные копии файлов напрямую, без применения архиваторов типа tar, а также работу с ssh/sftp без дополнительных средств вроде rsync и sshfs.


    Поведение при создании резервных копий:


    1. Размер репозитория будет равен размеру изменений, или меньше.
    2. Ожидается большая нагрузка на процессор при использовании сжатия и/или шифрования, а также вероятна достаточно большая нагрузка на сеть и дисковую подсистему, если процесс архивации и/или шифрования будет работать на сервере хранения резервных копий.
    3. Если повредить репозиторий — вероятна отложенная ошибка как при создании новых резервных копий, так и при попытке восстановления. Надо планировать дополнительные меры по обеспечению целостности репозитория или использовать встроенные средства проверки его целостности.

    В качестве эталонного значения принята работа с tar, как это было показано в одной из прошлых статей.


    Тестирование zbackup


    Общий механизм работы zbackup заключается в том, что программа находит в потоке данных, подаваемом на входе, области, содержащие одинаковые данные, затем опционально их сжимает, шифрует, сохраняя каждую область только 1 раз.


    Для дедупликации используется 64-битная кольцевая hash-функция со скользящим окном для побайтной проверки на совпадение с уже существующими блоками данных (подобному тому, как это реализовано в rsync).


    Для сжатия применяется lzma и lzo в многопоточном исполнении, а для шифрования — aes. В последних версиях присутствует возможность в будущем удалять старые данные из репозитория.
    Программа написана на C++ с минимальными зависимостями. Автор по всей видимости вдохновлялся unix-way, поэтому программа принимает данные на stdin при создании резервных копий, выдавая аналогичный поток данных в stdout при восстановлении. Таким образом, zbackup можно использовать как весьма неплохой "кирпичик" при написании собственных решений резервного копирования. Например, у автора статьи эта программа является основным средством резервного копирования для домашних машин примерно с 2014 года.


    В качестве потока данных будет применяться обычный tar, если не сказано иначе.


    Посмотрим, какие будут результаты:

    Проверка работы выполнялась в 2 вариантах:


    1. создается репозиторий и запускается zbackup на сервере с исходными данными, потом содержимое репозитория передается на сервер хранения резервных копий.
    2. создается репозиторий на сервере хранения резервных копий, запускается zbackup через ssh на сервере хранения резервных копий, ему через pipe выдаются данные.

    Результаты первого варианта были такие: 43m11s — при использовании нешифрованного репозитория и компрессора lzma, 19m13s — при замене компрессора на lzo.


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



    Ясно видно, что подобный процесс резервного копирования годится лишь при относительно редких и небольших изменениях. Также крайне желательно ограничивать работу zbackup в 1 поток, иначе будет весьма высокая загрузка по процессору, т.к. программа весьма хорошо умеет работать в несколько потоков. Нагрузка на диск была небольшой, что в целом при современной дисковой подсистеме на основе ssd будет незаметно. Также четко видно запуск процесса синхронизации данных репозитория на удаленный сервер, скорость работы сравнима с обычным rsync и упирается в производительность дисковой подсистемы сервера хранения резервных копий. Минусом подхода является хранение локального репозитория и, как следствие, — дублирование данных.


    Более интересным и применимым на практике является второй вариант с запуском zbackup сразу на сервере хранения резервных копий.


    Для начала будет проверена работа без использования шифрования c компрессором lzma:



    Время работы каждого тестового запуска:


    Запуск 1 Запуск 2 Запуск 3
    39m45s 40m20s 40m3s
    7m36s 8m3s 7m48s
    15m35s 15m48s 15m38s

    Если активировать шифрование с применением aes, результаты достаточно близки:



    Время работы на тех же данных, с шифрованием:


    Запуск 1 Запуск 2 Запуск 3
    43m40s 44m12s 44m3s
    8m3s 8m15s 8m12s
    15m0s 15m40s 15m25s

    Если шифрование совместить с сжатием на lzo, выходит так:



    Время работы:


    Запуск 1 Запуск 2 Запуск 3
    18m2s 18m15s 18m12s
    5m13s 5m24s 5m20s
    8m48s 9m3s 8m51s

    Размер результирующего репозитория был относительно одинаков и составлял 13гб. Это значит, что дедупликация работает корректно. Также на уже сжатых данных применение lzo дает ощутимый эффект, по общему времени работы zbackup вплотную приближается к duplicity/duplicati, однако отставая от основанных на librsync в 2-5 раз.


    Преимущества очевидны — экономия дискового пространства на сервере хранения резервных копий. Что касается инструментов проверки репозитория — автором zbackup они не предусмотрены, рекомендуется применять отказоустойчивый дисковый массив или облачный провайдер.


    В целом весьма неплохое впечатление, несмотря на то, что проект примерно 3 года стоит на месте (последний feature request был около года назад, но без ответа).


    Тестирование borgbackup


    Borgbackup является форком attic, еще одной, схожей с zbackup системы. Написан на python, имеет схожий с zbackup список возможностей, но дополнительно умеет:


    • Монтировать резервные копии через fuse
    • Проверять содержимое репозитория
    • Работать в режиме клиент-сервер
    • Использовать различные компрессоры для данных, а также эвристическое определение типа файла при его компрессии.
    • 2 варианта шифрования, aes и blake
    • Встроенное средство для

    проверки производительности

    borgbackup benchmark crud ssh://backup_server/repo/path local_dir


    Результаты получились такие:


    C-Z-BIG 96.51 MB/s (10 100.00 MB all-zero files: 10.36s)
    R-Z-BIG 57.22 MB/s (10
    100.00 MB all-zero files: 17.48s)
    U-Z-BIG 253.63 MB/s (10 100.00 MB all-zero files: 3.94s)
    D-Z-BIG 351.06 MB/s (10
    100.00 MB all-zero files: 2.85s)
    C-R-BIG 34.30 MB/s (10 100.00 MB random files: 29.15s)
    R-R-BIG 60.69 MB/s (10
    100.00 MB random files: 16.48s)
    U-R-BIG 311.06 MB/s (10 100.00 MB random files: 3.21s)
    D-R-BIG 72.63 MB/s (10
    100.00 MB random files: 13.77s)
    C-Z-MEDIUM 108.59 MB/s (1000 1.00 MB all-zero files: 9.21s)
    R-Z-MEDIUM 76.16 MB/s (1000
    1.00 MB all-zero files: 13.13s)
    U-Z-MEDIUM 331.27 MB/s (1000 1.00 MB all-zero files: 3.02s)
    D-Z-MEDIUM 387.36 MB/s (1000
    1.00 MB all-zero files: 2.58s)
    C-R-MEDIUM 37.80 MB/s (1000 1.00 MB random files: 26.45s)
    R-R-MEDIUM 68.90 MB/s (1000
    1.00 MB random files: 14.51s)
    U-R-MEDIUM 347.24 MB/s (1000 1.00 MB random files: 2.88s)
    D-R-MEDIUM 48.80 MB/s (1000
    1.00 MB random files: 20.49s)
    C-Z-SMALL 11.72 MB/s (10000 10.00 kB all-zero files: 8.53s)
    R-Z-SMALL 32.57 MB/s (10000
    10.00 kB all-zero files: 3.07s)
    U-Z-SMALL 19.37 MB/s (10000 10.00 kB all-zero files: 5.16s)
    D-Z-SMALL 33.71 MB/s (10000
    10.00 kB all-zero files: 2.97s)
    C-R-SMALL 6.85 MB/s (10000 10.00 kB random files: 14.60s)
    R-R-SMALL 31.27 MB/s (10000
    10.00 kB random files: 3.20s)
    U-R-SMALL 12.28 MB/s (10000 10.00 kB random files: 8.14s)
    D-R-SMALL 18.78 MB/s (10000
    10.00 kB random files: 5.32s)


    При тестировании будет использоваться эвристика при компрессии с определением типа файла (compression auto), а результаты будут такие:


    Для начала проверим работу без шифрования:


    Время работы:


    Запуск 1 Запуск 2 Запуск 3
    4m6s 4m10s 4m5s
    56s 58s 54s
    1m26s 1m34s 1m30s

    Если включить авторизацию репозитория (режим authenticated), результаты получатся близкими:



    Время работы:


    Запуск 1 Запуск 2 Запуск 3
    4m11s 4m20s 4m12s
    1m0s 1m3s 1m2s
    1m30s 1m34s 1m31s

    При активации шифрования aes результаты не сильно ухудшились:



    Запуск 1 Запуск 2 Запуск 3
    4m55s 5m2s 4m58s
    1m0s 1m2s 1m0s
    1m49s 1m50s 1m50s

    А если поменять aes на blake, ситуация вовсе улучшится:



    Время работы:


    Запуск 1 Запуск 2 Запуск 3
    4m33s 4m43s 4m40s
    59s 1m0s 1m0s
    1m38s 1m43s 1m40s

    Как и в случае с zbackup, размер репозитория составил 13гб и даже чуть меньше, что, в целом, ожидаемо. Весьма порадовало время работы, оно сравнимо с решениями на основе librsync, обеспечивая гораздо более широкие возможности. Также порадовала возможность задания различных параметров через переменные окружения, что дает весьма серьезное преимущество при использовании borgbackup в автоматическом режиме. Также порадовала нагрузка при резервном копировании: судя по загрузке процессора — borgbackup работает в 1 поток.


    Особых минусов при использовании не обнаружилось.


    Тестирование restic


    Несмотря на то, что restic достаточно новое решение (первые 2 кандидата были известны еще с 2013 года и старше), он обладает достаточно неплохими характеристиками. Написан на Go.


    Если сравнивать с zbackup, дополнительно дает:


    • Проверку целостности репозитория (включая проверку по частям).
    • Огромный список поддерживаемых протоколов и провайдеров для хранения резервных копий, а также поддержку rclone — rsync для "облачных" решений.
    • Сравнение 2 резервных копий между собой.
    • Монтирование репозитория через fuse.

    В целом список возможностей достаточно близок к borgbackup, местами больше, местами меньше. Из особенностей — отсутствие возможности отключения шифрования, а следовательно, резервные копии будут зашифрованными всегда. Давайте посмотрим на практике, что можно выжать из этого ПО:


    Результаты получились таковы:


    Время работы:


    Запуск 1 Запуск 2 Запуск 3
    5m25s 5m50s 5m38s
    35s 38s 36s
    1m54s 2m2s 1m58s

    Результаты работы также сравнимы с решениями на основе rsync и, в целом, весьма близки к borgbackup, но нагрузка на процессор более высокая (работает несколько потоков) и пилообразная.


    Вероятнее всего, программа упирается в производительность дисковой подсистемы на сервере хранения данных, как это уже было с rsync. Размер репозитория составил 13гб, как и у zbackup или borgbackup, явных минусов при использовании этого решения не обнаружилось.


    Результаты


    По факту у всех кандидатов получились близкие показатели, однако разной ценой. Лучше всех показал себя borgbackup, чуть медленнее — restic, zbackup, вероятно, не стоит начинать применять,
    а если он уже используется — пробовать менять на borgbackup или restic.


    Выводы


    Наиболее перспективным решением выглядит restic, т.к. именно он обладает наилучшим соотношением возможностей к скорости работы, но пока не будем торопиться с общими выводами.


    Borgbackup в принципе ничем не хуже, а вот zbackup вероятно лучше заменить. Правда, для обеспечения работы правила 3-2-1 zbackup все еще можно задействовать. Например, в дополнение к средствам резервного копирования на основе (lib)rsync.


    Анонс


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


    Автор публикации: Павел Демкович

    Southbridge
    362,57
    Обеспечиваем стабильную работу серверов
    Поделиться публикацией

    Комментарии 20

      0

      Минус подобных решений — низкая скорость восстановления данных из бекапа. Говорю на примере restic, но подозреваю что у других тоже. Доставать данные из снапшота достаточно долго, монтировать снапшот в фс — еще дольше. Так что низкий MTTR — мимо.

        0

        не знаю насчет restic, наши девопсы им пользуются, лично для себя выбрал давно borgbackup из-за поддержки hetzner backup из коробки, восстановление снапшота при наличии локального репозтория мгновенно: borg mount repo::backup /path/to/mount потом можно сразу начинать rsync

          0
          Добрый день! Процесс резервного копирования — часть общего процесса, поэтому настоящие джедаи, для особенно критических с точки зрения доступности сервисов, делают PITR и соблюдают правило 3-2-1. Но эта задача весьма уверенно переходит в разряд с SLA, и если клиента предупредили, что раскатка с резервной копии будет сутки, и клиент согласился — все в порядке.
            0
            Безусловно вы правы. Просто говорю о том чтобы не воспринимали как серебряную пулю. Тем более глядя на скорости создания резервной копии можно автоматически подумать что и достать ее можно будет также быстро. А потом оказывается что нет.
            А тот же restic сам ценю и широко применяю.
          +1
          Спасибо за интересный тест :) Когда выбирал для бэкапа домашней тачки решение, выбирал между borg и restic. Начал с borg, но хотелось поддержки rclone, а тогда её у него не было(не знаю, как сейчас), в результате попробовал и restic. Последний оказался очень похож на borg, но в отличии от первого полностью подходил под решение нужной мне задачи(бэкапы с шифрованием + поддержка облачных хранилищ) — в результате я стал юзать именно его.
            0

            А вы не пробовали тестировать DAR (Disk ARchive)? Интересно было бы сравнение с тем же restic.

              0
              Добрый день! В предыдущей статье он упоминался, но из-за того, что текущая методика тестирования не покрывает и 10% его возможностей — его обзор может быть будет в 6-й части цикла.
              +1
              Почему-то опущен большой плюс утилит на Go — что тул поставляется в виде одного бинарника, причем, с минимум зависимостей. Это значит, что внезапный апдейт python не поломает совместимость или запуск бэкапа в принципе. Что мне не надо беспокоится, что в системе будет нужная версия питончика. Установка и запуск borg даже на домашней убунте всё же вызывает некоторую боль.
              P.S. Спасибо за restic, пошел смотреть! :)
                0

                Я сам очень ценю портабельность утилит на Go, но справедливости ради стоит отметить, что Borg тоже поставляется в статической линковке.

                  0
                  Добрый день! Главный принцип — установка из репозитория, так что подключаем EPEL и ставим через yum install… А если по каким-то причинам нету желания использовать версию из репозитория — наиболее крутые решения собирают свои бинарники статически.
                  +1

                  Хм. Две просьбы.


                  1. В старых статьях внесите, пожалуйста, ссылки на новые. Иначе не удобно ходить по циклу статей.
                  2. LVM snapshot? Не, отменили уже? Просто как вариант дешевого бекапа, причем универсального (в частности, когда речь идет про БД) — практически идеальное решение. Имеется в виду НЕ снапшот сам перегонять целиком, а использовать его для снимка "мгновенного" состояния ФС (с предварительным sync'ом БД), а потом уже оттуда можно выдирать нужные файлы, просто подмонтировав снапшот и класть в удаленное хранилище. И это точно будет дешевле чем Veeam или Altaro (кстати, не увидел в списке претендентов, а решение реально крутое для гипервизоров).
                    +1

                    У LVM снапов производительность все-таки оставляет желать лучшего. На thick provisioning перформанс и оригинала и снапа ухудшается просто катастрофически со временем, особенно под такими активными штуками, как БД. С thin provisioning все получше, но общая производительность (со снапом или без) тоже не фонтан. BTRFS… не будем о ней. ZFS on Linux — rock solid, не тормозит, хоть обснапшоться весь. Заодно никаких плясок с "монтированием и выдиранием файлов", zfs send/receive на бекап сервер.

                      0

                      ну, можно и альтернативные варианты вроде ZFS снапшотов...

                      0
                      Добрый день! Ссылочки добавили, спасибо!

                      Veeam будет в следующей статье, плюс идет оценка влияния процесса резервного копирования _без_ создания snapshot т.к. данные не изменяются в процессе резервного копирования для простоты и наглядности.
                      0

                      Стоит отметить, что у restic пока нет сжатия, но это, возможно, не такой и большой недостаток благодаря дедупликации. Все же, по сравнению с borg, поддержка кучи бекендов, в т.ч. бекап напрямую в облако, это огромный плюс.

                        0
                        Добрый день! Сжатие возможно и не актуально на нашем наборе данных (уже пожатые изображения и видео), а вот дедупликация реально решает. И еще — у Borg тоже есть куча бэкэндов, не такая большая, как у restic, но покрывает 90% существующих облаков. Ну, и zbackup можно скрестить с rclone и получить свой кастомный продукт :) Первый проход будет долгим, а дальше все будет достаточно быстро.
                          0

                          Скажите пожалуйста (может пропустил), какие бэкэнды есть у Borg кроме local FS и remote (over SSH)? Насколько я знаю, никакие облака, в т.ч. банальный S3/S3-compat/OpenStack Swift не поддерживаются напрямую. Да, можно репу синкать через rclone (долгой ему жизни). Но это значит, что ее надо держать локально. Иногда это не вариант, например на паре терабайт, для которых выделили ресурсы только в cloud/object storage, просто потому что он дешевле, чем NAS/SAN/block volumes.


                          zbackup сначала подкупил streaming backups, а потом я понял, что ему тоже надо постоянное хранилище локально. Мечталось, что ты ему передаешь затаренный поток, он его жмет+дедуплицирует на лету и отдает в stdout, который можно уже через rclone cat отдавать сразу в S3. Для архивного хранения самое оно. К сожалению, так оно не работает. В добавок zbackup еще и discontinued судя по всем (спасибо, что указали на это).

                            0
                            Да, Вы правы, локальный каталог и удаленный репо через ssh.
                              0

                              К слову, покопавшись в доках restic обнаружил, что zbackup вполне успешно можно заменить для streaming backups примерно так:


                              tar cf - data_dir | restic backup --stdin --stdin-filename data_dir.tar

                              Компрессию можно добавить в пайп по вкусу.

                        0

                        Спасибо за интересный материал!
                        В прошлом году озаботился поиском простой методики РК для веб-хостинга. Основные критерии:


                        1. Минимальный overhead.
                        2. Поддержка S3-хранилища.
                        3. Поддержка Google Drive ("облако" выбрал, исходя из цены и скорости).
                          Попробовал restic — столкнулся с проблемой при копировании файлов, расположенных на ftpfs (частный случай fuse). Плюс, при росте количества копий, столкнулся с заметным падением производительности при создании копии, но быть уверен в зависимости от объема не могу.
                          Выбрал для создания регулярных копий duplicacy. Пользуюсь с февраля 2018 года. Объемы заметно не растут, т.к. проект довольно статичный. Настроил retention, используя "заготовки" из Вики на github. В целом — всем доволен, сбоев не отмечал и смело могу рекомендовать.
                          На работе же администрирую HDPS Commvault — очень нравится, но вот только, конечно, не для дома.

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое