В данной статье будут рассматриваться программные средства для резервного копирования, которые путем разбиения потока данных на отдельные компоненты (chunks), формируют репозиторий.
Компоненты репозитория могут дополнительно сжиматься и шифроваться, а самое главное — при повторных процессах резервного копирования — переиспользоваться повторно.
Резервная копия в подобном репозитории — именованная цепочка связанных друг с другом компонентов, например, на основе различных hash-функций.
Есть несколько подобных решений, я остановлюсь на 3: zbackup, borgbackup и restic.
Ожидаемые результаты
Поскольку все претенденты так или иначе требуют создания репозитория, одним из важнейших факторов будет оценка размера репозитория. В идеальном случае его размер должен быть не более 13 гб согласно принятой методике, а то и меньше — при условии хорошей оптимизации.
Также крайне желательно иметь возможность создавать резервные копии файлов напрямую, без применения архиваторов типа tar, а также работу с ssh/sftp без дополнительных средств вроде rsync и sshfs.
Поведение при создании резервных копий:
- Размер репозитория будет равен размеру изменений, или меньше.
- Ожидается большая нагрузка на процессор при использовании сжатия и/или шифрования, а также вероятна достаточно большая нагрузка на сеть и дисковую подсистему, если процесс архивации и/или шифрования будет работать на сервере хранения резервных копий.
- Если повредить репозиторий — вероятна отложенная ошибка как при создании новых резервных копий, так и при попытке восстановления. Надо планировать дополнительные меры по обеспечению целостности репозитория или использовать встроенные средства проверки его целостности.
В качестве эталонного значения принята работа с tar, как это было показано в одной из прошлых статей.
Тестирование zbackup
Общий механизм работы zbackup заключается в том, что программа находит в потоке данных, подаваемом на входе, области, содержащие одинаковые данные, затем опционально их сжимает, шифрует, сохраняя каждую область только 1 раз.
Для дедупликации используется 64-битная кольцевая hash-функция со скользящим окном для побайтной проверки на совпадение с уже существующими блоками данных (подобному тому, как это реализовано в rsync).
Для сжатия применяется lzma и lzo в многопоточном исполнении, а для шифрования — aes. В последних версиях присутствует возможность в будущем удалять старые данные из репозитория.
Программа написана на C++ с минимальными зависимостями. Автор по всей видимости вдохновлялся unix-way, поэтому программа принимает данные на stdin при создании резервных копий, выдавая аналогичный поток данных в stdout при восстановлении. Таким образом, zbackup можно использовать как весьма неплохой "кирпичик" при написании собственных решений резервного копирования. Например, у автора статьи эта программа является основным средством резервного копирования для домашних машин примерно с 2014 года.
В качестве потока данных будет применяться обычный tar, если не сказано иначе.
Проверка работы выполнялась в 2 вариантах:
- создается репозиторий и запускается zbackup на сервере с исходными данными, потом содержимое репозитория передается на сервер хранения резервных копий.
- создается репозиторий на сервере хранения резервных копий, запускается 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: Выводы
Автор публикации: Павел Демкович
Комментарии (20)
glowingsword
05.06.2019 21:01+1Спасибо за интересный тест :) Когда выбирал для бэкапа домашней тачки решение, выбирал между borg и restic. Начал с borg, но хотелось поддержки rclone, а тогда её у него не было(не знаю, как сейчас), в результате попробовал и restic. Последний оказался очень похож на borg, но в отличии от первого полностью подходил под решение нужной мне задачи(бэкапы с шифрованием + поддержка облачных хранилищ) — в результате я стал юзать именно его.
texder
05.06.2019 23:10А вы не пробовали тестировать DAR (Disk ARchive)? Интересно было бы сравнение с тем же restic.
nAbdullin Автор
06.06.2019 13:59Добрый день! В предыдущей статье он упоминался, но из-за того, что текущая методика тестирования не покрывает и 10% его возможностей — его обзор может быть будет в 6-й части цикла.
pansa
06.06.2019 00:05Почему-то опущен большой плюс утилит на Go — что тул поставляется в виде одного бинарника, причем, с минимум зависимостей. Это значит, что внезапный апдейт python не поломает совместимость или запуск бэкапа в принципе. Что мне не надо беспокоится, что в системе будет нужная версия питончика. Установка и запуск borg даже на домашней убунте всё же вызывает некоторую боль.
P.S. Спасибо за restic, пошел смотреть! :)deklin
06.06.2019 10:44Я сам очень ценю портабельность утилит на Go, но справедливости ради стоит отметить, что Borg тоже поставляется в статической линковке.
nAbdullin Автор
06.06.2019 14:01Добрый день! Главный принцип — установка из репозитория, так что подключаем EPEL и ставим через yum install… А если по каким-то причинам нету желания использовать версию из репозитория — наиболее крутые решения собирают свои бинарники статически.
gecube
06.06.2019 09:18Хм. Две просьбы.
- В старых статьях внесите, пожалуйста, ссылки на новые. Иначе не удобно ходить по циклу статей.
- LVM snapshot? Не, отменили уже? Просто как вариант дешевого бекапа, причем универсального (в частности, когда речь идет про БД) — практически идеальное решение. Имеется в виду НЕ снапшот сам перегонять целиком, а использовать его для снимка "мгновенного" состояния ФС (с предварительным sync'ом БД), а потом уже оттуда можно выдирать нужные файлы, просто подмонтировав снапшот и класть в удаленное хранилище. И это точно будет дешевле чем Veeam или Altaro (кстати, не увидел в списке претендентов, а решение реально крутое для гипервизоров).
deklin
06.06.2019 10:51У LVM снапов производительность все-таки оставляет желать лучшего. На thick provisioning перформанс и оригинала и снапа ухудшается просто катастрофически со временем, особенно под такими активными штуками, как БД. С thin provisioning все получше, но общая производительность (со снапом или без) тоже не фонтан. BTRFS… не будем о ней. ZFS on Linux — rock solid, не тормозит, хоть обснапшоться весь. Заодно никаких плясок с "монтированием и выдиранием файлов", zfs send/receive на бекап сервер.
nAbdullin Автор
06.06.2019 14:06Добрый день! Ссылочки добавили, спасибо!
Veeam будет в следующей статье, плюс идет оценка влияния процесса резервного копирования _без_ создания snapshot т.к. данные не изменяются в процессе резервного копирования для простоты и наглядности.
deklin
06.06.2019 10:54Стоит отметить, что у restic пока нет сжатия, но это, возможно, не такой и большой недостаток благодаря дедупликации. Все же, по сравнению с borg, поддержка кучи бекендов, в т.ч. бекап напрямую в облако, это огромный плюс.
nAbdullin Автор
06.06.2019 14:09Добрый день! Сжатие возможно и не актуально на нашем наборе данных (уже пожатые изображения и видео), а вот дедупликация реально решает. И еще — у Borg тоже есть куча бэкэндов, не такая большая, как у restic, но покрывает 90% существующих облаков. Ну, и zbackup можно скрестить с rclone и получить свой кастомный продукт :) Первый проход будет долгим, а дальше все будет достаточно быстро.
deklin
06.06.2019 15:48Скажите пожалуйста (может пропустил), какие бэкэнды есть у 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 судя по всем (спасибо, что указали на это).nAbdullin Автор
06.06.2019 17:20Да, Вы правы, локальный каталог и удаленный репо через ssh.
deklin
07.06.2019 20:29К слову, покопавшись в доках
resticобнаружил, чтоzbackupвполне успешно можно заменить для streaming backups примерно так:
tar cf - data_dir | restic backup --stdin --stdin-filename data_dir.tar
Компрессию можно добавить в пайп по вкусу.
whitedruid
07.06.2019 20:35Спасибо за интересный материал!
В прошлом году озаботился поиском простой методики РК для веб-хостинга. Основные критерии:
- Минимальный overhead.
- Поддержка S3-хранилища.
- Поддержка Google Drive ("облако" выбрал, исходя из цены и скорости).
Попробовал restic — столкнулся с проблемой при копировании файлов, расположенных на ftpfs (частный случай fuse). Плюс, при росте количества копий, столкнулся с заметным падением производительности при создании копии, но быть уверен в зависимости от объема не могу.
Выбрал для создания регулярных копий duplicacy. Пользуюсь с февраля 2018 года. Объемы заметно не растут, т.к. проект довольно статичный. Настроил retention, используя "заготовки" из Вики на github. В целом — всем доволен, сбоев не отмечал и смело могу рекомендовать.
На работе же администрирую HDPS Commvault — очень нравится, но вот только, конечно, не для дома.
fessmage
Минус подобных решений — низкая скорость восстановления данных из бекапа. Говорю на примере restic, но подозреваю что у других тоже. Доставать данные из снапшота достаточно долго, монтировать снапшот в фс — еще дольше. Так что низкий MTTR — мимо.
Kylin
не знаю насчет restic, наши девопсы им пользуются, лично для себя выбрал давно borgbackup из-за поддержки hetzner backup из коробки, восстановление снапшота при наличии локального репозтория мгновенно: borg mount repo::backup /path/to/mount потом можно сразу начинать rsync
nAbdullin Автор
Добрый день! Процесс резервного копирования — часть общего процесса, поэтому настоящие джедаи, для особенно критических с точки зрения доступности сервисов, делают PITR и соблюдают правило 3-2-1. Но эта задача весьма уверенно переходит в разряд с SLA, и если клиента предупредили, что раскатка с резервной копии будет сутки, и клиент согласился — все в порядке.
fessmage
Безусловно вы правы. Просто говорю о том чтобы не воспринимали как серебряную пулю. Тем более глядя на скорости создания резервной копии можно автоматически подумать что и достать ее можно будет также быстро. А потом оказывается что нет.
А тот же restic сам ценю и широко применяю.