Резервную копию сайта проверяют восстановлением в отдельной среде и прохождением основных сценариев. Статус «копирование завершено» подтверждает работу задания, но не показывает, что приложение запустится с нужными данными. Результат проверки должен включать состав восстановленного сайта, время и найденные ограничения.
Для бизнеса полезны два ориентира: сколько данных допустимо потерять и за какое время нужно вернуть работу. Они определяют требования к копиям и процессу восстановления.
Два вопроса владельцу сайта
RPO обозначает целевую точку восстановления, то есть допустимый объём потери данных, выраженный через время. RTO задаёт целевое время восстановления. Термины рассматриваются в руководстве NIST по планированию восстановления. Здесь они используются как инженерные ориентиры для обсуждения с подрядчиком.
Условный пример: копия сделана в 02:00, сбой произошёл в 10:00. В ней может не оказаться изменений за последующие восемь часов. Насколько это приемлемо, зависит от данных: новых статей, заказов, файлов и операций.
Ежедневное расписание само по себе не доказывает достижение RPO. Нужно учитывать успешность копии, длительность операции и способ получения согласованного состояния. Фактическое время возвращения работы сравнивают с RTO после теста или инцидента.
Что должно входить в восстановление
| Компонент | Почему нужен | Как проверить |
|---|---|---|
| База данных | Заявки, пользователи, настройки | Контрольные записи и связи |
| Загруженные файлы | Документы и изображения | Открытие выборки файлов |
| Код и версия приложения | Совместимость со структурой базы | Запуск нужной версии |
| Конфигурация окружения | Подключения и пути | Инвентаризация без раскрытия секретов |
| Зависимости | Работа сборки и служб | Воспроизводимая установка |
| Доступы и процедура | Возможность начать восстановление | Ответственный получает нужный доступ |
Не записывайте пароли в общий протокол. Укажите защищённое место хранения и порядок получения доступа. Копия, которую способен открыть только отсутствующий подрядчик, создаёт отдельную зависимость.
Файлы и база должны соответствовать выбранной точке восстановления. Если запись о документе есть, а сам файл отсутствует, интерфейс может открыться с ошибкой. Такой дефект проверяют отдельно.
Способ копирования зависит от системы
В документации PostgreSQL описаны разные подходы: SQL-выгрузка, копирование файлов и непрерывное архивирование. Для вашего приложения метод выбирают с учётом версии, объёма и нужной точки восстановления.
Например, pg_dump создаёт согласованную выгрузку PostgreSQL. Эта согласованность относится к базе в рамках описанного метода. Она не означает автоматического согласования базы с отдельным хранилищем документов или внешней CRM.
Не копируйте живые файлы базы произвольной командой, полагаясь на размер архива. Пусть специалист определит корректный способ и проверит его восстановлением. Инструкция должна соответствовать конкретной системе и версии.
Подготовьте изолированный тест
Рекомендуем отдельную среду без доступа реальных посетителей. До запуска отключите отправку клиентских сообщений, боевые платежи и внешние действия. Тестовое восстановление не должно повторно отправлять старые заявки или письма.
Проверьте сетевые разрешения и задания по расписанию. Старый код может автоматически включить рассылку сразу после старта. Используйте тестовые ключи, заглушки и ограниченные права там, где это подходит архитектуре.
Если копия содержит реальные пользовательские данные, до теста проверьте правовое основание обработки, круг доступа, срок хранения и условия использования тестовой среды. Техническая изоляция сама по себе не является заключением о выполнении всех требований к обработке данных.
Назначьте дату, ответственного за выполнение и человека, который проверит бизнес-сценарии. Зафиксируйте копию и версию приложения. Измеряйте время от согласованного начала процедуры, включая подготовку инфраструктуры и получение доступа.
Проверьте работоспособность по сценариям
Откройте главную и внутреннюю страницу. Найдите контрольную запись с известной датой. Проверьте вход тестового пользователя, поиск, просмотр документа и сохранение новой тестовой записи. Для магазина добавьте тестовый заказ, для сайта услуг проверьте форму без отправки реальному менеджеру.
Сравните выборку данных с ожидаемым состоянием. Количество строк помогает обнаружить крупную потерю, но не доказывает правильность каждой связи. Полезны контрольные суммы файлов и выборочная проверка содержимого, подобранная под систему.
Если требуется восстановление на определённый момент, проверьте именно его. PostgreSQL описывает восстановление на момент времени с базовой копией и архивом журналов. Наличие только одного из компонентов не равно готовой процедуре.
Протокол, который можно принять
Запишите: какая копия использована, что вошло в неё, где проходил тест, сколько времени заняли этапы, какие сценарии выполнены и какие ошибки обнаружены. Для каждого дефекта укажите ответственного и следующий тест после исправления.
Условная запись: «Страницы и база восстановлены за 42 минуты. Два контрольных документа не открылись. Отправка уведомлений заблокирована. Требуется исправить копирование файлов и повторить проверку». Такой результат не позволяет объявить восстановление полностью готовым, зато точно показывает оставшуюся работу.
После изменения архитектуры, базы, хранилища или процедуры проведите новый тест. Интервал плановых проверок выбирайте по критичности и частоте изменений. Успешный прошлый тест подтверждает проверенный сценарий на ту дату.
Обсудите с подрядчиком, кто принимает решение о боевом восстановлении и кто проверяет результат. Рекомендуем включить процедуру резервного копирования, доступы и инструкцию восстановления в согласованный состав передачи проекта. Смежные вопросы разобраны в статье о выборе подрядчика.
Источники
- NIST SP 800-34 Rev. 1, RPO, RTO и планирование проверок.
- PostgreSQL: резервирование, разные методы.
- PostgreSQL: SQL dump, согласованная выгрузка базы.
- PostgreSQL: PITR, восстановление на выбранный момент.