Restic или BorgBackup: что выбрать для бэкапа

Restic и BorgBackup: сравнение в одном абзаце

Restic и BorgBackup выполняют одну и ту же основную задачу: создают дедуплицированные, зашифрованные инкрементальные резервные копии Linux-сервера. Ключевое различие связано с местом хранения резервной копии. Restic изначально поддерживает S3 и другие API объектного хранилища, поэтому bucket является полноценным целевым хранилищем, и на удалённой стороне ничего устанавливать не нужно. Для стабильной версии Borg на машине, где хранится репозиторий, должна быть установлена программа borg, потому что репозиторий Borg обслуживается процессом, а не файловой системой или API. Если целевое хранилище — объектное хранилище, выбор уже очевиден. Если целевая система — второй Linux-компьютер, которым вы управляете, можно использовать Borg, который часто работает быстрее.

Остальные различия менее существенны. Обе программы разбивают файлы на фрагменты с разбиением по содержимому, поэтому при изменении 40 GB каталога на 200 MB будет передано примерно 200 MB. Обе шифруют данные на клиенте. Обе подключают snapshot через FUSE (filesystem in userspace), чтобы вы могли скопировать отдельный файл. По состоянию на October 2026 версия restic — 0.19.1, а стабильная ветка Borg — 1.4, текущая версия — 1.4.5. Borg 2.0 уже несколько лет находится в beta и по-прежнему помечен как предназначенный только для тестирования, поэтому сегодня следует разворачивать версию 1.4.

Модель репозитория — главное различие

Репозиторий restic представляет собой каталог файлов: config, keys/, snapshots/, index/ и data/, заполненный pack-файлами. Для его чтения больше ничего не требуется. Поэтому restic поддерживает так много backend. Репозиторий restic можно хранить в любом хранилище, которое умеет записывать, получать, перечислять и удалять blob-объекты. Так один бинарный файл поддерживает локальные пути, SFTP, собственный REST-сервер, S3, Backblaze B2, Azure, Google Cloud Storage и любые хранилища, доступные через rclone.

Репозиторий Borg также состоит из файлов на диске, но Borg не работает с ним через простой транспорт. Для удалённого репозитория Borg запускает borg serve на удалённой стороне через SSH и использует собственный протокол для взаимодействия с этим процессом. Серверная часть выполняет реальную работу: хранит репозиторий, применяет транзакции и отвечает на запросы к индексам. Поэтому в стабильной серии Borg 1.4 нет backend для S3. В bucket нельзя запустить необходимый процесс. Borg 2 меняет эту модель: он переносит хранение в новый слой под названием borgstore, а в документации описаны URL репозиториев sftp://, rclone:remote:path и s3: или b2:. Однако Borg 2 всё ещё находится в статусе beta, и проект не рекомендует использовать его в production. Поэтому для реального резервного копирования сегодня отсутствие S3 остаётся проблемой.

Именно этот факт архитектуры определяет большинство практических различий ниже.

# restic: the repository is a URL, and the backend is part of it
restic -r /srv/restic-repo init
restic -r sftp:backup@198.51.100.20:/srv/restic-repo init
restic -r s3:s3.us-east-1.amazonaws.com/my-backup-bucket init

# borg: a local path, or user@host:path, with borg installed on that host
borg init --encryption=repokey-blake2 /srv/borg/vps1
borg init --encryption=repokey-blake2 backup@198.51.100.20:/srv/borg/vps1

Шифрование: один из вариантов можно отключить

Restic всегда использует шифрование. Режима без шифрования не существует. restic init запрашивает пароль, генерирует на его основе ключ с помощью scrypt, после чего каждый записанный pack-файл шифруется и проходит проверку подлинности. Если вы потеряете пароль, данные будут утрачены безвозвратно, так как механизм восстановления не предусмотрен архитектурой.

