Резервные копии есть, а данные потеряли: как проверить восстановление

На сервере каждую ночь выполняется резервное копирование. В отчёте стоят зелёные отметки, свободное место ещё есть, подрядчик уверяет, что всё настроено. А потом пропадает база, удаляется папка с документами или после обновления перестаёт запускаться сайт. Выясняется, что архив есть, но восстановить из него рабочий сервис не получается.

Такое возможно без какого-либо сложного сбоя. Резервное копирование и восстановление – разные операции. Первая создаёт копию, вторая должна вернуть данные и саму возможность работать. Проверять стоит именно вторую.

Почему успешный бэкап ещё не означает успешное восстановление

Программа резервного копирования обычно подтверждает, что завершила свою задачу: записала архив, загрузила объекты в хранилище или создала снимок диска. Но этот отчёт не всегда отвечает на более важные вопросы. Есть ли в копии нужная база? Согласованы ли данные? Сохранились ли конфигурация сервиса и права? Есть ли доступ к ключам шифрования?

Типичная ловушка – копируется каталог сайта, но забыта база данных. Или архив с базой выгружается, но содержит ошибку и ни разу не открывался в настоящем сервере БД. Ещё один вариант: данные целы, а инструкция по запуску приложения, секреты подключения и необходимые версии программ остались только на потерянной машине.

Поэтому ответ «резервные копии есть» полезен лишь наполовину. Вторая половина – подтверждённый результат тестового восстановления.

Какие ошибки чаще всего обнаруживаются слишком поздно

• Копируется не всё. В архиве есть файлы, но нет базы, вложений, сертификатов или нужной конфигурации.
• Копия повреждена или неполна. Система поставила отметку об успехе, а архив распаковывается с ошибкой или не содержит последних частей данных.
• Точка восстановления слишком старая. Копии формально есть, но нужные изменения произошли позднее.
• Нет ключей и доступов. Зашифрованный архив остался, а пароль, ключ или учётные данные для получения копии недоступны.
• Зависимость от исходного сервера. Единственные копии лежат рядом с рабочими данными или доступны тем же учётным записям.
• Некому и нечем восстанавливать. Не подготовлена тестовая площадка, отсутствует инструкция, неясно, кому звонить при сбое.

Часть проблем обнаруживается простым осмотром настроек. Но проверить, что сервис действительно запустится, можно только восстановив его в другой среде и выполнив осмысленные проверки.

Первый шаг: убедиться, что копия доступна независимо от сервера

Начните с места хранения. Выберите свежую точку восстановления и попробуйте получить её с отдельного устройства, используя тот порядок действий, который понадобится при аварии. Если копию можно открыть только с работающего сервера, этот сценарий слишком хрупкий.

Проверьте срок хранения и доступ к ключам. Цель – убедиться, что архив достижим, а доступы к нему не зависят от единственной потерянной машины.

Что стоит проверить отдельно

Посмотрите, не являются ли несколько «разных копий» всего лишь файлами на одном физическом диске или в одном аккаунте без разграничения прав. Если сбой, ошибочное удаление или недоступность помещения затронет всё место хранения, выбор нужного архива уже не поможет.

Само по себе количество копий ничего не говорит о результате. Для бизнес-критичных данных важно заранее понимать, какая из копий переживёт проблему с основной площадкой и как быстро её можно будет получить.

Второй шаг: восстановить данные в безопасной тестовой среде

Не проверяйте архив поверх работающей базы или текущего сайта. Подготовьте отдельную виртуальную машину, тестовый сервер либо изолированный контейнер со своими портами, дисками и учётными записями. Восстановление не должно изменять рабочие данные или отправлять настоящим клиентам уведомления, письма и сообщения.

Для файлового архива тест может начинаться с восстановления выбранной папки и проверки нескольких документов. Для сайта нужен запуск его тестовой копии. Для PostgreSQL или MySQL лучше выполнить восстановление в отдельный экземпляр СУБД и убедиться, что таблицы читаются, необходимые записи на месте, а приложение может подключиться. Обычная успешная распаковка архива такую проверку не заменяет.

После запуска тестового сервиса проверьте не только главную страницу или подключение к базе. Попробуйте открыть несколько реальных разделов, найти документы, выполнить безопасную тестовую операцию, убедиться в целостности связей и вложений. Для интеграций отключите реальные отправки наружу.

Третий шаг: доказать, что восстановленный сервис пригоден для работы

Успешный запуск – только начало. Инженер должен проверить данные, а ответственный сотрудник – сценарии, ради которых система существует. Например, открываются ли нужные заказы в CRM и доступны ли последние загруженные договоры.

Результат теста фиксируют отдельно: что удалось восстановить, какая точка использована, что не открылось и сколько заняла работа.

Не забывайте о версиях и зависимостях

Приложение может требовать определённой версии базы, модулей, пакетов ОС или файлов конфигурации. Поэтому стоит сохранить список компонентов и порядок их запуска. Если для восстановления требуется бывший подрядчик с единственным паролем, проверка выявила проблему, даже когда сама база успешно открылась.

Полезно повторять тест при изменении инфраструктуры: после переноса сервиса, замены способа создания копий, крупного обновления или изменения состава данных. Периодичность обычных проверок подбирают под критичность сервиса и скорость изменения данных.

Как понять, сколько данных и времени бизнес готов потерять

До теста определите два ориентира. RPO – насколько старую точку восстановления бизнес ещё может принять. RTO – сколько времени допустимо тратить до возобновления работы сервиса. Это не обещания подрядчика, а требования, которые проверяются на реальном сценарии.

Условный пример: если резервная копия делается раз в сутки, между последним сохранённым состоянием и аварией могут оказаться изменения за значительную часть дня. Если восстановление архива занимает несколько часов, для срочной обработки заказов это может быть слишком долго. В такой ситуации нужно менять частоту создания копий, способ хранения или сам план восстановления.

Не пытайтесь оценивать сроки по размеру архива на глаз. Время зависит от загрузки копии, пропускной способности канала, скорости дисков, объёма базы, проверки и последовательности запуска сервисов.

Минимальный протокол тестового восстановления

• Что проверяли: название сервиса, его окружение и перечень критичных данных.
• Какая копия: дата и время точки восстановления, место хранения и способ получения.
• Как восстановили: последовательность действий и используемые средства, без записи секретов в открытый документ.
• Что проверили: запуск, таблицы или документы, вложения, права, тестовый сценарий работы.
• Что получилось: недостающие данные, ошибки, фактическое время и принятые исправления.
• Кто отвечает: владелец процесса, исполнитель теста и дата следующей проверки.

Такой протокол занимает меньше сил, чем попытка восстановить по памяти всю последовательность действий во время аварии. И он помогает отличить технически созданную копию от действительно проверенного сценария возврата к работе.

Что сделать на этой неделе

Выберите один важный сервис, найдите его свежую резервную копию и договоритесь о безопасном тестовом восстановлении. Не обязательно сразу проверять все серверы. Гораздо полезнее один раз пройти путь до работающего результата, записать слабые места и только после этого расширять проверки на остальную инфраструктуру.

Если собственных специалистов для такой работы нет, в Феерично Digital можно обсудить организацию резервного копирования и проверку восстановления. Главное – заранее согласовать состав данных, место хранения, порядок теста и ответственного за результат.