Почему резервная копия без тестового восстановления может оказаться бесполезной
Факт создания копии не означает, что из неё поднимется сервис. Разбираем, что ломает восстановление, как устроена процедура проверки, что такое RPO и RTO и как вести журнал проверок.
«Резервные копии делаются» — это утверждение о процессе. «Сервис восстановится за два часа» — утверждение о результате. Между ними нет автоматической связи: копия может создаваться годами и не разворачиваться, когда понадобится.
Проверяется это единственным способом — восстановлением. Не проверкой галочки «задание выполнено успешно», а фактическим подъёмом сервиса из копии.
Что ломает восстановление
Задание может завершаться успешно годами, а копия при этом оставаться непригодной. Типичные причины:
| Причина | Почему не видно заранее | Как обнаружить |
|---|---|---|
| Повреждённый архив | Задание отчитывается об успехе: файл записан, содержимое не проверялось | Контрольная сумма и пробная распаковка |
| Копия неполная | Копируется база, но не конфигурация сервиса, или наоборот | Восстановление на чистый контур: не хватит того, чего нет |
| Отсутствуют ключи шифрования | Копия зашифрована, ключ лежит только на исходном сервере | Попытка восстановления на другой машине |
| Неверные права и владельцы файлов | Файлы восстановились, сервис не стартует | Проверка запуска приложения, а не наличия файлов |
| Потерянные зависимости | Нужны версия runtime, пакет или сертификат, которых нет в копии | Восстановление на чистую систему |
| Копия на том же диске, что и источник | Работает до отказа диска — то есть до момента, когда нужна | Проверка расположения хранилища |
| Задание давно не выполняется | Никто не смотрит на результат, ошибка молчит | Мониторинг времени последней успешной копии |
Резервная копия, из которой ни разу не восстанавливали, — это гипотеза, а не защита.
RPO и RTO: два числа, с которых всё начинается
Прежде чем настраивать копирование, нужно ответить на два вопроса. Они определяют и схему, и её стоимость.
| Показатель | Вопрос | На что влияет |
|---|---|---|
| RPO — допустимая потеря данных | Данные за какой период мы готовы потерять? | Частота копирования |
| RTO — допустимое время простоя | Сколько сервис может быть недоступен? | Способ хранения и процедура восстановления |
Пример. Если RPO — сутки, достаточно ночного копирования. Если RPO — час, нужны частые копии или журнал транзакций базы. Если RTO — четыре часа, копия может лежать в архиве; если полчаса — она должна быть готова к быстрому развёртыванию, а процедура — отработана.
Процедура тестового восстановления
Смысл процедуры — ответить на вопрос «копия существует, но восстановится ли из неё сервис». Восстановление выполняется на отдельном контуре, результат проверяется по данным и работоспособности приложения, итог фиксируется.
Шаг 1
Подготовить изолированный контур
Отдельная виртуальная машина или сеть, не связанная с боевой средой. Проверка не должна затрагивать рабочие данные и адреса.
Шаг 2
Восстановить из копии, а не из источника
Только то, что есть в архиве. Если чего-то не хватает — это и есть найденная проблема, а не повод «доложить руками».
Шаг 3
Запустить сервис
Не «файлы на месте», а приложение стартовало и отвечает. Большинство проблем с правами и зависимостями видны именно здесь.
Шаг 4
Проверить данные
Открыть несколько записей, сверить количество, проверить свежесть последней. Пустая база, которая запустилась, — тоже провал теста.
Шаг 5
Замерить время
Сколько заняло восстановление целиком. Это фактическое RTO, а не то, которое записано в документе.
Шаг 6
Зафиксировать результат
Дата, что восстанавливали, сколько заняло, что пошло не так, что исправлено.
Шаг 7
Удалить тестовый контур
Иначе через полгода он превратится в неучтённую систему с копией боевых данных.
Как часто проверять
Периодичность зависит от важности сервиса и от того, как часто меняется его окружение. Разумный ориентир:
| Тип системы | Периодичность проверки | Дополнительно |
|---|---|---|
| Критичные для работы компании | Ежеквартально | Обязательно после крупного обновления |
| Важные, но с допустимым простоем | Раз в полгода | После смены схемы хранения |
| Вспомогательные | Раз в год | Достаточно выборочной проверки |
Отдельное правило: проверка обязательна после любого изменения в самой схеме копирования, при смене версии СУБД и при переносе хранилища. Именно эти события чаще всего незаметно ломают восстановление.
Журнал проверок
Без записи результата проверка теряет половину смысла: через полгода никто не помнит, что и когда восстанавливали. Минимальный формат:
Дата: 2026-__-__
Что восстанавливали: сервис / база / файловый ресурс
Из копии от: дата копии
Куда: изолированный тестовый контур
Время до старта: __ мин (фактическое RTO)
Данные проверены: да / нет, чем именно
Результат: успешно / с замечаниями / неудача
Найденные проблемы: ______________________________
Что исправлено: ______________________________
Следующая проверка: 2026-__-__Что должно быть настроено помимо самих копий
- Хранение отдельно от источника. Копия на том же диске защищает только от ошибочного удаления файла, но не от отказа диска.
- Ротация по сроку хранения. Иначе место кончается, и задания начинают падать — обычно в самый неподходящий момент.
- Уведомление о результате. Состояние должно быть видно без захода на сервер. Молчащая система неотличима от сломанной.
- Контроль времени последней успешной копии. Отдельная проверка в мониторинге: она ловит случай, когда задание перестало запускаться вовсе.
- Копия конфигурации, а не только данных. Восстановить базу без настроек сервиса — это половина работы.
- Хранение ключей шифрования отдельно от копий и от исходного сервера.
Последние два пункта — самые частые находки при первом же тестовом восстановлении.
Чек-лист
- Определены RPO и RTO, согласованы с бизнесом.
- Копии хранятся отдельно от источника.
- Настроена ротация по сроку хранения.
- Результат каждого задания виден без захода на сервер.
- Мониторинг контролирует время последней успешной копии.
- Копируются данные и конфигурация.
- Ключи шифрования хранятся отдельно и доступны при восстановлении.
- Проведено тестовое восстановление на изолированном контуре.
- Замерено фактическое время восстановления.
- Результат записан в журнал, назначена дата следующей проверки.
Контроль времени последней успешной копии — часть более общей задачи: что должен контролировать мониторинг кроме доступности. Про резервное копирование конфигураций публикации сервисов — в материале о размещении сервисов за одним внешним адресом.