Borg vs Restic: что выбрать для бэкапов на VDS

Если у вас на VDS уже живут приложения и базы, раньше или позже встанет вопрос: на чём строить backup? В мире CLI-утилит два самых частых варианта — Borg и Restic. Оба дают дедупликацию (deduplication), шифрование (encryption) и инкрементальные снимки, но философия, форматы repository и поведение под разными нагрузками отличаются. Ниже — структурированное сравнение для админов и девопсов, с упором на практику на одиночных и небольших кластерах VDS.

Коротко: в чём суть выборов

Если очень упрощать: Borg традиционно силён на локальных дисках и по SSH, с мощной встроенной компрессией и проверенным временем форматом. Restic — кросс-бэкендовый (включая S3-совместимые хранилища), прост в развертывании, отлично параллелит сетевые загрузки и часто удобнее в мультиплатформе.

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

Архитектура и философия

Borg

Borg делает ставку на локальные и SSH-репозитории, использует контент-определяемое разбиение файлов на блоки (переменный размер чанков) и агрессивно экономит место за счёт эффективной дедупликации и сжатия. Концептуально это «файловая» модель: архивы выглядят как логические снимки, легко монтируются через FUSE, а репозиторий хранит сегменты, индексы и ключи шифрования. Для удалённого доступа есть режим borg serve и строгие ограничения через authorized_keys.

Restic

Restic — «контент-адресное» хранилище объектов со снапшотами, к которым легко обращаться, и широким спектром бэкендов: локальный диск, SFTP, а также объектные хранилища (S3-совместимые, крупные облака). Он написан с прицелом на переносимость, прост в установке на большинстве Linux-дистрибутивов и охотно распараллеливает сетевые операции. Это особенно важно, если ваш repository — удалённый объектный стор.

Репозитории и дедупликация

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

• Borg хранит сегменты и индексы, поддерживает режим «append-only» как защиту от случайного/злоумышленного удаления новых данных, а также полноценную проверку borg check и восстановление индексов.
• Restic складывает блоки в pack-файлы, поддерживает репаковку и restic prune, умеет restic rebuild-index при необходимости. Упор сделан на простоту и кросс-бэкендовость (подробнее см. разбор бэкапов в объектные сторы в статье бэкапы в S3 с Restic и Borg).

На практике по локальному диску и SSH Borg часто показывает очень высокую эффективность по месту и скорости, особенно на наборах «много мелких файлов». Restic выигрывает гибкостью бэкендов и параллельными выгрузками, что заметно при удалённом repository в объектном хранилище.

Шифрование и доверие к среде

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

Практические правила:

• Ставьте сильный пароль и храните его офлайн-копию.
• Разделите материал ключей и место, где лежит репозиторий.
• Используйте отдельного системного пользователя без root, минимум прав по SSH.
• Для Borg с borg serve задавайте ограничение командой в authorized_keys и отключайте интерактивный shell.

Компрессия и экономия места

Borg давно умеет встроенную компрессию (zstd, lz4, lzma), что даёт существенный выигрыш на текстах, логах, SQL-дампах. Restic исторически делал ставку на дедупликацию и переносимость; в свежих версиях поддерживает компрессию, и на многих наборах данных вы тоже получите заметное сокращение занимаемого объёма. Выбор алгоритма зависит от баланса CPU/IO: на слабых VDS разумно стартовать с zstd со средним уровнем.

Производительность: практика на VDS

Слово performance для бэкапов обычно распадается на четыре аспекта: скорость первого полного бэкапа, скорость инкрементов, скорость восстановления и системная нагрузка (CPU, RAM, IO):

