Бэкап и восстановление BorgBackup

MAATRIX

Если вы гоняете tar и rsync в cron, то знаете эту боль: полный бэкап каждую ночь съедает диск за пару недель, инкрементальные копии путаются, а восстановить нужно ровно один файл — и приходится распаковывать гигабайты архива целиком. BorgBackup решает это иначе: он режет данные на блоки, хранит только уникальные, сжимает и по желанию шифрует — и после первого полного бэкапа каждый следующий занимает разумные мегабайты вместо гигабайт.

Что такое BorgBackup и почему дедупликация меняет экономику

Borg — это консольная программа для бэкапов с content-defined chunking: файл делится на блоки переменного размера по содержимому, а не по фиксированным границам. Если вы добавили строку в середину лога на 500 МБ, Borg пересчитает контрольные суммы блоков и увидит, что 499 МБ данных не изменились — в репозиторий уйдёт только новый блок. Для БД-дампов, логов, VM-образов и вообще любых данных, где между снимками меняется малая доля, экономия места — в разы, иногда на порядок.

Три вещи, которые отличают Borg от связки tar + rsync:

• Дедупликация на уровне блоков, а не файлов — работает, даже если файл переименовали или сдвинули часть содержимого.
• Сжатие (lz4, zstd, zlib, lzma) применяется к уже дедуплицированным блокам, экономия складывается.
• Аутентифицированное шифрование (AES-256 + HMAC или BLAKE2) прямо в репозитории — не нужен отдельный gpg или LUKS-контейнер.

Расплата — Borg держит индекс чанков в памяти клиента при бэкапе, и на первом полном снимке большого датасета это может быть заметно по RAM. Для типичного веб-проекта или пары баз данных это не проблема, для десятков терабайт — стоит закладывать сервер с запасом по памяти.

Установка на сервере

Пакет есть в репозиториях всех популярных дистрибутивов, ставить из исходников не нужно.

# Debian / Ubuntu
apt update && apt install -y borgbackup

# AlmaLinux / RHEL (EPEL)
dnf install -y epel-release
dnf install -y borgbackup

# проверка версии
borg --version

На момент написания в репозиториях Debian 12 и Ubuntu 24.04 идёт ветка 1.2.x — этого достаточно для всех сценариев ниже. Если нужна свежая 1.4 с улучшениями по скорости, ставьте через pipx install borgbackup — это не сломает системный пакет.

Для восстановления через borg mount дополнительно понадобится FUSE:

apt install -y fuse3
# или на системах с fuse2
apt install -y fuse

Инициализация репозитория и первый бэкап

Репозиторий — это каталог, куда Borg складывает чанки и метаданные. Он может быть локальным (второй диск, смонтированный NAS) или удалённым по SSH — синтаксис одинаковый.

# локальный репозиторий с шифрованием repokey (ключ хранится внутри репозитория)
borg init --encryption=repokey-blake2 /mnt/backup/repo

# Borg спросит пароль — сохраните его отдельно, без него данные не расшифровать

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

export BORG_PASSPHRASE='ваш-длинный-пароль'
# или, безопаснее — команда, которая печатает пароль в stdout
export BORG_PASSCOMMAND='cat /root/.borg-passphrase'

Первый бэкап — полный по объёму данных, но это единственный раз, когда так будет:

borg create \
  --stats --progress \
  --compression zstd,6 \
  --exclude-caches \
  /mnt/backup/repo::'{hostname}-{now:%Y-%m-%d_%H:%M}' \
  /etc /home /var/www /var/lib/mysql-dump

{hostname} и {now} — плейсхолдеры Borg, каждый запуск создаёт архив с уникальным именем внутри общего репозитория. --exclude-caches пропускает каталоги с файлом CACHEDIR.TAG (типично для node_modules, кешей сборки). Второй и все последующие запуски той же командой будут читать те же файлы, но в репозиторий уйдут только изменившиеся блоки — обычно счётчик "This archive: X MB" резко падает уже со второго прогона.

Автоматизация: cron и ротация через prune

Голый borg create в cron быстро завалит диск архивами, если не чистить старые. За это отвечает borg prune — он не трогает уникальные данные, а лишь помечает архивы на удаление и освобождает больше не нужные чанки:

#!/bin/bash
# /usr/local/bin/borg-backup.sh
set -e
export BORG_PASSCOMMAND='cat /root/.borg-passphrase'
REPO=/mnt/backup/repo