Borg позволяет выбрать режим шифрования при создании репозитория, и этот выбор является окончательным. borg init --encryption=repokey хранит зашифрованный ключ внутри репозитория, поэтому для восстановления достаточно одной кодовой фразы. --encryption=keyfile хранит ключ на клиенте в ~/.config/borg/keys/, поэтому злоумышленник, получивший доступ к репозиторию, не сможет прочитать данные. В этом случае вы обязаны создавать резервную копию файла ключа отдельно, иначе архивы станут нечитаемыми. Для каждого режима существует вариант -blake2, который использует для аутентификации BLAKE2b вместо HMAC-SHA256; это работает быстрее на оборудовании без аппаратного ускорения SHA. Также существует --encryption=none, который является оправданным выбором, если репозиторий размещен на диске с собственным шифрованием.

Практическое правило: используйте repokey-blake2 для обычного резервного копирования сервера, keyfile — если репозиторий находится в месте, которому вы не доверяете полностью, и никогда не используйте none на арендованном оборудовании.

Сжатие и почему в restic оно появилось поздно

Borg поддерживает сжатие с самого начала. По умолчанию используется lz4, поскольку этот режим достаточно быстр, чтобы включать его для всех данных. zstd поддерживает уровни от 1 до 22 и по умолчанию использует уровень 3, а zlib и lzma предназначены для случаев, когда размер важнее времени выполнения. auto применяет эвристику к каждому фрагменту, поэтому уже сжатые данные не сжимаются повторно.

borg create --compression zstd,3 --stats --progress \
  /srv/borg/vps1::'{hostname}-{now}' /etc /home /srv

В restic сжатие отсутствовало до появления формата репозитория 2, для которого требуется restic версии 0.14.0 или новее. Сейчас формат 2 используется по умолчанию для нового репозитория, а сжатие задаётся с помощью --compression одним из пяти значений: auto (по умолчанию), off, fastest, better или max. Режимы fastest и better появились в restic 0.19.0, поэтому старые бинарные файлы принимают только auto, off и max. Старый репозиторий формата 1 остаётся без сжатия, пока вы не выполните его миграцию. Поэтому если ваш репозиторий restic создан до версии 0.14 и вы не выполняли миграцию, для текста, журналов и дампов баз данных по-прежнему требуется полный объём.

Удаленные цели: S3 против SSH

Здесь обычно и происходит выбор.

Для работы restic с S3 требуются только учетные данные в переменных окружения, больше ничего на стороне сервера не нужно. Тот же подход работает с бакетами, которые вы хостите самостоятельно; это распространенная связка: запустите MinIO для S3 API на собственном VPS и укажите на него restic.

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export RESTIC_REPOSITORY=s3:https://objects.example.com/backups
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /home /srv --exclude-caches

Для работы Borg с удаленным репозиторием требуются SSH и установленный Borg на удаленной стороне; при этом важно, чтобы версия на сервере была совместима с клиентской. Это создает неудобства, если удаленная сторона вам не принадлежит. Если же это второй сервер, которым вы уже управляете, проблем нет, и вы получаете самый надежный механизм защиты от программ-вымогателей, который предлагают оба инструмента: SSH-ключ с доступом только на добавление (append only). Настройте ключ на выполнение borg serve, и клиент сможет добавлять архивы, но не сможет их удалять. Таким образом, взломанная машина не сможет стереть свою историю резервных копий.

command="borg serve --append-only --restrict-to-path /srv/borg/vps1",restrict ssh-ed25519 AAAA...

У restic есть аналогичный функционал, только если вы запускаете его собственный REST server, который поддерживает режим append only. При работе с обычным S3 того же эффекта можно добиться с помощью политик бакета или object lock — это задача провайдера, а не restic. Ограничьте и сам транспорт, так как SSH-соединение требует такой же защиты, как и любой другой вход в систему: примените SSH-доступ только по ключам с ограничением в authorized_keys для учетной записи, используемой для резервного копирования.

Скорость: что подразумевает каждый подход

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

