restic или BorgBackup: что выгоднее и когда

MAATRIX

Рано или поздно каждый, кто настраивает бэкапы вручную через rsync и cron, натыкается на вопрос: а зачем изобретать велосипед, если есть готовые инструменты с дедупликацией и шифрованием? Дальше выбор почти всегда сужается до двух имён — restic и BorgBackup. Оба зрелые, оба бесплатные, оба умеют инкрементальные снапшоты без боли. Разница в деталях, но именно эти детали определят, будете вы через год ругаться на медленный prune или спокойно спать, зная, что бэкап долетел до S3 в другом регионе.

Что у них общего

И restic, и BorgBackup решают одну и ту же задачу: делают content-defined chunking (нарезку файлов на куски переменной длины по содержимому, а не по фиксированному размеру), дедуплицируют эти куски внутри репозитория и шифруют всё на клиенте до отправки на сервер хранения. Оба инструмента:

• хранят историю как цепочку снапшотов, а не как набор полных копий;
• поддерживают инкрементальные бэкапы «из коробки» — второй и последующие запуски передают только изменённые куски;
• позволяют смонтировать репозиторий как файловую систему (FUSE) и просто скопировать нужный файл, не разворачивая весь бэкап;
• умеют политики хранения (retention) — «оставить 7 дневных, 4 недельных, 12 месячных»;
• шифруют данные AES-256, ключ знает только клиент, сервер хранения видит только зашифрованные блобы.

То есть на уровне «зачем вообще нужен такой инструмент» они взаимозаменяемы. Различия начинаются там, где вы выбираете, куда писать бэкап, сколько у вас оперативной памяти и как часто вам нужно восстанавливать один конкретный файл посреди ночи.

Архитектурные различия

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

BorgBackup использует собственный низкоуровневый формат, заточенный под работу через SSH с сервером, на котором тоже установлен Borg (или borg serve). Дедупликация в Borg исторически считается чуть агрессивнее за счёт более мелкой нарезки чанков и локального индекса, который Borg держит в памяти клиента — отсюда и растущий аппетит к RAM на больших репозиториях.

restic написан на Go, хранит данные в формате, который не привязан к конкретному серверному демону — на другом конце достаточно голого файлового хранилища, SFTP или объектного бакета. Repository lock и метаданные тоже лежат прямо в хранилище, поэтому клиенту не нужен постоянный процесс на стороне сервера. Это развязывает руки: можно бэкапиться сразу в S3-совместимое хранилище без прослойки в виде SSH-демона.

Из этого вытекает практическое следствие: Borg почти всегда требует SSH-доступ на приёмнике (или локальный/смонтированный путь), а restic одинаково легко работает и через SSH, и без него вовсе.

Бэкенды хранения: где на самом деле разница ощутима

Если вы храните бэкапы только на своём сервере или на соседнем VPS по SSH — оба инструмента справятся одинаково хорошо. Разница проявляется, когда хочется писать бэкап во внешнее объектное хранилище.

Если план — писать бэкапы в объектное хранилище напрямую, без танцев с rclone mount, restic выигрывает почти безоговорочно. Мы уже разбирали настройку rclone для бэкапов как универсальной прослойки — с restic она часто просто не нужна, инструмент сам умеет говорить на S3-протоколе.

Потребление ресурсов: память и CPU

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

• BorgBackup держит индекс чанков в памяти клиента при работе с репозиторием. На репозиториях с десятками миллионов объектов (много мелких файлов, долгая история) потребление памяти растёт заметно и может стать узким местом на VPS с 1–2 ГБ RAM. Мы отдельно смотрели, сколько RAM закладывать под restic — для Borg логика похожая, но пик обычно выше на сопоставимых объёмах.
• restic тоже держит индекс в памяти, но кэширует его на диске между запусками (~/.cache/restic), что снижает нагрузку на повторных бэкапах и делает поведение более предсказуемым на маленьких серверах.
• По CPU оба используют многопоточное сжатие и хеширование (Borg — zstd/lz4 по выбору, restic — zstd по умолчанию начиная с современных версий), разница на практике редко критична для типичного VPS с 2–4 vCPU.

Если сервер бэкапов — это отдельная маленькая машина на 1–2 ГБ памяти с большим количеством мелких файлов (например, почтовые ящики или CMS-аплоады), присмотритесь к restic или сразу берите план с запасом по RAM — так меньше риска, что prune или check упрутся в OOM killer.

Восстановление и повседневная эксплуатация

По UX оба инструмента близки, но есть нюансы, которые чувствуются именно в стрессовой ситуации — когда бэкап нужен «прямо сейчас».

# restic: посмотреть список снапшотов и смонтировать репозиторий
restic -r sftp:backup@storage:/repo snapshots
restic -r sftp:backup@storage:/repo mount /mnt/restic

# BorgBackup: то же самое
borg list ssh://backup@storage/./repo
borg mount ssh://backup@storage/./repo /mnt/borg

Оба поддерживают частичное восстановление конкретных путей без разворачивания всего снапшота, оба умеют check/verify для проверки целостности репозитория. Разница в мелочах: у restic более явные и предсказуемые сообщения об ошибках и структурированный JSON-вывод (--json), что удобно, если бэкап встроен в мониторинг через healthchecks.io. У Borg богаче встроенная статистика по дедупликации (borg info показывает точную экономию места по каждому архиву), что полезно, когда нужно объяснить руководству, почему инкрементальный бэкап весит в 50 раз меньше полного.

По скорости первого полного бэкапа и последующих инкрементов — оба показывают близкие результаты на одинаковом железе и сети; конкретные числа зависят от диска, сети и структуры данных настолько сильно, что любые «X ГБ/мин» из чужих бенчмарков переносить на свой сервер бессмысленно. Проверяйте на тестовом прогоне.

Когда выбрать restic, а когда BorgBackup

Сведём практический выбор в одну таблицу — по сценарию, а не по абстрактным «плюсам».

Если сомневаетесь — начните с restic: он проще разворачивается без выделенного сервера-приёмника, а к моменту, когда упрётесь в его ограничения, вы уже будете понимать свой профиль нагрузки достаточно, чтобы осознанно мигрировать на Borg (или наоборот).

Практическая настройка на VPS

Независимо от выбора, базовый чек-лист бэкапа на арендованном сервере выглядит так:

1. Отдельный пользователь с ограниченными правами для процесса бэкапа.
2. Ключ шифрования репозитория — хранить отдельно от сервера-источника (менеджер паролей, отдельный сейф).
3. Cron-задача с логированием и оповещением при ошибке — мы отдельно разбирали частые ошибки cron-задач на сервере, это применимо и к бэкапным скриптам.
4. Регулярный restic check / borg check — раз в неделю, не реже.
5. Тестовое восстановление хотя бы раз в квартал — бэкап, который никогда не восстанавливали, не бэкап, а надежда.

Пример минимального systemd-таймера для restic:

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Restic backup

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=s3:https://s3.example.com/my-backups
Environment=RESTIC_PASSWORD_FILE=/etc/restic/password
ExecStart=/usr/bin/restic backup /var/www /etc /home --exclude-caches
ExecStartPost=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

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

Частые вопросы