Как установить и настроить BorgBackup на VPS

MAATRIX

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

Почему BorgBackup, а не tar или rsync

Обычный архив через tar.gz создаёт полную копию данных при каждом запуске. Если у вас 50 ГБ данных и вы бэкапитесь раз в сутки, через месяц набежит полтора терабайта — даже если реально менялось по паре гигабайт в день. Rsync с --link-dest частично решает проблему через жёсткие ссылки на неизменённые файлы, но работает только на уровне файлов целиком: поменялась одна строка в логе на 10 ГБ — копируется весь файл заново.

Borg дедуплицирует на уровне блоков переменного размера (content-defined chunking). Файл режется на куски по содержимому, и если кусок уже есть в репозитории — из другого файла, из прошлого бэкапа, откуда угодно — он не копируется повторно, а только получает ссылку. На практике это значит, что база данных, изменившаяся на 1%, добавит в репозиторий примерно 1% нового объёма, а не создаст полную копию. Поверх дедупликации Borg добавляет сжатие (zstd, lz4 или zlib на выбор) и опциональное шифрование AES-256 прямо на клиенте — данные покидают сервер уже зашифрованными.

Из практических ограничений: Borg — не готовое SaaS-решение, а инструмент командной строки, который нужно самому обвязать cron-заданиями и мониторингом. И репозиторий Borg — это не универсальный S3-бакет: он живёт в своём формате, и работать с ним умеет только сам Borg (или совместимый форк Borgmatic).

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

Схема простая: Borg ставится и на машину с данными (клиент), и, если бэкапы идут на отдельный сервер по SSH, на сервер-хранилище (там нужен как минимум borg serve, а по факту проще поставить полный пакет). На Ubuntu и Debian пакет есть в стандартных репозиториях, но версия в них обычно отстаёт на год-два от актуальной — для дедупликации это не критично, но новые фичи вроде улучшенного chunking появляются только в свежих релизах.

apt update
apt install -y borgbackup
borg --version

Если нужна более свежая версия, есть готовый бинарник borgbackup.pyz (Python zipapp) — не требует установки зависимостей и одинаково работает на разных дистрибутивах:

wget https://github.com/borgbackup/borg/releases/latest/download/borg-linux-glibc231.tgz
tar -xzf borg-linux-glibc231.tgz
chmod +x borg-linux-glibc231
mv borg-linux-glibc231 /usr/local/bin/borg
borg --version

Точное имя файла зависит от релиза и версии glibc на сервере — проверьте страницу релизов на GitHub перед скачиванием. Если бэкапы будут уходить на второй сервер по SSH, там достаточно того же пакета: Borg сам запускает borg serve на удалённой стороне при подключении.

Инициализация репозитория и шифрование

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

# Локальный репозиторий (например, на отдельном диске)
borg init --encryption=repokey-blake2 /mnt/backup/repo

# Удалённый репозиторий на втором сервере по SSH
borg init --encryption=repokey-blake2 user@backup-host:/srv/borg/repo

Режим шифрования стоит выбрать осознанно:

repokey удобнее — ключ переезжает вместе с репозиторием, не нужно отдельно бэкапить keyfile. keyfile безопаснее в модели угроз, где хранилище может быть скомпрометировано отдельно от клиента: например, бэкапы лежат у третьей стороны. Суффикс -blake2 — более быстрый алгоритм хеширования на современных CPU без AES-NI, разницы в безопасности с обычным SHA-256 вариантом нет, но на многих VPS blake2 заметно быстрее.

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

export BORG_PASSPHRASE='ваш-надёжный-пароль'
export BORG_REPO='user@backup-host:/srv/borg/repo'

Переменные окружения BORG_REPO и BORG_PASSPHRASE избавляют от необходимости указывать репозиторий и пароль в каждой команде — это пригодится при автоматизации.

Первый бэкап и стратегия исключений

Создание архива — команда borg create с именем архива и списком путей. Имя архива удобно делать с временной меткой, чтобы архивы не перезаписывали друг друга и легко сортировались по дате.

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

Двойное двоеточие :: — это репозиторий, взятый из BORG_REPO, плюс имя архива после него. Флаг --compression zstd,6 задаёт сжатие zstd с уровнем 6 — разумный баланс скорости и степени сжатия для большинства данных; для CPU послабее подойдёт уровень 3, для архивного холодного хранилища — 15-19, но это заметно медленнее.

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

