Стратегия резервного копирования Linux-серверов: как не остаться без данных

Меня зовут Семёнов Евгений Сергеевич, я директор АйТи Фреш. За 15+ лет работы с ИТ-инфраструктурой малого и среднего бизнеса я видел десятки случаев, когда компания теряла данные. И почти всегда причина одна и та же — не было стратегии. Были «какие-то бэкапы» на внешний диск, сделанные пять лет назад, без проверки, без истории, без понимания, что и куда восстанавливать. Эта статья про то, как построить стратегию, которая работает, и чего она стоит.

Начинаем с вопросов бизнесу, а не с железа

Ошибка номер один — начинать с выбора софта и железа. Правильная последовательность: бизнес говорит, сколько ему стоит час простоя и потеря N часов работы, а дальше инженер подбирает решение. Основные параметры:

• RPO (Recovery Point Objective) — сколько данных допустимо потерять. Для 1С-базы розничной сети это может быть 15 минут, для файлов с проектами — сутки.
• RTO (Recovery Time Objective) — сколько сервис может быть недоступен. Интернет-магазин в чёрную пятницу — 15 минут, офисный файл-сервер — 4 часа.
• Retention — сколько хранить копии. Для бухгалтерии по НК РФ — 5 лет, для оперативных данных — 90 дней.
• Объём — сколько терабайт данных, с учётом роста на 2-3 года вперёд.

Я всегда начинаю аудит у клиента с таблицы «какой сервис — какой RPO/RTO». Без этого бэкапы получаются либо недостаточными (бизнес теряет деньги), либо избыточными (бизнес переплачивает за инфраструктуру).

Правило 3-2-1-1-0

Классическое 3-2-1 устарело с приходом шифровальщиков. Современная версия:

Соблюдение всех пяти пунктов — эталон. В реальности малый бизнес иногда пропускает offsite (экономят), почти всегда забывают про immutable и проверки. У нас на практике — это две самые частые причины катастрофических инцидентов.

Четыре уровня защиты данных

Я строю стратегию как матрёшку из нескольких уровней, каждый из которых защищает от разных угроз:

1. Уровень 1: Снапшоты. Btrfs/ZFS snapshot или LVM на самом сервере. Защищают от случайного удаления файла пользователем. RPO 1 час, RTO 1 минута. Не защищают от сбоя железа.
2. Уровень 2: Локальные бэкапы. Borg или rsync на отдельный NAS в той же стойке. Защищают от сбоя диска/сервера. RPO 1-24 часа, RTO 1-4 часа.
3. Уровень 3: Offsite. Копия на удалённом NAS или в облаке. Защищают от пожара, кражи, аварии в дата-центре. RPO 24 часа, RTO 4-24 часа.
4. Уровень 4: Immutable / Archive. Неизменяемые копии на длительное хранение. Защищают от шифровальщика, который дошёл до всего остального. RPO 7-30 дней, RTO 1-3 суток.

Какие инструменты использовать на каждом уровне

У нас на практике выбор по уровням обычно такой:

• Уровень 1: snapper (Btrfs) или zrepl (ZFS). Иногда LVM snapshot, если нужна совместимость со старыми FS.
• Уровень 2: BorgBackup на Synology/QNAP NAS в корпоративной сети.
• Уровень 3: Borg на удалённый NAS в другом дата-центре (часто МТС или Selectel), либо Restic в S3-совместимое облако.
• Уровень 4: MinIO с Object Lock, Yandex Object Storage в режиме WORM, или физические LTO-ленты.

Специальные случаи: БД, виртуалки, почта

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

# PostgreSQL — логический дамп + WAL archiving для point-in-time recovery
pg_dumpall --clean | gzip > /var/backups/pg/all.sql.gz
# + в postgresql.conf: archive_mode=on, archive_command='test ! -f /wal/%f && cp %p /wal/%f'

# MySQL/MariaDB
mariabackup --backup --target-dir=/var/backups/mariadb/$(date +%F)
mariabackup --prepare --target-dir=/var/backups/mariadb/$(date +%F)

# KVM VMs — virtnbdbackup с dirty bitmaps
virtnbdbackup -d vm-name -l inc -o /backup/vms/vm-name

# Mail — консистентный бэкап mailbox требует блокировки:
# для Dovecot — doveadm backup между серверами
doveadm backup -u user@example.com mdbox:/backup/mail/user

