Резервное копирование сайта: стратегии и восстановление

Резервное копирование сайта — это не «запасной файл на всякий случай», а управляемый процесс, который определяет скорость восстановления после сбоя, взлома, ошибки релиза или отказа серверов. Ниже — рабочие стратегии, инструменты и чек‑лист, чтобы настроить бэкапы и реально уметь восстановиться.

Зачем бизнесу резервное копирование и что ломается чаще всего

• Человеческий фактор: неудачный деплой, удаление таблицы БД, конфликт плагинов.
• Вредоносные действия: шифровальщики, бэкдоры, дефейс.
• Инфраструктура: падение диска/RAID, сбой в ДЦ/облаке, ошибки провайдера.
• Данные: повреждённые образы, битые индексы, несовместимые миграции.

Риск материализуется внезапно. Поэтому важно считать RPO/RTO и строить бэкап‑стратегию под них.

• RPO (Recovery Point Objective): сколько данных допустимо потерять (например, 15 минут транзакций).
• RTO (Recovery Time Objective): за сколько времени система должна подняться (например, 30 минут до возврата в SLA).

Резервное копирование сайта по модели 3-2-1

Стратегия бэкапов 3‑2‑1 — отраслевой стандарт, который остаётся практичным:

1. Храните как минимум 3 копии данных: прод + 2 резервные.
2. На 2 разных типах носителей: например, объектное хранилище и локальный диск/лента.
3. 1 копия — offsite backup для сайта, физически/сетево отдельно (другой регион/провайдер).

Практика применения:

• Прод: рабочий сервер/кластер.
• Локальный резерв: снимки томов (snapshots) на уровне гипервизора/СХД или инкрементные копии в том же облаке — для быстрого отката.
• Offsite: объектное хранилище S3‑совместимое или другой облачный регион/провайдер, недоступный из прода напрямую. Шифрование, отдельные креды, минимальные ACL.

Что бэкапить: не только файлы

Чтобы восстановление сайта из бэкапа было полным и консистентным, в зону копирования должны входить:

• Файлы приложения: исходники, статический контент/uploads, собранные бандлы.
• Бэкап базы данных: дампы или физические копии + журналы (binlog/WAL) для point‑in‑time recovery.
• Конфигурации/секреты: .env, wp-config.php, .settings.php (Битрикс), nginx/Apache, systemd‑юниты.
• Инфраструктура как код: Terraform/Ansible/Helm charts — ускорит развертывание среды.
• Образы контейнеров/артефакты CI: версии сборок для детерминированного отката.

Консистентность:

• Для MySQL/MariaDB: xtrabackup или Percona Backup for MySQL для горячих копий; mysqldump — для малых инсталляций и логической миграции.
• Для PostgreSQL: pg_dump/pg_dumpall для логических; pg_basebackup + WAL‑архивация (например, wal-g) для PITR.
• Для файлов: LVM/ZFS snapshots, затем выгрузка в объектное хранилище (restic/borg/rsync + checksums).

Автоматические бэкапы сайта: расписание, хранение, контроль

Автоматизация устраняет человеческий фактор. Базовые правила:

• Частота: БД — от каждых 5–15 минут (журналы) до часов; файлы — ежедневно/по изменениям. Согласуйте с RPO.
• Ретенция: недельные, месячные, квартальные «полные» точки, инкременты — плотнее. Типовой стек: 7 daily, 4 weekly, 6 monthly.
• Верификация: регулярный тест восстановления на стенде, автоматическая проверка хеш‑сумм и целостности архивов.
• Версионирование: храните несколько поколений, чтобы откатиться до «чистой» версии при скрытой компрометации.
• Иммутабельность: WORM/Locked buckets в S3‑совместимых сторах защищают от шифровальщиков.

Инструменты:

• restic/borgbackup — дедупликация, шифрование по умолчанию, S3/SSH/локальные таргеты.
• rclone — синхронизация в облака/объектные стора.
• Перконовские утилиты, wal-g — для БД с инкрементами и PITR.
• Сторонние сервисы для CMS (WordPress): UpdraftPlus, Jetpack Backup (для малых проектов; для серьёзных — системный подход предпочтительнее).

Offsite и безопасность: не храните ключи рядом с копиями

Offsite backup для сайта снижает общий риск. Принципы:

• Изоляция: другой аккаунт/организация/регион. Нет прямого доступа из прод‑среды.
• Шифрование: на клиенте (restic/borg) + шифрование в покое (SSE/KMS). Ключи — в отдельном хранилище секретов.
• Сети: минимальные ingress/egress, VPC endpoints при наличии, приватный доступ к хранилищу.
• Доступ: IAM‑политики только на write‑only для агентов бэкапа, чтение — через break‑glass процедуру.
• Проверка изоляции: прохождение tabletop‑сценариев «сайт скомпрометирован, что с бэкапами?».

Восстановление сайта из бэкапа: сценарии и время

Процедуры должны быть документированы и отрепетированы. Типовые сценарии:

• Откат релиза: деплой предыдущего артефакта + миграция БД вниз (если возможна) или восстановление БД на момент до релиза.
• Падение БД: развёртывание нового инстанса, восстановление full backup + журналы до конкретного времени (PITR).
• Компрометация файлов: восстановление только uploads/статики с проверкой сигнатур, код — из репозитория.
• Потеря инфраструктуры: «холодный старт» по IaC + импорт конфигов, затем заливка БД и статического контента.

