Восстановление базы из копии: что включить в приёмочный протокол
Проверка цепочки резервных копий и запуска приложения в изолированной среде.
Выберите проверяемую точку восстановления
Покупка хранилища для резервных копий должна заканчиваться проверкой восстановления нужного сервиса. Согласуйте с владельцем приложения дату и время контрольной точки, допустимую потерю последних изменений и срок возвращения к работе. Для проверки выберите известный набор записей или операций, которые должны присутствовать после восстановления. Не заменяйте их фактом, что файл резервной копии существует.
Запишите название и версию СУБД, версию приложения, метод создания копии и состав необходимых файлов. Если резервное копирование выполняют несколько систем, укажите, какая из них отвечает за согласованную точку. Это позволит найти недостающие зависимости до закупки дополнительных накопителей или серверов.
Соберите цепочку и зависимости
Для SQL Server в полной модели восстановления последовательность может включать копию данных и последующие копии журналов транзакций. Состав цепочки зависит от выбранной точки и ранее созданных копий; его определяют по документации СУБД и настройкам резервирования. Универсальное правило «достаточно последнего файла» здесь непригодно.
Вместе с данными проверьте доступность необходимых ключей, разрешений, настроек приложения и поддерживаемой версии среды восстановления. Ответственные за эти компоненты могут быть разными людьми. Составьте список зависимостей с местом хранения и порядком получения доступа, сохраняя секреты в предназначенном для них хранилище, а не в самом протоколе или письме поставщику.
Подготовьте изолированный стенд
Восстановление проводят на согласованном тестовом сервере, не поверх действующей базы. Заранее исключите нежелательные подключения к рабочим интеграциям: автоматические письма, платежные действия, обмен с внешними системами и задания по расписанию. Определите, кто подтверждает изоляцию и кто имеет право остановить испытание.
Копии производственных данных могут содержать сведения с ограниченным доступом. Применяйте согласованную процедуру доступа и удаления тестовой среды после проверки. Для самого протокола достаточно обезличенных контрольных результатов. Не нужно включать в него содержимое клиентских записей, пароли, ключи или полный дамп базы.
Измеряйте весь путь до готового приложения
Время восстановления отсчитывайте от согласованного начала процесса до проверенной готовности сервиса. Раздельно отметьте получение файлов, подготовку среды, восстановление данных и проверку приложения. Быстрое копирование на диск не доказывает, что пользователи смогут работать в требуемый срок.
После штатного восстановления выполните предусмотренные для СУБД проверки целостности и контрольные операции приложения. Для SQL Server используйте подходящую документированную процедуру, включая DBCC CHECKDB по согласованной программе проверки. Успешная проверка структуры не подменяет прикладную сверку: нужны и контрольные записи, и разрешённые действия пользователя в тестовой среде.
Зафиксируйте результат и остаточные вопросы
В протоколе укажите идентификаторы копий, выбранную точку, версии компонентов, длительность этапов, контрольный набор и обнаруженные ошибки. Каждое замечание свяжите с ответственным и действием: отсутствующий журнал, неподходящая версия, недостаточная скорость репозитория или зависимость от недоступного ключа. Так результат становится основанием для изменения проекта.
Определите, когда повторять испытание: после существенного изменения приложения, способа резервирования или среды восстановления. Согласуйте периодические проверки отдельно от закупки оборудования. Для предложения поставщику передавайте объёмы и измеренные узкие места из протокола; это поможет выбрать хранилище по реальному сценарию, не обещая заранее универсальное время восстановления любой базы.