borg create \
  --stats --progress \
  --compression zstd,6 \
  --exclude '/var/www/*/cache/*' \
  --exclude '/home/*/.cache' \
  --exclude-caches \
  ::'{hostname}-{now:%Y-%m-%d_%H%M}' \
  /etc /home /var/www /var/lib/postgresql

Флаг --exclude-caches автоматически пропускает каталоги с файлом-меткой CACHEDIR.TAG — так помечают себя многие системы кеширования. Для баз данных важна консистентность: бэкап файлов PostgreSQL или MySQL «на живую» без остановки или снапшота может дать повреждённый дамп. Правильный подход — либо pg_dump/mysqldump перед запуском Borg (архивируется уже готовый дамп, а не файлы движка), либо снапшот файловой системы (LVM, ZFS, Btrfs) на момент бэкапа.

Ротация архивов через prune

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

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

Логика — «сетка хранения»: последние 7 дней держим ежедневные бэкапы, дальше — по одному в неделю за последний месяц, а ещё дальше — по одному в месяц за полгода. Это стандартная схема, которая даёт частое восстановление на недавние даты и редкие точки на далёком горизонте, не раздувая репозиторий. После prune полезно запускать compact — он физически освобождает место, которое prune только пометил как свободное:

borg compact

Без compact место в репозитории не возвращается сразу — об этом шаге часто забывают, а потом удивляются, почему диск не освобождается после чистки старых архивов.

Автоматизация по cron и мониторинг

Ручной запуск бэкапов работает до первого отпуска или загруженной недели — рано или поздно про них забывают. Обычное решение — обернуть команды в shell-скрипт и повесить на cron.

#!/bin/bash
set -e

export BORG_REPO='user@backup-host:/srv/borg/repo'
export BORG_PASSPHRASE='ваш-надёжный-пароль'

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

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

Сохраните как /usr/local/bin/borg-backup.sh, дайте права на выполнение и добавьте в crontab, например на 3 часа ночи. Подробно про формат cron-строк и типичные ошибки при их настройке — в отдельной статье про настройку cron-задач на VPS.

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

Пароль в открытом виде в скрипте — не идеал: ограничьте права на файл (chmod 600) и, если возможно, используйте BORG_PASSCOMMAND для чтения пароля из внешнего хранилища секретов вместо хранения в файле. Для удалённого репозитория стоит настроить вход по SSH-ключу без пароля — руководство есть в статье про SSH-ключи вместо пароля на VPS, это заодно и безопаснее парольного входа.

Скрипт, который тихо перестал работать полгода назад, — классический сценарий провала бэкапов. Добавьте внешний контроль: сервис вроде healthchecks.io пингуется в конце успешного запуска, и если пинг не пришёл вовремя — шлёт уведомление. Настройка описана в статье про мониторинг cron-задач через healthchecks.io; добавить это к скрипту — одна строка curl в конце. Также не забывайте следить за местом на диске под репозиторий — резкий рост данных может съесть всё свободное пространство быстрее, чем ожидалось, об этом — в статье про мониторинг диска на VPS.

Проверка целостности и восстановление

Бэкап, который ни разу не проверяли на восстановление, — это не бэкап, а обещание бэкапа. Периодически (раз в месяц-квартал) стоит проверять целостность репозитория и пробовать реальное восстановление на тестовой машине.

borg check --repository-only

Список архивов в репозитории и их содержимое — посмотреть проще простого:

borg list ::
borg list ::'{hostname}-2026-08-15_0300'

Восстановление всего архива или отдельных файлов делается через extract — по умолчанию Borg распаковывает в текущий каталог, сохраняя структуру путей:

mkdir /tmp/restore-test && cd /tmp/restore-test
borg extract ::'{hostname}-2026-08-15_0300' var/www/mysite/config.php

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

borg mount ::'{hostname}-2026-08-15_0300' /mnt/borg-mount
ls /mnt/borg-mount
cp /mnt/borg-mount/var/www/mysite/config.php /tmp/
borg umount /mnt/borg-mount

Именно проверка восстановления, а не факт наличия файлов в репозитории, даёт уверенность, что бэкап реально сработает в критический момент. Правило «3-2-1» здесь тоже уместно: минимум три копии данных, на двух разных носителях, одна — вне основного сервера физически. VPS для второй копии — недорогое решение, если объём бэкапов не гигантский; про подбор такого сервера есть отдельный обзор — лучший VPS для бэкапов.

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