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

Restic и BorgBackup: сравнение

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

Все остальные различия менее значительны. Оба инструмента используют разбиение файлов на блоки по их содержимому, поэтому при изменении 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 files). Для чтения данных ничего больше не требуется. Именно поэтому 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, после чего каждый записанный 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 для 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?

На локальном диске или быстрой локальной сети показатели близки, и оба инструмента упираются в скорость чтения и хеширования на стороне источника. 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 меняет формат репозитория и предоставляет документированный путь обновления, поэтому начало работы сегодня не создаст вам проблем в будущем.