1С на PostgreSQL — всегда логический дамп плюс физический бэкап каталога базы после остановки службы. Exchange/Exchange-подобные системы — специализированные агенты Veeam или Veritas.

Шифрование и хранение ключей

Бэкапы почти всегда содержат персональные данные сотрудников или клиентов. Требование 152-ФЗ — шифровать при хранении и передаче. Варианты:

• BorgBackup — встроенное шифрование AES-CTR с HMAC-SHA256.
• Restic — аналогично, AES-256.
• LUKS-шифрование самого устройства хранения.
• GPG для старых rsync-пайплайнов.

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

Мониторинг и тестирование

Я всегда подключаю бэкапы к Prometheus через node_exporter textfile collector:

# /usr/local/bin/borg-backup.sh в конце:
cat << EOF > /var/lib/prometheus/node-exporter/borg.prom
# HELP borg_last_backup_timestamp Unix timestamp of last successful backup
# TYPE borg_last_backup_timestamp gauge
borg_last_backup_timestamp{repo="server1"} $(date +%s)

# HELP borg_backup_duration_seconds Duration of last backup
# TYPE borg_backup_duration_seconds gauge
borg_backup_duration_seconds{repo="server1"} ${DURATION}
EOF

В Alertmanager — правило: если last_backup_timestamp старше 30 часов, слать алерт в Telegram.

Раз в месяц — выборочный тест: восстанавливаем случайный бэкап случайной системы на тестовый сервер, запускаем сервис, проверяем работоспособность. Фиксируем в журнале «бэкап за 2025-02-14 восстановлен, приложение запустилось, тест пройден».

Кейс: построение стратегии для производственной компании

В январе 2025 к нам пришёл клиент — завод металлообработки в Подмосковье, 85 рабочих мест. Инфраструктура: 1С ERP на Windows Server + PostgreSQL (350 ГБ), файл-сервер с 3D-моделями (2.8 ТБ), почтовый сервер exchange-on-prem, Asterisk, учётные системы цехов. Бюджет на бэкапы — до 600 тыс. руб. единоразово плюс 15 тыс./мес.

Спроектировали четырёхуровневую схему. Купили Dell PowerEdge R750 с Xeon Platinum 8280 и 96 ГБ RAM как целевой сервер бэкапов, HP MSA 2050 на 60 ТБ raw (RAID-6). Разместили в дата-центре МТС, связь через 40G Mellanox VPN-туннель. На заводе — Synology RS3621xs+ для первого уровня локальных бэкапов. Offsite — Yandex Object Storage с Object Lock на 30 дней для месячных архивов.

RPO: 15 минут для 1С (через WAL-archiving), 1 час для файл-сервера (Btrfs snapshots), 4 часа для остального. RTO: 1 час для критичного (1С), 4 часа для всего остального. Итоговая стоимость проекта — 580 тыс. руб., ежемесячное обслуживание — 12 тыс. руб. Уже через 3 месяца один из бухгалтеров случайно удалил каталог с документами за квартал — восстановили за 20 минут из снимка часовой давности. Это окупило всю систему.

Что НЕ делать (чек-лист из опыта)

• Не копируйте БД на уровне файлов без остановки/дампа — получите битый бэкап.
• Не храните бэкапы в той же СХД, где оригинал — даунтайм хранилища убьёт и то, и другое.
• Не игнорируйте offsite — пожар/кража уничтожают всю стойку разом.
• Не давайте рабочим пользователям доступ к бэкап-хранилищу.
• Не используйте один пароль на все репозитории.
• Не забывайте мониторить — молчаливо сломавшийся cron-job за полгода приведёт к потере истории.

FAQ — частые вопросы о стратегии бэкапов

Что такое RPO и RTO?

RPO — допустимая потеря данных в часах. RTO — время восстановления сервиса.

Что означает правило 3-2-1?

3 копии, 2 носителя, 1 offsite. Современная версия 3-2-1-1-0 добавляет immutable и нулевые ошибки при проверке.

Какой бюджет нужен на бэкапы для офиса на 50 мест?

Разово 200-400 тыс. руб. на железо, 5-15 тыс./мес на хранение и обслуживание.

Как часто тестировать восстановление?

Критичные системы — ежемесячно выборочно, полный DR-тест — раз в полгода.

Что делать, если шифровальщик дошёл до NAS?

Восстанавливаться с offsite immutable-копии. Если и она поражена — катастрофа, для того эту копию и делают.