• Первый прогон будет CPU-интенсивным из‑за чтения и chunking. На 1–2 vCPU и NVMe это может занять часы при сотнях гигабайт и миллионах файлов — это нормально.
• Инкременты после первой базы обычно быстры: считываются только изменённые чанки, пересылается малый объём.
• Восстановление «многих мелких файлов» часто быстрее у Borg из‑за особенностей упаковки и FUSE-монтажа; у Restic это зависит от распределения по pack-файлам и от того, локально ли репозиторий.
• Сетевые бэкенды: Restic обычно эффективнее нагружает канал за счёт параллелизма. Borg по SSH устойчив и предсказуем, особенно между двумя VDS в одном регионе.

Наблюдаемые эффекты на малых/средних VDS:

• «Много мелочи» (CMS, ассеты, vendor): Borg нередко чуть быстрее и экономичнее по диску.
• «Крупные файлы» (образы, медиа): обе утилиты близки, Restic удобнее, если хранение — S3‑совместимое.
• «Сетевой бэкап на объектку»: Restic ощущается быстрее благодаря конкурентным загрузкам.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Восстановление и сценарии аварий

Оба инструмента поддерживают FUSE-монтирование снапшота и точечное восстановление файлов и директорий. Это удобно для быстрых проверок и экстренных случаев.

• Borg: borg mount монтирует архив, далее можно выбирать отдельные файлы и копировать их командой cp или rsync.
• Restic: restic mount создаёт древо снапшотов по хостам, датам и тегам; можно вытащить одиночный файл без полного восстановления.

Важно регулярно делать check и prune, а также тестировать восстановление на «песочнице». Частая ошибка — годами копить бэкапы и ни разу не пробовать restore: в аварии проявляются забытые пароли, исчерпанные inode, нехватка свободного места, сломанные пути и т. п.

Эксплуатация на VDS: надёжный контур

Набор практик, который отлично приживается на типичном VDS:

• Разнести бэкап-хранилище и боевой сервер хотя бы по разным хостам/ЦОД.
• Если используете локальный диск как «промежуточный буфер», не забывайте выгружать «внешнюю» копию.
• Назначить окна времени, ограничить ресурсы nice и ionice, чтобы не мешать вечерним пикам трафика.
• Сделать systemd unit и timer, плюс healthcheck с алертом — чтобы замечать отвалившиеся ключи, переполненные репозитории и истёкшие пароли.
• Хранить офлайн-материал ключей и документировать процедуру «как расшифровать и восстановить», включая контакты ответственных.

Примеры команд: быстрый старт

Установка

# Debian/Ubuntu
apt update
apt install borgbackup
apt install restic

# CentOS/Rocky/Alma
yum install borgbackup
yum install restic

Borg: инициализация, бэкап, ротация

# Инициализация репозитория (локально или по SSH)
export BORG_PASSPHRASE="strong-pass"
borg init --encryption=repokey-blake2 /backup/borg-repo
# или
borg init --encryption=repokey-blake2 user@backup-host:/srv/borg/repo

# Первый бэкап каталога /var/www
borg create --stats --progress /backup/borg-repo::www-$(date +%Y-%m-%d) /var/www --exclude-caches --exclude "*.tmp" --compression zstd,6

# Список архивов
borg list /backup/borg-repo

# Ротация и удаление старых
borg prune -v --list /backup/borg-repo --keep-daily=7 --keep-weekly=4 --keep-monthly=6

# Проверка
borg check /backup/borg-repo

# Восстановление
borg extract /backup/borg-repo::www-2025-01-01 var/www/site

Restic: инициализация, бэкап, ротация

# Переменные окружения для простоты
export RESTIC_PASSWORD="strong-pass"
export RESTIC_REPOSITORY="sftp:user@backup-host:/srv/restic/repo"
# или S3-совместимое хранилище
# export RESTIC_REPOSITORY="s3:s3.amazonaws.com/bucket/name"
# export AWS_ACCESS_KEY_ID=...
# export AWS_SECRET_ACCESS_KEY=...

# Инициализация
restic init

# Первый бэкап
restic backup /var/www --exclude-caches --exclude "*.tmp"

