Бэкап без теста восстановления — только надежда.
Две цели
RPO определяет потерю данных, RTO — длительность простоя
RPO — точка во времени, к которой должны восстановиться данные. RTO — целевой срок возвращения процесса или системы после сбоя.
Если база копируется раз в сутки, худшая потеря изменений близка к 24 часам: это фактический RPO, даже если в документе написано 15 минут. Если восстановление занимает шесть часов, обещание RTO 30 минут не подкреплено архитектурой.
Назначайте цели отдельно для каталога, заказов, файлов, CRM и аналитики. Статические изображения можно восстановить медленнее, чем оплаченные заказы.
Архитектура
Правило 3‑2‑1 и современное усиление
Базовая идея: иметь три копии данных, использовать два разных типа носителя или независимых контура и хранить одну копию вне основной площадки. Для защиты от вымогателя добавляют неизменяемую или офлайн‑копию и обязательную проверку восстановления.
База и файлы, которыми пользуется продуктивная система.
Версионная копия в отдельной учётной записи или хранилище.
Независимый регион/поставщик, ограниченный доступ, immutability или offline.
Регулярное восстановление в изолированный контур и протокол результата.
Два bucket в одной учётной записи с одним ключом — не независимость. Компрометация панели или ошибочный lifecycle может удалить оба.
Состав
Копируйте не только файлы и базу
- Дамп или согласованный снимок базы с проверкой целостности.
- Пользовательские файлы, закрытые документы и медиа.
- Конфигурация веб‑сервера, DNS, cron, очередей и контейнеров.
- Код или ссылка на воспроизводимый тег релиза.
- Секреты — в отдельной защищённой системе с процедурой восстановления.
- Список версий, лицензий и внешних интеграций.
- Инструкция, контакты и порядок переключения DNS/трафика.
Проверяйте согласованность: дамп базы и файлы одного заказа должны относиться к совместимому моменту. Иначе технически успешное восстановление создаст бизнес‑ошибки.
Защита
Бэкап содержит те же чувствительные данные, что и продуктив
Шифруйте передачу и хранение, разделяйте роли, включите MFA, запрещайте обычному приложению удалять архив, журналируйте операции и тестируйте оповещение о массовом удалении. Ключ шифрования не храните только рядом с копией.
Устанавливайте срок хранения по задачам восстановления и требованиям к данным. «Храним все ежедневные копии бессрочно» увеличивает стоимость и объём потенциальной утечки.
Если скомпрометированный администратор может изменить или удалить каждую копию, правило 3‑2‑1 формально выполнено, но задача восстановления — нет.
Учение
Как провести тест восстановления
- Выберите случайную дату и не предупреждайте исполнителя о конкретной копии заранее.
- Разверните чистое изолированное окружение.
- Восстановите конфигурацию, базу, файлы и секреты по инструкции.
- Проверьте вход, поиск, форму, заказ, загрузку и интеграции безопасными тестовыми данными.
- Измерьте время по этапам и фактическую точку данных.
- Зафиксируйте пробелы, владельцев и срок исправления.
Сопоставьте реальное время с финансовой моделью: потерянная маржа, зарплата простаивающей команды, SLA, восстановительные работы и репутационный эффект.
Последний протокол успешного теста важнее зелёной надписи «backup completed».
FAQ
Частые вопросы
Снимок VPS — это резервная копия?
Это полезный слой, но снимок в той же панели и на той же площадке не заменяет независимую внешнюю копию.
Как часто делать копии?
Частота выводится из RPO и интенсивности изменений. Если допустима потеря пяти минут заказов, суточный дамп не подходит.
Нужно ли копировать логи?
Ключевые журналы могут быть нужны для расследования, но их объём, чувствительность и сроки хранения планируются отдельно.
Как часто тестировать восстановление?
После значимых изменений и регулярно по критичности. Для коммерческого сайта разумен хотя бы квартальный сценарий, а критичные системы проверяются чаще.
Первоисточники
Документы и руководства
- NIST SP 800-34 Rev. 1 — RPO, RTO и планирование восстановления
- CISA StopRansomware Guide — offline/immutable copies и тестирование
- NIST Cybersecurity Framework 2.0 — функция Recover и управление риском
Дата проверки: 25 августа 2026. Нормы, ставки, интерфейсы ведомств и условия сервисов могут измениться. Перед юридически или финансово значимым решением сверьте актуальную редакцию первоисточника и обстоятельства вашей организации.
