BorgBackup на Ubuntu 24.04: пошаговая установка

MAATRIX

Классическая схема «tar + cron + rsync» работает, но у неё есть слабое место: каждая полная копия занимает столько же места, сколько предыдущая, а шифрование и целостность архивов приходится городить отдельно. BorgBackup решает это одним инструментом — он хранит только изменившиеся куски данных, сжимает их и шифрует прямо на лету, а по ощущениям для вас каждый бэкап выглядит как полный, хотя реально занимает место только новых данных. Разберём установку и настройку BorgBackup на Ubuntu 24.04 с нуля — от репозитория до автоматического расписания и проверенного восстановления.

Что такое BorgBackup и чем он лучше tar

Borg делит каждый файл на куски переменной длины по содержимому (content-defined chunking), считает хэш каждого куска и сохраняет в репозитории только те куски, которых там ещё нет. Если вы каждую ночь бэкапите каталог на 50 ГБ, а за день изменилось 200 МБ, новый архив добавит в репозиторий примерно 200 МБ новых чанков — остальное просто сошлётся на уже сохранённые данные. При этом каждый архив в репозитории остаётся самостоятельным и полным: удалить старый архив можно без риска сломать более новые, потому что общие чанки просто останутся использоваться другими архивами.

В сравнении с автоматическими бэкапами через tar и cron разница в трёх вещах: дедупликация не даёт диску расти линейно от числа копий, сжатие (lz4, zstd, zlib) встроено и не требует отдельной команды gzip, а шифрование репозитория ключом или парольной фразой закрывает данные ещё до того, как они лягут на диск. Обратная сторона — Borg сложнее в освоении, чем связка из трёх утилит, и репозиторий несовместим с обычным tar -xzf: доставать файлы нужно самим Borg.

Устанавливаем Borg

В репозиториях Ubuntu 24.04 пакет borgbackup есть из коробки, ставить сторонние PPA не требуется:

sudo apt update
sudo apt install borgbackup

Проверьте, что установка прошла успешно, и посмотрите версию:

borg --version

Точную версию покажет сама команда — в apt-репозиториях Ubuntu она периодически обновляется, и это нормально: формат репозитория Borg обратно совместим внутри второй ветки (Borg 2.x). Если вам нужна свежая версия из pip, ставьте её в виртуальное окружение, а не поверх системного Python, чтобы не конфликтовать с зависимостями apt. Для монтирования архивов через FUSE дополнительно понадобится пакет borgbackup-fuse — поставьте его сразу:

sudo apt install borgbackup-fuse

Создаём и инициализируем репозиторий

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

sudo mkdir -p /backup/borg-repo
sudo chown $USER:$USER /backup/borg-repo

Инициализируйте репозиторий с шифрованием repokey — при этом варианте ключ шифрования хранится внутри самого репозитория и защищён вашей парольной фразой:

borg init --encryption=repokey /backup/borg-repo

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

borg key export /backup/borg-repo /root/borg-key-backup.txt

Кроме repokey есть режим keyfile, где ключ хранится не в репозитории, а локально на клиентской машине — это удобнее, если репозиторий лежит на недоверенном удалённом хранилище. Подробнее о выборе между вариантами шифрования и типичных ошибках при настройке смотрите в статье про бэкап с шифрованием на сервере.

Первый бэкап и как работает дедупликация

Создадим первый архив — бэкапим типовой набор из веб-каталога, конфигов и домашней папки, сжимая данные алгоритмом zstd с умеренным уровнем сжатия:

export BORG_PASSPHRASE='ваша-парольная-фраза'
borg create --stats --progress \
  --compression zstd,6 \
  /backup/borg-repo::'{hostname}-{now:%Y-%m-%d_%H-%M}' \
  /var/www /etc /home

Имя архива формируется из шаблона: подставляются имя хоста и текущее время, так что каждый запуск создаёт архив с уникальным именем, и запускать команду можно хоть каждый час без риска перезаписи. Флаг --stats в конце выведет сводку: сколько данных обработано, сколько реально записано на диск и какая часть дедуплицирована. При первом запуске эти числа почти совпадут — уникальных чанков ещё нет, дедуплицировать нечего.

Запустите ту же команду на следующий день без изменений в исходной команде — второй архив создастся за секунды, а --stats покажет, что размер новых данных в разы меньше исходного объёма: почти все чанки уже есть в репозитории и просто получают ссылку из нового архива. Именно это и есть смысл content-defined chunking — в отличие от инкрементных бэкапов «по времени модификации файла», Borg сравнивает данные по содержимому, поэтому одинаковый кусок данных из разных файлов (например, общие библиотеки в разных версиях Docker-образов) тоже дедуплицируется.

