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

Привет! Я, Семёнов Евгений Сергеевич, директор ITFresh. За 15 лет работы с IT-инфраструктурой малого и среднего бизнеса чего только не насмотрелся: компании теряли ценнейшие данные. И что вы думаете? Причина почти всегда одна: никакого внятного плана по бэкапам. Просто какие-то файлы на внешнем диске, пятилетней давности. Никто их не проверял, нет истории версий, и главное — никто не понимает, что потом восстанавливать и куда. Звучит знакомо? В этом материале расскажу, как построить реально работающую стратегию резервного копирования и что для этого пригодится.

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

Самая большая ошибка, с которой мы сталкиваемся: бросаться сразу выбирать софт или железо. Запомните: сначала бизнес чётко формулирует, сколько стоит каждый час простоя и сколько компания теряет при пропаже 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? Увы, с приходом шифровальщиков оно стало устаревшим. Вот современная, более надёжная версия:

Да, согласен, соблюсти все пять пунктов – это, конечно, идеал. В реальном малом бизнесе часто бывает, что на офсайте пытаются сэкономить и иногда пропускают этот пункт. Но вот про неизменяемые бэкапы (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 или подобных систем, тут без вариантов: только специализированные агенты Veeam или Veritas.

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

Внимание! Ваши бэкапы почти наверняка содержат персональные данные — сотрудников, клиентов. А значит, согласно 152-ФЗ, вы обязаны их шифровать, как при хранении, так и при передаче. Какие есть варианты шифрования?

• BorgBackup? Это серьёзно! Внутри — встроенное шифрование AES-CTR, да ещё с HMAC-SHA256. Ваши данные под надёжной защитой.
• Restic — аналогично, AES-256.
• А как насчёт физической защиты? Используем LUKS-шифрование самого устройства хранения. Посторонние точно не залезут.
• GPG для старых rsync-пайплайнов.

Главное правило, про которое многие забывают: ключи шифрования должны храниться отдельно! Никогда не храните их там же, где зашифрованные данные. Мы в ITFresh используем такую типовую схему: парольная фраза хранится в корпоративном 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 человек. Их IT-инфраструктура довольно типична, но при этом сложна: 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? Для 1С — всего 15 минут, и это благодаря WAL-архивированию. Для файл-сервера — 1 час, тут спасают Btrfs-снимки. А для всего остального установили 4 часа. Что по RTO? Для критичных систем, например, 1С, он составил всего 1 час. Для всех других — 4 часа. Вся эта махинация обошлась в 580 тысяч рублей, а ежемесячное обслуживание — 12 тысяч. И знаете что? Система полностью себя окупила уже через три месяца! Представьте: один из бухгалтеров случайно удалил целый каталог с документами за квартал. Паника? Нет! Мы восстановили всё за каких-то 20 минут, используя снимок, сделанный всего час назад. Вот это мы называем результатом!

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

• Вот вам совет от нас: ни в коем случае не копируйте базу данных просто так, на уровне файлов, если вы её не остановили или не сделали дамп. Иначе что получите? 100% битый бэкап, а это очень обидно.
• И ещё одно правило: никогда не храните резервные копии на той же СХД, что и оригинал. Почему? Потому что если это хранилище выйдет из строя, вы потеряете всё — и рабочие данные, и их бэкапы. Это же катастрофа!
• 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-копии. Если и она поражена — катастрофа, для того эту копию и делают.