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