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

Restic против BorgBackup в одном абзаце

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

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

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

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

Репозиторий Borg — это также набор файлов на диске, но Borg никогда не взаимодействует с ними через простой транспорт. Для удаленного репозитория Borg запускает borg serve на стороне сервера по SSH и общается с этим процессом по собственному протоколу. Серверная часть выполняет реальную работу: она хранит репозиторий, применяет транзакции и отвечает на запросы к индексу. Именно поэтому у Borg нет бэкенда 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, после чего каждый записанный файл пакета шифруется и проходит проверку подлинности. Потеря пароля означает безвозвратную потерю данных, так как механизм восстановления не предусмотрен архитектурой.

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 для получения 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-сервера, который поддерживает режим «только добавление». При работе с обычным S3 того же эффекта можно добиться с помощью политик бакета или блокировки объектов (object lock), что является задачей провайдера, а не restic. Также ограничьте доступ к транспорту, так как SSH-соединение в данном случае требует такой же защиты, как и любой другой вход в систему: примените SSH-доступ только по ключам с ограничением в файле authorized_keys для учетной записи, используемой для резервного копирования.

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

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

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

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

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

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

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

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

Хранение: 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-задача, которая только удаляет архивы, но не выполняет сжатие, приведёт к бесконечному росту репозитория при коротком списке архивов. В restic команда forget без --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 timer.

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

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

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

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

FAQ

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

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

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

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

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

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

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

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

Стоит ли ждать Borg 2.0?

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