Pull to refresh

Comments 20

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

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

Добрый день! Процесс резервного копирования — часть общего процесса, поэтому настоящие джедаи, для особенно критических с точки зрения доступности сервисов, делают PITR и соблюдают правило 3-2-1. Но эта задача весьма уверенно переходит в разряд с SLA, и если клиента предупредили, что раскатка с резервной копии будет сутки, и клиент согласился — все в порядке.
Безусловно вы правы. Просто говорю о том чтобы не воспринимали как серебряную пулю. Тем более глядя на скорости создания резервной копии можно автоматически подумать что и достать ее можно будет также быстро. А потом оказывается что нет.
А тот же restic сам ценю и широко применяю.
UFO just landed and posted this here

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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


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