Автоматизируем через cron

Хранить пароль прямо в команде — плохая идея для автоматизации. Заведите файл с парольной фразой и правами только для владельца:

sudo mkdir -p /etc/borg
sudo sh -c 'echo "ваша-парольная-фраза" > /etc/borg/passphrase'
sudo chmod 600 /etc/borg/passphrase

Соберите скрипт /usr/local/bin/borg-backup.sh, который читает пароль из файла, делает архив и сразу чистит место через prune (см. следующий раздел):

#!/bin/bash
export BORG_REPO=/backup/borg-repo
export BORG_PASSPHRASE="$(cat /etc/borg/passphrase)"

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

borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6

Сделайте скрипт исполняемым и поставьте в cron на ночное время:

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

Добавьте строку с запуском в 2:15 ночи и логированием вывода:

15 2 * * * /usr/local/bin/borg-backup.sh >> /var/log/borg-backup.log 2>&1

Как и с любым cron-заданием, проверьте на следующий день, что в /var/log/borg-backup.log нет ошибок, а borg list /backup/borg-repo показывает свежий архив. Учитывайте, что переменная BORG_PASSPHRASE, установленная через export внутри скрипта, видна только этому процессу и его дочерним — это безопаснее, чем передавать пароль аргументом команды, который остаётся в истории и в выводе ps.

Политика хранения: prune и compact

Без ограничения числа архивов репозиторий будет расти бесконечно, даже с учётом дедупликации — старые уникальные чанки, которые уже никому не нужны, всё равно занимают место. Команда borg prune удаляет архивы по политике хранения, оставляя нужную глубину истории:

borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6 /backup/borg-repo

Это значит: последние 7 ежедневных архивов, последние 4 еженедельных и последние 6 ежемесячных сохраняются, остальные удаляются. Здесь важный нюанс, который часто упускают: prune только помечает архивы как удалённые и убирает ссылки на чанки — реально место на диске освобождает отдельная команда borg compact, которую нужно запускать следом:

borg compact /backup/borg-repo

Без регулярного compact репозиторий будет занимать больше места, чем должен, — чанки, на которые больше никто не ссылается, физически останутся на диске. Добавьте эту команду в тот же скрипт сразу после prune. Также периодически, например раз в месяц, запускайте проверку целостности репозитория — она находит повреждённые чанки до того, как вы обнаружите проблему при попытке восстановления:

borg check /backup/borg-repo

Полная проверка на большом репозитории может занять заметное время и нагрузить диск, поэтому запускайте её в окно низкой нагрузки, а не сразу после ночного бэкапа.

Восстанавливаем данные и переносим на удалённый сервер

Посмотреть список архивов и их содержимое можно так:

borg list /backup/borg-repo
borg list /backup/borg-repo::hostname-2026-08-30_02-15

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

mkdir /mnt/borg-restore
borg mount /backup/borg-repo::hostname-2026-08-30_02-15 /mnt/borg-restore
cp -a /mnt/borg-restore/var/www/mysite /var/www/mysite-restored
fusermount -u /mnt/borg-restore

Если нужно вернуть всё содержимое архива целиком, используйте extract — команда распаковывает в текущую директорию, поэтому предварительно перейдите в нужную папку:

cd /tmp/restore-test
borg extract /backup/borg-repo::hostname-2026-08-30_02-15

Для настоящей защиты по правилу 3-2-1 репозиторий стоит держать не только локально, но и на отдельном сервере. Borg умеет работать поверх SSH без дополнительных инструментов — на удалённой машине тоже должен быть установлен Borg, а инициализация репозитория выглядит так же, только с ssh://-адресом:

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

Если используете нестандартный порт или отдельный SSH-ключ, задайте это через переменную BORG_RSH:

export BORG_RSH="ssh -p 2222 -i /root/.ssh/borg_key"

Дальше все команды — create, prune, compact, check — работают с удалённым репозиторием точно так же, как с локальным, просто путь указывается через ssh://. Если под такой второй сервер нужна отдельная площадка, разумно смотреть на неё отдельно от продакшен-инфраструктуры — какую конфигурацию и локацию выбрать под хранение бэкапов, разобрано в статье VPS для бэкапов и архива.

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