# Список снапшотов
restic snapshots

# Ротация
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

# Проверка
restic check

# Восстановление каталога
restic restore latest --target /restore --path "/var/www/site"

Репликация и оффсайт

Типовой контур: делать локально быстрый бэкап на дополнительный диск VDS, а затем реплицировать его во внешний репозиторий. Для Restic это просто выбор другого бэкенда и повторный запуск. Для Borg — поднять удалённый borg serve на «холодном» сервере и выгружать туда копию. Главное — периодически проверять целостность обоих репозиториев. Для SSH-пайплайнов пригодится наш материал rsync и SSH: деплой и бэкапы.

Исключения, теги, структурирование

Список исключений — ваша лучшая экономия CPU и IO. Исключайте node_modules и мимо-грузящиеся артефакты сборки, если они воспроизводимы. Отдельно бэкапьте базы консистентно: снимайте дампы (или делайте snapshot на уровне файловой системы, если у вас LVM/ZFS) и только их складывайте в бэкап-дерево.

Используйте теги/префиксы именования архивов: это помогает быстро фильтровать снимки по проектам и ролям серверов.

Обслуживание: prune, check, reindex

Не экономьте на обслуживании репозитория:

• Borg: borg prune по расписанию, периодический borg compact при необходимости, borg check --verify-data раз в месяц в «тихие часы».
• Restic: restic forget --prune регулярно, restic check по расписанию, restic rebuild-index при подозрениях на рассинхронизацию индексов.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Безопасность SSH и ограничение прав

Для Borg по SSH добавляйте ключ с ограничением запуска в authorized_keys у сервера-хранилища (только borg serve), запрещайте туннели и форварды, отключайте pty. Для Restic по SFTP — отдельный юзер и chroot, ключи только на чтение/запись нужных путей. В обоих случаях убедитесь, что компрометация боевого сервера не позволяет удалять старые снимки: режим append-only и строгие политики помогают.

Диагностика и типичные проблемы

• «Медленно бегает первый бэкап»: это нормально. Сведите в ноль лог-файлы, большие кеши браузеров и артефакты сборки. Установите разумную компрессию (например, zstd среднего уровня).
• «Не хватает RAM»: уменьшите параллелизм для Restic, для Borg не повышайте уровень компрессии сверх меры. Следите за размером page cache.
• «Прервалась сеть»: оба инструмента достаточно устойчивы. Перезапустите, они догрызут с места остановки. При частых обрывах снизьте параллелизм и увеличьте таймауты SSH/S3-клиента.
• «Репозиторий раздулся»: проверьте политику хранения, запустите prune, для Restic — при необходимости repack (входит в prune), для Borg — compact.
• «Не удаётся восстановить файл из старого снапшота»: проверьте ключи и пароль, затем смонтируйте снапшот через FUSE и скопируйте вручную.

Миграция Borg ↔ Restic

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

Что выбрать: краткий чек-лист

• Храните в объектном хранилище, важна простая мультиоблачность, хотите гибкую работу по сети и параллелизм — берите Restic.
• Фокус на локальном/SSH, много мелких файлов, нужна сильная встроенная компрессия и быстрая навигация по архивам — берите Borg.
• Смешанный сценарий? Используйте оба: быстрый локальный Borg для ежедневных точек и Restic в объектку для оффсайта.

Резюме

И Borg, и Restic — зрелые и надёжные инструменты с полноценной deduplication, encryption и хорошим performance при корректной настройке. Выбор чаще диктуется инфраструктурой и точкой хранения repository. Для VDS я бы предложил простую стратегию: локальный ежедневный снимок для быстрых откатов и удалённый оффсайт в другой ЦОД; регулярный check и тестовые восстановления; документированную процедуру аварийного доступа к ключам. Тогда вне зависимости от того, что вы выберете — Borg или Restic — ваши бэкапы действительно будут работать, а не просто занимать место.