У любого, кто отвечает за данные, почти наверняка есть резервные копии. И почти наверняка они ни разу не разворачивались. Это не упрёк: копии создаются автоматически, журнал зелёный, место на диске расходуется — всё выглядит как работающая система.
Проблема в том, что «копия создаётся» и «из копии можно восстановиться» — разные утверждения. Узнать, что они разошлись, можно ровно в двух ситуациях: на учении или в аварии. Второе дороже.
Почему «скрипт вернул ноль» ничего не значит
Загрузка файла копии может завершиться успешно и записать на диск не данные, а текст ошибки. Получается файл, который существует, попадает в журнал, учитывается в отчёте — и подозрительно мало весит. Все формальные проверки пройдены. Узнаёте об этом при попытке восстановиться.
Поэтому первый уровень защиты — проверять не факт создания копии, а её пригодность:
- копия свежее суток;
- база данных действительно является базой и проходит проверку целостности;
- ключевые таблицы на месте и не пусты;
- каждый снимок векторного хранилища распаковывается и не подозрительно мал.
И самое важное: эту проверку тоже надо проверять. Мы гоняем её на четырёх видах намеренно испорченных копий — порченый снимок, битая база, недостающий снимок, устаревшая копия. Все четыре должны ловиться. Проверка, которую ни разу не видели ругающейся, неотличима от проверки, которая не работает.
Сами копии снимаются ежедневно, хранится семь поколений. Если в назначенное время машина была выключена, таймер догоняет пропущенный запуск, а не ждёт следующих суток.
И всё равно этого мало
Пригодная копия — ещё не восстановленная система. Поэтому 20 сентября 2026 года на стенде мы провели учение: развернули копию целиком и сравнили с боевыми данными.
Развернули в изолированный экземпляр хранилища, не трогая боевые данные. Это стоит сказать прямо: учение, которое рискует боевыми данными, — не учение, а авария по расписанию.
Три коллекции восстановились, число записей совпало точка в точку: 940, 414 и 1612. База переписки прошла проверку целостности, её содержимое по числу записей совпало с боевой. Копия содержала изменение, сделанное в тот же день, — то есть она была свежей, а не просто существовала.
Почему совпадения счётчиков мало
Совпавшие числа — приятный результат и слабое доказательство. Данные могли восстановиться «мёртвыми»: записи на месте, а поиск по ним не работает — например, если векторы повредились при переносе. Счётчик этого не увидит.
Поэтому отдельно проверили, что векторы живые. Точку из восстановленной коллекции взяли как поисковый запрос и посмотрели, что найдётся. Сама с собой она совпала с оценкой 1,0000, а ближайшими соседями оказались осмысленные фрагменты — те, которые и должны быть рядом.
Это тот же приём, что и в нашей проверке закладок в документах: недостаточно, чтобы проверка прошла, — надо убедиться, что она вообще способна не пройти. Две статьи, один метод.
Деталь, которая убеждает сильнее остального
В восстановленной базе нашлись две записи с нарушенными внешними связями. Без объяснения это звучит как дефект. Но ровно те же две записи есть и в боевой базе.
То есть копия воспроизвела боевую базу точно — вместе с её особенностями, а не «почистила» их по дороге. Именно это и требуется от копии: не улучшать, а повторять. Копия, которая молча исправляет данные, так же ненадёжна, как копия, которая их теряет, — просто это труднее заметить.
Что учение дало кроме галочки
Нашлась ошибка — не в копии, а в порядке восстановления. Каталог со снимками векторного хранилища нельзя подключать только для чтения: хранилище управляет им само и на старте падает. Выглядит это так, будто копия битая. В аварии такая диагностика стоила бы часов паники и, возможно, решения, что копии нет вовсе.
Это лучший аргумент в пользу учений: ошибка была в процедуре, и найти её можно было только попробовав. Теперь порядок оформлен скриптом — он поднимает изолированный экземпляр, сверяет данные, проверяет поиск и убирает за собой. Учение проводится после каждого изменения схемы хранения, как регламент, а не как разовая акция.
Восстановление доказывает, что данные переживут потерю. Оно ничего не говорит о том, что сервис не остановится: машина одна, резервной нет, и отказоустойчивости мы не заявляем. Копия защищает данные, а не доступность. И ещё: учение проведено один раз, на текущей схеме хранения. Многолетней статистики за ним нет — есть регламент.
Коротко
Копия, которую ни разу не разворачивали, — предположение, а не копия. Проверять стоит не факт создания, а пригодность, саму проверку — на заведомо испорченных копиях, а восстановление — разворачиванием в отдельный экземпляр с проверкой, что поиск по восстановленным данным работает.
Эта проверка и закладки в поддельном акте — про одно: систему надо проверять на том, чего от неё не ждёшь, а не только на том, ради чего её ставили.