Резервное копирование сайта и баз данных с гарантированным восстановлением

Бэкап — это не “файл где-то на хостинге”. Это управляемая система, которая гарантирует восстановление сайта и данных в нужный момент и в нужные сроки. Если бэкап нельзя восстановить быстро и предсказуемо — его нет.
Мы настраиваем резервное копирование так, чтобы оно выдерживало ошибки админов, сбои хостинга, обновления, взломы, шифровальщики и “случайно удалили базу”.

Когда услуга нужна прямо сейчас

• есть сайт/магазин/личный кабинет, и потеря данных = прямые убытки;
• обновляете CMS/модули/сервер — нужен гарантированный откат;
• данные меняются ежедневно (заказы, заявки, контент, пользователи);
• хостинг “делает бэкап”, но непонятно где он хранится и как восстанавливается;
• нужны контрольные точки восстановления и защита от взлома/шифровальщика.

Почему “бэкап у хостинга” не спасает

• Нет контроля RPO/RTO: как часто копируют и как быстро поднимут — неизвестно.
• Копия хранится там же: сгорел/упал аккаунт/сломали доступ — копии тоже нет.
• Нет тестовых восстановлений: бэкап может быть “успешный”, но нерабочий.
• Не копируют критичное: конфиги, cron, secrets, загрузки, объектные хранилища.

Что мы делаем

1) Проектируем систему под ваши риски

• определяем RPO (сколько данных можно потерять) и RTO (за сколько нужно восстановиться);
• фиксируем, что именно копируем: файлы, БД, медиа, конфиги, доступы, планировщики;
• выбираем стратегию: полные/инкрементальные/дифференциальные, частота и ротация.

2) Настраиваем резервное копирование сайта

• файлы проекта, пользовательские загрузки, критические конфиги;
• исключения из бэкапа (кэш, временные файлы) — чтобы копии были быстрыми и “чистыми”;
• контроль размера и ротации, чтобы хранилище не “взрывалось”.

3) Настраиваем резервное копирование базы данных

• консистентные дампы/снимки без “битых” транзакций;
• резервирование схем, ролей, прав и критичных параметров;
• PITR (Point-in-Time Recovery) там, где это оправдано: откат до конкретной минуты.

4) Хранение по правилу 3-2-1 и защита копий

• 3 копии, 2 разных типа носителя, 1 копия вне основного периметра;
• шифрование при хранении и передаче;
• минимальные права доступа к хранилищу (чтобы взлом сайта не удалил бэкапы).

5) Мониторинг и уведомления (чтобы вы узнавали о проблеме, а не “после”)

• мониторинг успешности бэкапов: выполнение, длительность, размер, ошибки;
• мониторинг доступности сайта/SSL (если требуется);
• уведомления о сбоях и регрессах (почта/мессенджер — по вашей схеме).

6) Тестовые восстановления и регламент

• плановые тестовые восстановления (самый важный пункт);
• инструкция восстановления “в 2 часа ночи”: порядок действий, точки, доступы;
• проверка целостности: сайт поднялся, логин работает, данные на месте.

KPI и измеримость

• RPO: гарантированная “глубина” потери данных (например, 15 мин / 1 час / 24 часа);
• RTO: реальное время восстановления (включая БД, файлы, конфиги);
• успешность бэкапов: % успешных запусков без ошибок;
• время реакции на сбой: SLA уведомлений;
• результаты тестового восстановления: “восстановилось / не восстановилось” — без самообмана.

Критерии “готово”

• определены и зафиксированы RPO/RTO под ваш проект;
• настроены бэкапы файлов + БД + критичных конфигов (а не “что-то одно”);
• копии хранятся по 3-2-1 и защищены от удаления при компрометации;
• включены уведомления о сбоях и аномалиях;
• проведено тестовое восстановление и оформлен регламент восстановления.

Что мы не делаем

• не оставляем “бэкап в той же папке на сервере” и не называем это защитой;
• не настраиваем копирование без проверки восстановления;
• не делаем “раз в месяц” там, где данные меняются каждый день;
• не храним ключи и доступы в том же месте, где лежит сайт.

Сроки и стоимость

Обычно: 1 день и от 8 000 ₽.
Итог зависит от объёма данных, типа БД, требований к RPO/RTO и схемы хранения (локально/облако/несколько площадок).