Краткая выжимка: Для гиков и архитекторов, рулящих e-commerce, аналитикой и высоконагруженными Linux-нодами, классический бэкап через
tar.gzне только бессмысленно жрёт диск, но и создаёт риски «хранения данных в открытом виде» при передаче и статике. В этой статье мы выкинем устаревшие скрипты прошлого века и перейдём на корпоративный open-source стек BorgBackup. Благодаря дедупликации на уровне блоков и сквозному шифрованию, мы настроим удалённое аварийное восстановление даже на узком канале. Настройка потребует времени, а первый бэкап нагрузит CPU, но это финальная «капсула спасения» для абсолютного контроля над данными в 2026 году.
Почему в 2026 году пора окончательно отказаться от традиционных бэкапов tar.gz?
В повседневном администрировании Linux многие пишут Shell-скрипты, которые через tar -czvf архивируют директории сайтов или БД, а затем кидают их на резервную ноду через scp или rsync. При объёмах в десятки мегабайт это ещё работает, но когда бизнес растёт и появляются десятки гигабайт или терабайты изображений и БД, фатальные недостатки классической архивации становятся очевидными:
- Критический расход хранилища и канала: Предположим, у твоего e-commerce проекта 50 ГБ данных, а ежедневно добавляется лишь 10 МБ заказов. При классической архивации придётся каждый день сжимать и передавать все 50 ГБ. Это быстро забьёт диск резервной ноды и полностью утилизует пропускную способность сети.
- Иллюзия безопасности: Сжатые архивы обычно хранятся в открытом виде. Если ради экономии ты разместишь бэкапы на серверах с жёстким оверселлом или у ненадёжных провайдеров (скам-хостинг), при взломе ЦОД или несанкционированном доступе к хост-узлу твои БД, клиентские данные и исходный код окажутся полностью доступны.
- Отсутствие контроля версий: Если традиционный бэкап будет перезаписан или зашифрован ransomware, восстановить данные за конкретную дату практически невозможно, если только ты не тратишь огромные объёмы диска на хранение ежедневных полных архивов.
Для построения по-настоящему современного disaster recovery необходимо полностью пересмотреть подход к резервному копированию.
Архитектура BorgBackup и принципы работы на низком уровне
BorgBackup (или просто Borg) заслужил признание среди гиков и корпоративных архитекторов по всему миру благодаря интеграции трёх фундаментальных технологий, которые полностью меняют представление о резервном копировании.
1. Максимальная дедупликация данных (Data Deduplication)
Это главное преимущество Borg. В отличие от Rsync, который сравнивает файлы целиком, Borg использует алгоритм дедупликации на уровне блоков. С помощью алгоритма Content-Defined Chunking (CDC) файлы разбиваются на множество динамически сегментируемых блоков переменной длины. При втором запуске Borg передаёт только те блоки, чьи хеши изменились. Если ежедневно меняется лишь малая часть данных, 100 ежедневных бэкапов 50-гигабайтного сайта в Borg займут около 52 ГБ физического пространства (зависит от частоты изменений и ротации логов), а не 5000 ГБ.
2. Абсолютно безопасное сквозное шифрование (End-to-End Encryption)
Borg выполняет жёсткое шифрование всех блоков алгоритмом AES-256 непосредственно на исходном сервере (где работает твоя инфраструктура). Только после этого зашифрованные данные передаются по сети на удалённый сервер хранения. В процессе передачи целевой узел видит лишь бессмысленный набор бинарных блоков: он не знает ни имён файлов, ни структуры директорий.
3. Эффективный инкрементальный бэкап (Incremental Backup)
Благодаря дедупликации каждый запуск Borg логически представляет собой полный бэкап, но физически и по сетевому трафику потребляет лишь минимальный объём изменённых данных. Это позволяет безопасно настраивать резервное копирование каждый час, не опасаясь переполнения диска.
Практика архитектора: построение off-site disaster recovery на Borg
Для реализации резервного копирования уровня enterprise потребуются два сервера: production-узел (где работает основная инфраструктура) и storage-узел (для хранения резервных копий).
Шаг 1: Настройка аутентификации по SSH-ключам
Borg полностью опирается на протокол SSH для сетевого взаимодействия. Чтобы production-узел мог безопасно передавать данные на storage-узел без ввода паролей, необходимо настроить асимметричную аутентификацию. Инструкции по генерации высокозащищённых ключей и полному отключению входа по паролям см. в базовом руководстве: 【Базовая безопасность 2026】Настройка Ed25519 SSH-ключей на VPS и расширенный troubleshooting SOP.
Шаг 2: Установка Borg и инициализация репозитория
Установи Borg на оба сервера (на примере Ubuntu/Debian):
sudo apt update
sudo apt install borgbackup -y
Затем на production-узле выполни команду инициализации, подключившись к storage-узлу и создав на нём репозиторий (Repository). Допустим, IP хранилища — 10.0.0.2:
borg init --encryption=repokey-blake2 user@10.0.0.2:/mnt/backup/my_site_repo
Примечание: Параметр --encryption=repokey-blake2 является рекомендуемым официальным режимом. Это означает, что ключ шифрования сохраняется в удалённом репозитории, а заданная тобой сложная парольная фраза (Passphrase) служит единственным средством для его будущей расшифровки. Внимание: этот пароль — критически важный элемент безопасности. Никогда его не теряй!
Шаг 3: Создание первого и ежедневных архивов (Archive)
После инициализации можно начать резервное копирование директории /var/www/html с production-узла на удалённое хранилище:
borg create --stats --progress \
user@10.0.0.2:/mnt/backup/my_site_repo::"site-backup-{now:%Y-%m-%d_%H:%M}" \
/var/www/html
С параметром --stats после завершения бэкапа Borg выведет подробный отчёт о дедупликации. Ты заметишь, что благодаря этому механизму время выполнения каждой последующей операции create сократится с десятков минут до нескольких секунд.
Шаг 4: Полная автоматизация через Cron
Добавь команду borg create и переменную окружения с паролем в Shell-скрипт (например, /root/backup.sh):
#!/bin/bash
export BORG_PASSPHRASE="ваш_сложный_пароль"
borg create user@10.0.0.2:/mnt/backup/my_site_repo::"auto-{now:%Y%m%d}" /var/www/html
borg prune -v --list --keep-daily=7 --keep-weekly=4 user@10.0.0.2:/mnt/backup/my_site_repo
Примечание: Команда borg prune автоматически удаляет устаревшие резервные копии, предотвращая переполнение хранилища в долгосрочной перспективе.
После настройки добавь скрипт в планировщик Linux для ежедневного запуска в 03:00. Если ты не знаком с синтаксисом cron, ознакомься с руководством: Полное руководство по Linux Crontab: автоматизация выполнения скриптов на сервере.
Оптимизация для production и руководство по предотвращению ошибок
Borg — мощный инструмент, но он не предназначен для использования «вслепую». Без понимания его внутренней архитектуры в production-среде легко допустить критические ошибки.
💡 Практические рекомендации vps1111:
- Потеря ключа = безвозвратная потеря данных (строгое предупреждение): Borg выполняет жёсткое сквозное шифрование на стороне клиента. Если ты забудешь
BORG_PASSPHRASE, заданный при инициализации, удалённые данные навсегда превратятся в нечитаемый бинарный мусор. Никаких бэкдоров для восстановления не существует. Обязательно сохрани пароль в защищённом менеджере, например 1Password. - Кратковременная высокая нагрузка при первом запуске: При первичном разбиении десятков или сотен гигабайт на блоки и вычислении хешей Borg активно потребляет ресурсы CPU. Если твой production-сервер — слабая 1-ядерная машина, первый бэкап может вызвать заметные задержки в работе сайта. Рекомендуется запускать первоначальное копирование глубокой ночью, при минимальном трафике.
- Рекомендация: ⭐⭐⭐⭐⭐ (Идеальная замена классической архивации, инструмент enterprise-уровня для disaster recovery).
FAQ: Часто задаваемые вопросы
Подходит ли BorgBackup для прямого «горячего бэкапа» работающих MySQL/PostgreSQL?
Прямое резервное копирование физических файлов БД не рекомендуется. Любые инструменты файловой системы при работе с высоконагруженными реляционными базами данных с высокой вероятностью создадут «несогласованные данные (Inconsistent Data)» из-за изменения страниц во время бэкапа, что приведёт к повреждению БД при восстановлении. Оптимальная практика: добавь в начало твоего backup.sh команду mysqldump или pg_dump для экспорта базы в SQL-файл, а затем настрой Borg на резервное копирование именно этого текстового файла. Это гарантирует 100% целостность данных.
Какие требования к конфигурации принимающего сервера (хранилища)?
Минимальные. В этом заключается архитектурное преимущество Borg. Разбиение на блоки, сверка хешей и шифрование полностью выполняются на стороне production-узла. Сервер хранения лишь принимает и записывает зашифрованные блоки. Поэтому даже бюджетный сервер со специальной ценой, оснащённый всего 512 МБ памяти, слабым CPU, но большим HDD, отлично справится с ролью узла хранения для Borg.
Как восстановить данные на новом сервере, если production-узел полностью вышел из строя?
Процесс восстановления максимально прост. Достаточно арендовать новый сервер, установить клиент Borg и выполнить команду: borg extract user@IP_хранилища:/mnt/backup/my_site_repo::"имя_архива". При корректном вводе исходной парольной фразы Borg загрузит зашифрованные данные с удалённого узла, расшифрует их в реальном времени и полностью восстановит исходную структуру директорий и права доступа файлов.