Метрики восстановления:

• RTO: цель 15–60 минут для типового SME‑сайта при готовых плейбуках.
• RPO: от 0 до 15 минут при журнальном репликационном подходе.
• MTTR: контролируйте в инцидент‑отчётах и улучшайте по итогам постмортемов.

Особенности CMS: бэкап WordPress и Битрикс

WordPress:

• Что копировать: wp-content (themes, plugins, uploads), wp-config.php, дамп MySQL.
• Релизы: фиксируйте версии плагинов/тем (composer/lockfile где возможно).
• Откат: код — из Git, файлы — из бэкапа, БД — точечно или полностью; проверьте серилизованные данные при миграциях.

1С‑Битрикс:

• Структура: /bitrix/, /upload/, .settings.php, настройки веб‑сервера, cron‑агенты.
• БД: как правило MySQL/MariaDB — предпочтительны горячие копии (xtrabackup) + binlog для PITR.
• Кеш/композит: перед бэкапом можно сбросить кеш, при восстановлении — пересобрать.

Общее для обеих CMS:

• Не бэкапьте node_modules и прочие сборочные артефакты — собирайте на CI и храните артефакт отдельно.
• Проверьте права/владельцев файлов после восстановления, регенерируйте SALT/ключи при компрометации.

План восстановления после сбоев: что должно быть

Документ с рабочими шагами, доступный команде 24/7:

• Контакты и роли: кто принимает решения, кто выполняет операции.
• Карточки сценариев (runbooks) с командами: где лежат бэкапы, как подключиться, как расшифровать, что восстанавливать первым.
• Решение по трафику: поставить «техработы», отдать статику/кэш, срезать нагрузку на БД.
• Критические зависимости: SMTP, платежи, CDN, Webhooks — что отключить/переконфигурировать на время аварии.
• Критерии «система здорова»: список проверок после восстановления (авторизация, корзина, оплата, формы, админка).
• Постмортем: как фиксировать выводы и апдейты плейбуков.

Для компаний без собственного SRE/DevOps мы закрываем эти вопросы через услугу DevOps и инфраструктура: проектируем схему, автоматизируем, документируем и тренируем восстановление.

Инструментальные паттерны и примеры конфигураций

• Объектное хранилище: S3‑совместимые сторажи, версии включены, lifecycle‑политики (glacier/архив для long‑term).
• restic: репозитории с паролем, теги по окружениям, автоматическая проверка `restic check`.
• Планировщики: cron/systemd timers/GitHub Actions/GitLab CI по расписанию.
• Контроль целостности: sha256/sha512 для архивов, `restic prune`/`borg prune` по графику.
• Инцидентная готовность: ежеквартальные DR‑учения, отчёт по RTO/RPO, корректировки ретенции.

Полезные материалы по инфраструктуре — в статье «Обслуживание серверов для веб‑приложений: что это и зачем бизнесу» и обзор «Kubernetes: что это и когда он нужен проекту».

Чек‑лист настройки бэкапов сайта

• Определены RPO/RTO для сайта и БД.
• Включена стратегия 3‑2‑1 (в т.ч. offsite копия).
• Бэкапятся: код (из Git), статика/uploads, БД, конфиги/секреты, IaC.
• Автоматизация: расписания, ретенция, очистка старых копий.
• Шифрование: на клиенте + на стороне хранилища, ключи изолированы.
• Иммутабельность: включены версии/WORM‑политики.
• Тест восстановления: стенд, регулярные учения, заскриптованные шаги.
• Мониторинг: алерты по неуспешным задачам бэкапа и деградации RPO.
• Документация: актуальные runbooks и контакты on‑call.
• Доступ: write‑only для агентов, break‑glass для чтения.

Частые ошибки и как их избегать

• Единственная копия «на том же сервере». Решение: offsite + разные носители.
• Нет тестов восстановления. Решение: квартальные DR‑дни и метрики RTO.
• Делаем только «полные» копии. Решение: инкременты + журналы БД, экономия времени/трафика.
• Храним ключи шифрования рядом. Решение: отдельный KMS/секрет‑хранилище и ротация.
• Бэкапим мусор. Решение: явные исключения (cache, tmp, сборочные артефакты), списки файлов.
• Отсутствуют версии и ретенция. Решение: политики lifecycle и регламенты хранения.

Когда звать экспертов и что мы делаем

Если RPO < 15 минут, сувенирные плагины и ручные дампы не помогут: нужна архитектура и автоматизация. Команда LightsOn проектирует и внедряет надёжные схемы бэкапов, пишет плейбуки восстановления, проводит DR‑учения и интегрирует мониторинг. Начать можно с Аудит и оптимизация сайта или сразу пойти в DevOps и инфраструктура — подберём решение под ваши RPO/RTO и бюджет.

Коротко по шагам (пример плана)

1. Зафиксировать RPO/RTO и критичные сценарии.
2. Описать, что бэкапить, где хранить, как шифровать.
3. Выбрать инструменты (restic/borg + xtrabackup/pg_basebackup + S3) и настроить расписания.
4. Включить offsite и иммутабельность.
5. Развернуть стенд восстановления и прогнать учение.
6. Настроить мониторинг/алерты и регламент ретенции.
7. Обновлять план после каждого релиза и постмортема.

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