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

в 9:44, , рубрики: backup, borgbackup, devops, restic, testing, zbackup, Блог компании Southbridge, Серверное администрирование, системное администрирование

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

В данной статье будут рассматриваться программные средства для резервного копирования, которые путем разбиения потока данных на отдельные компоненты (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 была примерно четверть от времени):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Запуск 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Запуск 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, местами больше, местами меньше. Из особенностей — отсутствие возможности отключения шифрования, а следовательно, резервные копии будут зашифрованными всегда. Давайте посмотрим на практике, что можно выжать из этого ПО:

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

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

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

Запуск 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: Выводы

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

Автор: nAbdullin

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js