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

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

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

Остальные различия менее значительны. Обе программы разбивают файлы на блоки с разбиением по содержимому, поэтому из каталога размером 40 GB, в котором изменилось 200 MB, будет загружено примерно 200 MB. Обе программы шифруют данные на клиенте. Обе подключают снимок через FUSE (файловая система в пользовательском пространстве), чтобы можно было скопировать отдельный файл. По состоянию на July 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-систем. Любое хранилище, которое умеет записывать, получать, перечислять и удалять blobs, может хранить репозиторий restic. Поэтому один бинарный файл поддерживает локальные пути, SFTP, собственный REST-сервер, S3, Backblaze B2, Azure, Google Cloud Storage и любые хранилища, доступные через rclone.

Репозиторий Borg также состоит из файлов на диске, но Borg никогда не обращается к нему через простой транспорт. Для удаленного репозитория Borg запускает borg serve на удаленной стороне через SSH и взаимодействует с этим процессом по собственному протоколу. Серверная сторона выполняет реальную работу: хранит репозиторий, применяет транзакции и отвечает на запросы к индексам. Поэтому у Borg нет backend-системы S3 и проект ее не добавил. В bucket нельзя запустить процесс.

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

# 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 или max. Старый репозиторий формата 1 остается без сжатия, пока Вы не выполните его миграцию. Поэтому, если Ваш репозиторий restic создан до версии 0.14 и Вы ни разу не выполняли миграцию, текст, журналы и дампы баз данных по-прежнему занимают полный исходный объем.

Удаленные цели: S3 и SSH

Именно здесь обычно принимают решение.

Для подключения restic к S3 нужны учетные данные в окружении. Больше ничего запускать где-либо не требуется. Та же схема работает с хранилищем, которое вы размещаете самостоятельно. Это распространенная комбинация: запустите MinIO с API S3 на собственном 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-ключ только для добавления данных. Настройте ключ так, чтобы он выполнял borg serve. Тогда клиент сможет добавлять архивы, но не сможет их удалять. В случае взлома машины злоумышленник не сможет уничтожить историю резервных копий.

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

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

Скорость: что означает каждая архитектура

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

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

У restic при работе с объектным хранилищем нет серверной части, поэтому программа формирует представление о данных из индексных файлов и pack-файлов, которые загружает по HTTP. Чтобы количество запросов оставалось приемлемым, перед загрузкой программа объединяет множество небольших блоков в более крупные pack-файлы. Локальный кэш хранится в ~/.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 удаляет только ссылки на снимки. Данные сохраняются до выполнения 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 не соответствует ни одному пути и ничего не извлекает. При этом сообщение об ошибке не выводится. Извлечение также выполняется в текущий рабочий каталог. Поэтому сначала перейдите в отдельный временный каталог. Иначе старые файлы перезапишут актуальные.

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

Что выбрать для конкретной задачи

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

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

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

FAQ

Что быстрее: restic или BorgBackup?

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

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

Напрямую — нет. Репозиторий Borg обслуживается процессом borg serve через SSH. Внутри бакета такой процесс не запускается. Обычно объектное хранилище монтируют как файловую систему с помощью rclone. Проект Borg этого не рекомендует, поскольку сбой подключения во время транзакции может повредить репозиторий. Если вам нужно объектное хранилище, используйте restic.

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

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

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

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

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

Нет. По состоянию на July 2026 Borg 2.0 всё ещё находится в бета-тестировании, версия — 2.0.0b22. Проект указывает, что эта версия предназначена только для тестирования. Стабильная серия — 1.4, текущая версия — 1.4.5. Начните с 1.4 уже сейчас. Borg 2 изменяет формат репозитория и предоставляет документированный путь обновления, поэтому начало работы сегодня не создаёт проблем при последующем переходе.