nAbdullin Jun 5 2019 at 12:44

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

7 min

19K

Слёрм corporate blogSystem administration*Server Administration*DevOps*

+26

Comments 20

fessmage Jun 5 2019 at 20:02

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

ruslantum Jun 6 2019 at 13:48

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

nAbdullin Jun 6 2019 at 14:20

Добрый день! Процесс резервного копирования — часть общего процесса, поэтому настоящие джедаи, для особенно критических с точки зрения доступности сервисов, делают PITR и соблюдают правило 3-2-1. Но эта задача весьма уверенно переходит в разряд с SLA, и если клиента предупредили, что раскатка с резервной копии будет сутки, и клиент согласился — все в порядке.

fessmage Jun 6 2019 at 14:27

Безусловно вы правы. Просто говорю о том чтобы не воспринимали как серебряную пулю. Тем более глядя на скорости создания резервной копии можно автоматически подумать что и достать ее можно будет также быстро. А потом оказывается что нет.
А тот же restic сам ценю и широко применяю.

UFO just landed and posted this here

texder Jun 5 2019 at 23:10

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

nAbdullin Jun 6 2019 at 13:59

Добрый день! В предыдущей статье он упоминался, но из-за того, что текущая методика тестирования не покрывает и 10% его возможностей — его обзор может быть будет в 6-й части цикла.

pansa Jun 6 2019 at 00:05

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

deklin Jun 6 2019 at 10:44

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

nAbdullin Jun 6 2019 at 14:01

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

gecube Jun 6 2019 at 09:18

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

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

deklin Jun 6 2019 at 10:51

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

gecube Jun 6 2019 at 13:06

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

nAbdullin Jun 6 2019 at 14:06

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

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

deklin Jun 6 2019 at 10:54

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

nAbdullin Jun 6 2019 at 14:09

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

deklin Jun 6 2019 at 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 Jun 6 2019 at 17:20

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

deklin Jun 7 2019 at 20:29

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

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

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

whitedruid Jun 7 2019 at 20:35

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

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