borg create --stats --compression zstd,6 \
  "$REPO::{hostname}-{now:%Y-%m-%d_%H:%M}" \
  /etc /home /var/www

borg prune --list \
  --keep-daily=7 --keep-weekly=4 --keep-monthly=6 \
  "$REPO"

# схлопнуть освободившееся место в самом репозитории
borg compact "$REPO"

chmod +x /usr/local/bin/borg-backup.sh

# crontab -e
0 3 * * * /usr/local/bin/borg-backup.sh >> /var/log/borg-backup.log 2>&1

Обратите внимание на borg compact отдельным шагом — без него prune только помечает данные как удалённые, а физическое освобождение места в репозитории (для локального или SSH-репозитория с поддержкой compact) происходит именно на этой команде. Если у вас параллельно настроен мониторинг выполнения задач по расписанию, полезно обернуть скрипт пингом на внешний сервис — это подробно разобрано в статье про мониторинг cron-задач через healthchecks.io: если бэкап ночью не отработал, вы узнаете об этом утром, а не через неделю при попытке восстановиться.

Восстановление данных

Тут Borg удобнее большинства альтернатив — можно вытащить как весь архив, так и один файл, не разворачивая остальное.

# список архивов в репозитории
borg list /mnt/backup/repo

# полное восстановление конкретного архива в текущий каталог
cd /restore
borg extract /mnt/backup/repo::server1-2026-08-30_03:00

# восстановить один путь из архива
borg extract /mnt/backup/repo::server1-2026-08-30_03:00 var/www/site/wp-config.php

Ещё один способ — смонтировать архив как обычную файловую систему через FUSE и найти нужный файл вручную, без заранее известного пути:

mkdir -p /mnt/borg-mount
borg mount /mnt/backup/repo::server1-2026-08-30_03:00 /mnt/borg-mount

# смотрите, копируйте, что нужно
ls /mnt/borg-mount/var/www/

# после работы обязательно отмонтировать
borg umount /mnt/borg-mount

Перед тем как полагаться на бэкап в критический момент, стоит время от времени проверять целостность репозитория — битые чанки на диске или в сети иногда случаются:

borg check --verify-data /mnt/backup/repo

Это не быстрая операция на больших репозиториях (Borg перечитывает и пересчитывает контрольные суммы), поэтому --verify-data разумно гонять не в каждом cron-прогоне, а раз в неделю отдельным заданием. Общие принципы самой процедуры восстановления и то, что стоит проверять заранее, а не в момент аварии, разобраны в статье восстановление базы данных из бэкапа на практике.

Удалённый репозиторий и офсайт-копия

Локальный бэкап на том же сервере защищает от испорченного файла или неудачного деплоя, но не от отказа диска или потери сервера целиком. Borg одинаково работает с репозиторием по SSH — синтаксис меняется только в адресе:

borg init --encryption=repokey-blake2 \
  ssh://backup-user@backup-host.example:22/~/repo

borg create --stats --compression zstd,6 \
  ssh://backup-user@backup-host.example:22/~/repo::'{hostname}-{now}' \
  /etc /home /var/www

На стороне принимающего сервера должен быть установлен тот же Borg (передаётся команда borg serve), а для безопасности имеет смысл ограничить SSH-ключ бэкап-пользователя через command="borg serve --restrict-to-path /home/backup-user/repo" в authorized_keys — тогда с этим ключом ничего, кроме приёма бэкапов, сделать нельзя.

Дедупликация здесь особенно выгодна: если у вас несколько серверов с похожим окружением (одна и та же ОС, одинаковые системные файлы), можно писать в общий репозиторий и получать дедупликацию не только между снимками одной машины, но и между машинами — Borg не знает разницы, чанки есть чанки. Для отдельного VPS под роль бэкап-хранилища стоит закладывать не столько CPU, сколько дисковое пространство и приличный объём RAM под индекс — ориентиры по ресурсам разобраны в статье сколько ресурсов нужно VPS для бэкапов и архива, а пошаговая настройка такого сервера — в статье пошаговая настройка VPS под бэкапы и архив с нуля.

Если шифрование и compliance для вас критичны, а не просто "на всякий случай", посмотрите отдельно разбор нюансов шифрованных бэкапов — бэкап с шифрованием: частые ошибки и решения: там про хранение ключей, доступ при смене персонала и типичные промахи, которые не всегда очевидны из документации Borg.

Частые вопросы