Borg через SSH работает быстро на каналах с задержкой, так как серверная часть обладает «интеллектом». Клиент задает вопрос, удаленный процесс borg serve отвечает на него, используя индекс репозитория, и транзакция фиксируется в одном месте. Поиск чанков не превращается в сетевые round-trip запросы для каждого маленького файла.

Restic при работе с объектным хранилищем не имеет серверной части, поэтому он должен формировать общую картину на основе индексных файлов и файлов пакетов (pack files), которые он загружает по HTTP. Чтобы количество запросов оставалось разумным, он упаковывает множество мелких чанков в более крупные файлы перед отправкой и хранит локальный кэш в ~/.cache/restic, чтобы при следующем запуске не загружать индекс заново. Удалите этот кэш, и следующее резервное копирование будет медленным, пока он не перестроится. На канале с высокой задержкой и миллионами мелких файлов restic будет ощущаться медленнее, чем Borg при работе с теми же данными.

При работе с локальным диском или быстрой локальной сетью разница практически нивелируется, и оба инструмента упираются в скорость чтения и хеширования исходных данных.

Блокировки и резервное копирование нескольких машин

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

Restic позволяет нескольким клиентам одновременно выполнять резервное копирование в один репозиторий, так как процесс резервного копирования использует разделяемую блокировку, а монопольная требуется только для операций обслуживания, таких как prune. Десять похожих серверов, направленных в один репозиторий restic, выполняют дедупликацию относительно друг друга, поэтому второй и последующие серверы часто занимают очень мало места. Обратной стороной является радиус поражения: один пароль и один репозиторий содержат все данные, поэтому потеря пароля приводит к потере данных со всех десяти машин.

Retention: forget и prune против prune и compact

Оба инструмента разделяют процессы «решения о том, что сохранить» и «освобождения места», при этом выполнение второго этапа ложится на пользователя.

restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune
restic check

borg prune --list --glob-archives '{hostname}-*' \
  --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /srv/borg/vps1
borg compact /srv/borg/vps1

Ловушка в обоих инструментах одинакова, и её стоит обозначить прямо. В Borg команда borg prune удаляет архивы, но сама по себе не освобождает место на диске. Место возвращается только после запуска borg compact, поэтому cron-задача, которая выполняет очистку (prune), но никогда не выполняет сжатие (compact), приведет к бесконечному росту репозитория при коротком списке архивов. В restic команда forget без --prune лишь удаляет ссылки на снимки (snapshots), а данные остаются до тех пор, пока не будет запущен prune.

После очистки запускайте restic check. Эта команда проверяет структуру репозитория и сообщает о возможных повреждениях, что гораздо лучше, чем обнаружить проблему непосредственно во время восстановления данных.

Восстановление — единственный тест, который имеет значение

Оба инструмента позволяют смонтировать снапшот для просмотра содержимого. Это самый быстрый способ извлечь один конкретный файл.

restic snapshots
restic restore latest --target /tmp/restore --include /etc/nginx
restic mount /mnt/restore

borg list /srv/borg/vps1
borg extract --list /srv/borg/vps1::vps1-2026-07-30T02:00:00 etc/nginx
borg mount /srv/borg/vps1::vps1-2026-07-30T02:00:00 /mnt/restore

Обратите внимание на формат пути в borg extract. Пути внутри архива хранятся без ведущего слэша, поэтому etc/nginx — это верный вариант, а /etc/nginx ничего не находит и не извлекает, не выдавая при этом ошибки. Процесс извлечения записывает данные в текущую рабочую директорию, поэтому сначала перейдите во временную папку, иначе вы перезапишете актуальные файлы старыми версиями.

Восстановление, завершившееся без ошибок, еще не является доказательством успеха, так как приложение может иметь свои критерии полноты данных: сервер Immich, восстановленный из копии директории данных Postgres, запустится со всеми файлами на диске, но пустой временной шкалой. Это именно та проблема, которую необходимо учитывать при резервном копировании и восстановлении Immich.

