Резервные копии — это страховка бизнеса. Пока всё работает, кажется, что копии не нужны, но один сбой диска, обновление плагина с багом, удаление таблицы или взлом — и сайт превращается в набор ошибок. Бэкап позволяет вернуться в рабочую точку за минуты или часы вместо недельных простоев. Ключ к «безболевым» бэкапам — простая и автоматизированная схема, понятные цели (RPO/RTO), регулярные тесты восстановления и ответственность команды. В этом материале — практический чек‑лист Unihost: от выбора стратегии 3-2-1 до расписания, шифрования и контроля статуса.
Что именно нужно резервировать
Бэкап — это не только папка с файлами сайта. Чтобы восстановиться быстро и корректно, фиксируйте:
- Файлы приложения: темы, плагины, загрузки, статические ресурсы (uploads).
- Базы данных: MySQL/MariaDB (mysqldump/Percona XtraBackup), PostgreSQL (pg_dump/pg_basebackup).
- Конфигурации: web‑server (Nginx/Apache), PHP‑пулы, конфиги CMS, env‑переменные.
- Секреты и ключи: .env, конфиги интеграций, токены (хранить отдельно и шифровать).
- Инфраструктуру: IaC (Terraform/Ansible), Docker compose, версии образов/контейнеров.
- План и инструкции восстановления: кто что делает, где лежат копии, логины/ключи.
Если чего‑то из списка нет — восстановление затянется или окажется невозможным.
RPO и RTO «на пальцах»
RPO (Recovery Point Objective) — сколько данных вы готовы потерять при аварии. Например, RPO=1 час означает, что мы можем потерять не более часа изменений. RTO (Recovery Time Objective) — за какое время вы обязуетесь поднять систему. Например, RTO=2 часа: через 2 часа сайт должен работать.
Пример: интернет‑магазин с 500 заказами в день. Если RPO=30 минут, то вы делаете бэкапы БД минимум каждые 30 минут или используете репликацию/журналы транзакций. Если RTO=1 час, у вас готова процедура восстановления: скрипт развертывания файлов, импорт БД, переключение DNS/балансировщика. Любая стратегия бэкапа должна быть привязана к RPO/RTO.
Правило 3-2-1 и «3-2-1-1-0»
Классика: 3 копии, 2 разных носителя, 1 копия вне площадки. Это минимальный стандарт, чтобы один сбой не уничтожил всё. Расширение «3-2-1-1-0»: добавьте 1 офлайн/immutable копию (например, объектное хранилище с версионированием и блокировкой изменений) и цель «0 ошибок» при регулярной проверке восстановления.
Минимальная схема для сайта:
- Ежедневная копия на том же сервере (быстрое локальное восстановление).
- Копия в другом дата‑центре/регионе (offsite).
- Недельный/месячный архив в объектном хранилище с версионированием и полисом «immutable» на 7–30 дней.
Типы бэкапов: что выбрать
- Полный бэкап — каждый раз копируется всё. Просто, но долго и дорого по хранилищу.
- Инкрементальный — копируются изменения с последнего бэкапа. Быстро, экономит место, но цепочки длиннее.
- Дифференциальный — копируются изменения с момента последнего полного бэкапа. Компромисс по скорости/объёму.
Практика: раз в неделю — полный, ежедневно — инкрементальные. Для высоконагруженных БД — журналирование и снапшоты томов.
Где хранить: локально, offsite, объектное хранилище
- Локально (тот же сервер/хост): удобно для быстрых откатов; риск — единая точка отказа.
- Offsite (другой сервер/ЦОД): защищает от аварий площадки; потребует сети и политики доступа.
- Объектное хранилище (S3‑совместимое): дешево в пересчёте на гигабайт, есть версионирование и lifecycle‑политики. Используйте отдельный доступ (Access Key/Secret) строго с правами только на нужный бакет и префикс.
Инструменты и подходы
- Панели (cPanel/DirectAdmin/ISPmanager): встроенные бэкапы файлов и БД по расписанию, выгрузка на удалённый storage/SFTP.
- Снапшоты: на уровне гипервизора или LVM/ZFS — быстрые, удобны для «точки во времени», но это не замена файловым бэкапам.
- Rsync/Rclone: простые инкрементальные копии по SSH, синхронизация с объектным хранилищем.
- Borg/Restic: дедупликация, шифрование, проверка целостности, хранение в S3/SFTP/локально.
- Для БД: mysqldump/Percona XtraBackup (горячие копии), pg_dump/pg_basebackup; учитывайте блокировки и консистентность.
- CMS‑плагины: подходят для WordPress/Drupal, но лучше комбинировать с внешним хранилищем и базовым системным бэкапом.
Шифрование и управление доступом
Шифруйте бэкапы, особенно если храните их вне сервера. Для borg/restic шифрование включено из коробки; для архива — используйте надежные алгоритмы.
Доступы: создайте отдельные сервисные учётные записи для бэкапа с минимальными правами. Ключи и пароли храните в менеджерах секретов, а не в скриптах.
Ведите журнал доступа к бэкапам и скачиваниям, включите 2FA там, где это возможно.
Расписание и ретенция: реальный пример
Пример политики для корпоративного сайта:
- Файлы приложения: ежесуточно инкрементально, еженедельно — полный; хранение 14/60 дней.
- БД: снимки каждые 30 минут (binlog/archivelog), ежедневный полный дамп; хранение 7/30/90 дней по схеме GFS (ежедневные/недельные/месячные).
- Объектное хранилище: включено версионирование, lifecycle удаляет старше 90 дней; ежемесячный архив помечается immutable на 30 дней.
- Отдельный офлайн‑архив ключевых релизов (например, перед крупными изменениями).
Проверка и тест восстановления
Бэкап, который не восстанавливается, — не бэкап. Раз в месяц выполняйте DR‑тренировку: разворачивайте стенд из копий, фиксируйте время, лимит RTO и список шагов.
Автоматизируйте проверки: контроль целостности архивов, проверка хеша, тест восстановления выборочных файлов и дампов БД.
По результатам обновляйте инструкции и при необходимости политику ретенции.
Мониторинг и оповещения
Система бэкапа должна сама сообщать о проблемах: не прошёл дамп, закончился диск, не доступен бакет, просрочен ключ. Отправляйте отчёты в почту/мессенджер/Alertmanager, храните логи, ставьте SLA на время реакции.
Чек‑лист Unihost: пошаговая настройка
- Зафиксируйте RPO/RTO для сайта/подсистем: контент, БД, файлы, медиатека.
- Выберите схему 3-2-1 (или 3-2-1-1-0) и площадки хранения.
- Настройте инструменты: панель/скрипты/rsync/borg/restic/Cert‑хранилище S3.
- Пропишите расписание и ретенцию (GFS), опишите роли ответственных.
- Включите шифрование и сегрегацию доступов, заведите сервисные учётки/ключи.
- Включите мониторинг и алерты; ежедневно получайте отчёты о статусе бэкапа.
- Проведите первый тест восстановления и задокументируйте шаги.
- Перед каждым крупным релизом — внеплановый полный бэкап и точка восстановления.
- Ежеквартально — DR‑дрили и ревизия политики хранения.
- Обучите команду: где хранятся копии, кто дежурный, как эскалировать.
Особые случаи и советы
- E‑commerce и CRM: обеспечьте консистентность транзакций — используйте «горячие» копии БД или краткие окна блокировок.
- Большие медиа: вынесите на CDN/Object Storage и резервируйте метаданные/индексы отдельно.
- Плагины и кастомный код: перед обновлениями делайте снапшот и полный бэкап, ведите CHANGELOG.
- Мультисайты/тенанты: изолируйте бэкапы на уровне префиксов и прав доступа в бакете.
- Логи и аудит: бэкапьте только критичные; хранение логов регулируйте юридическими требованиями.
FAQ
В: Сколько хранить бэкапы?
О: Зависит от регуляций и бюджета. Часто — 14/60/90 дней по GFS, плюс офлайн‑архивы релизов.
В: Бэкап — это то же самое, что репликация?
О: Нет. Репликация может утащить ошибку на слейв; бэкап — снимок состояния во времени.
В: Как быть с «заражёнными» копиями?
О: Иммутабельная политика и версияция бакета помогают откатиться к «чистой» версии.
В: Что делать при нехватке места?
О: Включить дедупликацию/сжатие (borg/restic), пересмотреть ретенцию, вынести в объектное хранилище.
В: Кто отвечает за бэкапы?
О: Назначьте владельца процесса и дежурных.
Вывод и следующий шаг
Боль от потери данных неизмеримо дороже настройки копий. Внедрите простую схему 3-2-1, автоматизируйте бэкапы файлов и БД, включите шифрование, мониторинг и регулярные тесты восстановления. Команда Unihost поможет подобрать инфраструктуру, настроить расписание и политики хранения, а также проверить восстановление, чтобы при любой аварии вы вернулись в строй в рамках заявленных RPO/RTO.