Restic против Borg: выбор инструмента бэкапа

Restic и Borg решают одну задачу — дедуплицированный, зашифрованный бэкап с историей версий, — но исходят из разных предпосылок. Borg появился как проект про эффективное хранение и требует доверенного сервера с установленным borg. Restic писался под облачные хранилища: он работает поверх «тупого» объектного хранилища и не нуждается в агенте на другой стороне. Выбор между ними — это выбор не «что быстрее», а какая модель эксплуатации вам ближе.

Архитектура репозитория

Репозиторий Borg — это каталог с сегментами, индексом и транзакционным журналом. Клиент и сервер общаются по SSH и запускают borg serve; большая часть работы выполняется на клиенте, но сервер должен иметь borg совместимой версии. Плюс — можно включить --append-only на стороне сервера и защититься от удаления бэкапов при компрометации клиента.

Репозиторий restic — набор каталогов data, index, keys, snapshots и файла config. Он не требует серверной логики: подойдёт S3, Backblaze B2, Azure, REST-сервер, SFTP или локальный диск. Это же свойство означает, что все операции, включая prune, выполняются на клиенте и гоняют по сети метаданные.

borg info /mnt/backup/repo
restic cat config --repo /mnt/backup/restic

Как режется поток данных

Оба инструмента используют дедупликацию по содержимому, но разные алгоритмы. Borg режет поток скользящим хэшем buzhash на блоки со средним размером около 2 МиБ; параметры чанкера должны совпадать между запусками, иначе дедупликация перестанет находить общие блоки. Restic использует Rabin fingerprint и средний размер около 1 МиБ, упаковывая блоки в паки примерно по 16 МиБ. Для практики важно одно: сдвиг файла на несколько байт не ломает дедупликацию ни там, ни там, потому что границы блоков определяются содержимым.

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

Шифрование и ключи

Borg шифрует данные AES-256 в режиме CTR и аутентифицирует HMAC-SHA256 (в варианте repokey-blake2 — BLAKE2b). Ключ хранится либо в репозитории в зашифрованном виде (repokey), либо в домашнем каталоге (keyfile). Потеря ключа означает потерю архива, поэтому экспорт ключа — обязательный шаг, а не рекомендация.

Restic использует AES-256-CTR с аутентификацией Poly1305-AES и мастер-ключ, зашифрованный паролем через scrypt. Ключи лежат в каталоге keys репозитория, пароль передаётся через переменную окружения, файл или команду. Обе схемы надёжны при длинном пароле; разница в том, что borg позволяет хранить ключ отдельно от репозитория, а restic — нет.

Сжатие

Borg сжимает каждый блок отдельно и поддерживает lz4, zlib, zstd и lzma. Для повседневных бэкапов разумен zstd,8: он заметно быстрее lzma и почти не проигрывает на тексте. Restic включает сжатие автоматически начиная с версии 0.14 и тоже использует zstd; режим max стоит включать только там, где важнее размер, а не время.

Сжатие не мешает дедупликации: блоки сначала режутся, потом сжимаются. Но при смене алгоритма старые данные не пересжимаются, поэтому экономия проявится только на новых снапшотах.

Ротация и стоимость prune

Удаление старых копий — самая дорогая операция в обеих системах. Borg сначала помечает архивы, а затем требует borg compact, чтобы переписать сегменты и вернуть место. Restic совмещает удаление и перепаковку в forget --prune; флаг --max-repack-size ограничивает объём работы за один запуск.

borg init --encryption=repokey-blake2 /mnt/backup/repo
borg create --stats --compression zstd,8 /mnt/backup/repo::{now:%Y-%m-%d} /home /etc
borg prune --list --keep-daily 7 --keep-weekly 4 --keep-monthly 6 /mnt/backup/repo
borg compact /mnt/backup/repo

restic init --repo /mnt/backup/restic
restic backup --exclude-file=/etc/restic/excludes.txt /home /etc
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=5%

Оба процесса требуют эксклюзивной блокировки. В Borg это файл lock.exclusive; после аварийного завершения может остаться устаревшая блокировка, и её снимают командой borg break-lock, предварительно убедившись, что процесс действительно не работает. В restic блокировки лежат в каталоге locks, снимаются через restic unlock, а для чтения с носителя только для чтения есть --no-lock.

Планируйте prune отдельно от создания копий: и Borg, и restic на время перепаковки держат эксклюзивную блокировку, а интенсивный ввод-вывод замедляет остальные операции. Разумная схема — ежечасные снапшоты, ежедневное удаление по политике и еженедельная проверка части данных. Политику хранения задавайте не «на глаз», а от требований: сколько дней истории реально нужно для отката.

du -sh ~/.cache/borg ~/.cache/restic
restic stats --mode raw-data

Проверка и восстановление

Правило простое: бэкап без проверки — это надежда. Borg проверяет структуру командой borg check, а --verify-data дополнительно расшифровывает и сверяет контрольные суммы всех блоков. Restic делает то же через restic check, а --read-data-subset=10% позволяет проверять часть данных еженедельно, не читая весь репозиторий.

borg check --verify-data /mnt/backup/repo
borg list /mnt/backup/repo
borg extract --dry-run /mnt/backup/repo::2026-11-01 home/user/docs
restic restore latest --target /tmp/restore --path /home/user/docs

Для точечного восстановления удобны borg extract с путём и restic restore --include или restic dump для одного файла. Оба умеют монтировать снапшоты через FUSE, но для регулярной работы это скорее аварийный режим: монтирование большого репозитория требует времени и памяти.

Что выбрать

• Есть свой сервер по SSH и нужен минимальный трафик — Borg: дедупликация и сжатие на клиенте, append-only на сервере.
• Нужны S3, B2 или несколько площадок без агента — restic: один бинарник и объектное хранилище.
• Важна частая история версий и быстрый откат — restic с ежечасными снапшотами, а prune отдельным расписанием.
• Критичен размер репозитория и скорость на текстовых данных — Borg с zstd обычно экономичнее.
• Нужен бэкап с Windows или macOS в тот же репозиторий — restic проще, у borg меньше портативных сборок.

Итог

Restic и Borg не конкуренты «до победного», а инструменты под разные инфраструктуры. Borg выигрывает там, где есть свой сервер и хочется контролировать каждую операцию, включая append-only. Restic — там, где бэкап должен лежать в объектном хранилище и запускаться одним бинарником без зависимостей. В любом случае проверяйте восстановление, храните пароль и ключ отдельно от репозитория и не запускайте prune одновременно с созданием снапшота.