Какой бы инструмент вы ни выбрали, расписание — это лишь половина дела. Запускайте восстановление во временную директорию по расписанию, за которым вы действительно следите, как это сделано в полном руководстве по резервному копированию restic для VPS с использованием таймера systemd.

Что и когда выбрать

Выбирайте restic, если в качестве хранилища используется object storage, если вам нужен один исполняемый файл без установки дополнительного ПО на удаленной стороне, если несколько машин должны выполнять дедупликацию в общее хранилище или если восстановлением данных будет заниматься кто-то другой. Это единственный статический бинарный файл, которому для работы нужен только URL репозитория, и с точки зрения эксплуатации это решение сложно превзойти.

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

Оба варианта являются верными. Неверный вариант — это тот, который вы никогда не тестируете. Если вы уже делаете дампы на уровне приложений, продолжайте это делать: подход, описанный в настройке Nextcloud в Docker с дампами базы данных, применим к любому из этих инструментов, так как файл «живой» базы данных, скопированный в случайный момент времени, не является резервной копией базы данных.

FAQ

Работа restic и BorgBackup: какой инструмент быстрее?

На локальном диске или в быстрой LAN-сети они работают примерно одинаково. В обоих случаях производительность в итоге ограничивают скорость чтения и вычисления хешей на источнике. Borg обычно работает быстрее через SSH-соединение с высокой задержкой и очень большим количеством небольших файлов, потому что процесс borg serve на удалённой стороне отвечает на запросы к индексу без отдельного сетевого обмена для каждого чанка. Restic обычно работает быстрее при использовании object storage, с которым стабильная версия Borg вообще не работает.

Может ли BorgBackup сохранять резервные копии в S3 или Backblaze B2?

В стабильной серии 1.4 — нет. Репозиторий Borg 1.4 обслуживает процесс borg serve через SSH. Внутри bucket такой процесс не запускается. Borg 2 добавляет URL репозиториев s3:, b2: и rclone: через слой borgstore. Однако в октябре 2026 года Borg 2 всё ещё находится в статусе beta, и проект не рекомендует использовать его в production. В версии 1.4 эту проблему обходят, подключая object storage как файловую систему через rclone. FAQ Borg не рекомендует использовать network filesystem для хранения репозиториев и предупреждает, что FUSE и network filesystem могут привести к снижению производительности или повреждению данных. Если сегодня вам нужно использовать object storage для production backup, выберите restic.

Можно ли запускать оба инструмента для одних и тех же данных?

Да, некоторые так и делают: Borg — на второй сервер для быстрого локального восстановления, restic — в object storage для offsite-копии. Инструменты не используют общие данные, поэтому стоимость чтения и вычисления хешей оплачивается дважды. Кроме того, нужно безопасно хранить два пароля. Используйте такой вариант только после проверки восстановления обоими инструментами.

Что произойдёт, если я потеряю пароль от репозитория?

В обоих инструментах данные восстановить невозможно. Restic получает ключ из пароля с помощью scrypt, и обходного способа нет. В режиме repokey Borg хранит зашифрованный ключ внутри репозитория, поэтому для восстановления достаточно passphrase. В режиме keyfile дополнительно нужен файл ключа из ~/.config/borg/keys/. Храните пароль в password manager, который не находится на резервируемом сервере. Если используете keyfile, экспортируйте ключ Borg с помощью borg key export.

Нужно ли ждать Borg 2.0?

Нет. В октябре 2026 года Borg 2.0 всё ещё находится в статусе beta: текущая версия — 2.0.0b25, выпущенная 27 September 2026. Проект разрешает использовать её только для тестирования. Стабильная серия — 1.4, текущая версия — 1.4.5. Начните с версии 1.4 уже сейчас. Borg 2 изменяет формат репозитория и предоставляет документированный путь обновления (borg transfer --from-borg1), поэтому текущий выбор не создаёт тупик. В Borg 2 также появится встроенная поддержка S3, B2 и rclone после стабилизации версии.