Как держать резервные копии LLM-контура в стране?

Резервная копия LLM-контура считается рабочей только тогда, когда вы можете поднять приложение в разрешенной территории, расшифровать данные штатным способом и получить прежнее поведение там, где оно должно быть прежним. Архив с несколькими папками в объектном хранилище для этого не годится. Он может содержать терабайты данных и все равно не позволить восстановить поиск, права доступа, тонко настроенную модель или аудит.

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

Копировать нужно не сервисы, а состояние, от которого зависит ответ

LLM-приложение редко состоит из одной модели и одной базы данных. Пользовательский ответ появляется из цепочки: запрос проходит аутентификацию, правила фильтрации, поиск по знаниям, сборку контекста, вызов модели, модерацию и журналирование. Восстановить Kubernetes-манифесты без данных этой цепочки означает восстановить пустую оболочку.

Разделите артефакты по тому, как их можно вернуть:

• первичные данные: исходные документы, структурированные записи, медиа, настройки доступа и согласия;
• производные данные: чанки, эмбеддинги, векторные индексы, кеши, результаты извлечения и переобученные словари;
• исполняемое состояние: checkpoints, токенизаторы, LoRA-адаптеры, конфигурация инференса, образы и шаблоны промптов;
• доказательное состояние: аудит-логи, события доступа, версии политик, журналы конвейеров и результаты оценок;
• криптографическое состояние: ключи, версии ключей, политики доступа, цепочки сертификатов и параметры KMS или HSM.

Эти группы имеют разные RPO и RTO. Потеря кэша на шесть часов обычно неприятна, но терпима. Потеря журнала согласий, последней версии ACL или ключа для действующего архива может остановить сервис полностью. Не назначайте единый период резервирования «для всего LLM». Он скрывает именно те зависимости, которые потом ломают восстановление.

Полезный минимальный реестр выглядит так:

artifact: knowledge-search-prod
owner: ml-platform
classification: confidential
territory: KZ
source_of_truth: postgres-documents
rebuildable: true
rpo: 30m
rto: 4h
backup:
  primary_copy: kz-dc-a
  recovery_copy: kz-dc-b
  encryption_key: kms://kz-hsm/keys/rag-prod-backup-v7
restore_dependencies:
  - document-store
  - embedding-model-qwen3-embedding-8b@sha256:...
  - chunker-config@2026-07-01
  - acl-schema@v4
validation:
  - checksum
  - filtered-search-smoke-test
  - access-denial-test

Это не бюрократия ради таблицы. Строка rebuildable: true заставляет владельца ответить на неудобный вопрос: из каких именно данных и с какой версией эмбеддингов он пересоберет индекс. Если на этот вопрос нет точного ответа, индекс надо сохранять как самостоятельный артефакт.

Векторная база без корпуса и версии эмбеддингов не восстанавливает поиск

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

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

Для каждого production-индекса фиксируйте в манифесте как минимум:

{
  "collection": "support-kz-ru",
  "snapshot_time": "2026-07-23T02:30:00Z",
  "embedding_model": "approved-embedding-model",
  "embedding_revision": "sha256:9d4...",
  "dimension": 3072,
  "distance": "cosine",
  "chunking": {
    "parser": "[email protected]",
    "max_tokens": 700,
    "overlap_tokens": 100
  },
  "payload_schema": "acl-payload@v4",
  "source_cursor": "documents:842771",
  "checksum": "sha256:..."
}

Не подменяйте контрольную сумму тестом «коллекция открылась». Индекс может открыться, но потерять часть сегментов, фильтры или метаданные. После восстановления выполните фиксированный набор запросов: обычный поиск, поиск с фильтром по подразделению, запрос от пользователя без права на документ и запрос к удаленному документу. Ожидаемым результатом последнего теста часто должен быть пустой ответ. Именно он показывает, что вы не восстановили утечку вместе с данными.

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

Checkpoint нельзя отделять от его семейства файлов

Файл весом в десятки гигабайт, названный final-v3, почти никогда не является восстанавливаемой моделью. Чтобы запустить checkpoint предсказуемо, нужны точная ревизия базовой модели, токенизатор, конфигурация архитектуры, chat template, параметры квантования и версия движка инференса. Для адаптеров добавляются тип адаптера, целевые слои и совместимость с базовой моделью.

Чаще всего команда теряет не сами веса. Веса лежат в хранилище, а исчезает файл конфигурации, образ рантайма или точный идентификатор базового checkpoint. Через полгода кто-то подставляет «почти ту же» модель и получает отличия в следовании инструкциям, вызовах инструментов, длине контекста или языке ответа. Такая авария плохо заметна: сервис отвечает, но бизнес-процесс уже другой.

Собирайте модельный пакет как неизменяемый объект:

models/
  legal-assistant-2026-06/
    manifest.json
    base-model-ref.txt
    adapter.safetensors
    adapter_config.json
    tokenizer/
    generation-policy.yaml
    evaluation-baseline.jsonl
    signatures.sha256

manifest.json должен содержать идентификаторы и хеши файлов, но не секреты. В generation-policy.yaml положите параметры, которые меняют наблюдаемое поведение: temperature, top_p, ограничение длины, системный промпт, шаблон сообщений, перечень разрешенных инструментов и правила принудительного выбора инструмента.

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

Логи нужно делить на аудит, диагностику и сырой текст

Логи LLM-сервисов быстро становятся самым опасным и самым недооцененным архивом. В них попадают промпты, документы из retrieval, заголовки запросов, фрагменты ответов, номера договоров, адреса, токены доступа и сообщения об ошибках. Простое правило «сохраняем все для расследований» дает вам еще одну копию чувствительных данных без ясного срока хранения.

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

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

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

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

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

Ключи шифрования переживают бэкап только при отдельном плане

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

NIST SP 800-34 прямо связывает резервирование шифрованных данных с управлением криптографическими ключами: на новой или замененной системе должны оказаться и программное обеспечение, и ключевой материал, необходимые для чтения копии. Для LLM-контура это стоит понимать шире. Восстановление требует не только секретного значения, но и политики, версии ключа, прав аварийной роли, сертификатов сервисов и процедуры доступа к HSM или KMS.

Рабочая схема часто выглядит так:

1. Сервис генерирует отдельный DEK для каждого архива или набора архивов.
2. Сервис шифрует данные DEK, а затем шифрует сам DEK ключом KEK из локального KMS или HSM.
3. В архив попадают шифртекст, зашифрованный DEK, идентификатор версии KEK и манифест целостности.
4. Политика KMS, журнал операций и аварийная роль резервируются отдельно в разрешенной территории.
5. Для расшифровки нужны как минимум два контролируемых действия: доступ к архиву и разрешение на использование KEK.

Не копируйте экспортируемый корневой ключ в тот же архив «на всякий случай». Если правила и устройство допускают экспорт, сделайте защищенную офлайн-копию по отдельной процедуре с разделением полномочий. Если ключ неэкспортируемый, резервируйте конфигурацию и механизм восстановления самого HSM или KMS в пределах территории. В обоих случаях проверяйте процедуру на тестовом ключе. Документ, который никто не исполнял, не является планом восстановления.

Ротация тоже ломает архивы. В манифесте каждой копии должен быть указан идентификатор версии ключа, а политика удаления ключей должна учитывать самый старый еще хранимый архив. Удалить старую версию KEK после плановой ротации легко. Восстановить данные после этого невозможно, даже если все объекты целы.

Территория должна сохраняться на всем пути копии

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

Отдельно спросите у каждого компонента пять вещей:

• где физически лежат объекты и их реплики;
• куда попадают временные файлы, multipart-загрузки и очереди;
• где работает KMS, HSM и хранится журнал операций с ключами;
• в какой территории находятся копии метаданных, каталоги и техническая поддержка;
• может ли политика аварийного восстановления автоматически создать копию в другой стране.

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

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

AI Router может быть частью такого контура для команд, которым нужны локальное хранение данных, аудит-логи и маскирование PII, но резервирование прикладных данных, индексов и ключей все равно остается обязанностью владельца системы. Шлюз не знает, какие документы вы считаете первичным источником истины и какой RTO вы обещали бизнесу.

RPO и RTO надо назначать отдельным слоям

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

Составьте таблицу восстановления, где строки соответствуют реальным зависимостям, а не названиям команд:

Эти цифры нельзя копировать из чужой презентации. Если оператор колл-центра работает с базой знаний, а поиск отсутствует восемь часов, бизнес может перейти на ручной процесс. Если RAG участвует в проверке платежа или обработке обращения пациента, ручной режим может быть невозможен. Разговор о RTO нужно вести с владельцем процесса, а не завершать после того, как SRE назвал скорость восстановления дисков.

Для PostgreSQL не ограничивайтесь ночным дампом, если вам нужен малый RPO. Официальная документация PostgreSQL описывает PITR как сочетание базовой копии и непрерывно архивируемого WAL. Базовая копия дает точку старта, а WAL позволяет проиграть изменения до нужного момента. Но документация также предупреждает о практической ловушке: настройка архивации может отставать или перестать работать, а каталог pg_wal продолжит расти до остановки базы при заполнении диска.

Минимум, который должен видеть мониторинг: возраст последнего успешно заархивированного WAL, лаг между созданием и доставкой сегмента, свободное место pg_wal, успешность последней базовой копии и возможность прочитать восстановленный архив. Сигнал «задание резервного копирования завершилось» не покрывает ни один из этих рисков полностью.

Восстановление надо репетировать в изолированной среде

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

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

Порядок возврата обычно важнее скорости отдельных операций:

1. Поднимите управление идентификацией, роли, политики и доступ к KMS или HSM.
2. Восстановите первичные данные и базу метаданных, затем проверьте контрольные суммы и миграции схемы.
3. Верните документы и векторный индекс или запустите подтвержденную пересборку из фиксированного манифеста.
4. Загрузите модельный пакет, включите политики генерации и прогоните контрольный набор запросов.
5. Восстановите аудит, проверив непрерывность событий и запреты доступа, затем открывайте приложение пользователям.

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

Фиксируйте фактическое время каждого этапа, ручные действия, неожиданные права и объем переданных данных. После двух или трех упражнений вы почти наверняка сократите RTO не покупкой еще одного хранилища, а устранением мелочей: отсутствующего разрешения, долгого DNS-переключения, ручного поиска версии токенизатора или неописанного порядка миграций.

Ошибки обычно прячутся в цепочках зависимостей

Самая популярная рекомендация звучит так: делайте правило 3-2-1 и задача решена. Несколько копий на разных носителях действительно полезны, но правило не отвечает, можно ли легально держать одну из копий за пределами страны, есть ли у нее доступный ключ и можно ли поднять из нее векторный поиск с прежними ACL. В LLM-контуре количество копий не заменяет описание состояния.

Вторая ошибка: резервировать только инфраструктуру через Terraform, Helm или снимки виртуальных машин. IaC возвращает ресурсы, но не возвращает содержимое очереди, базу знаний, историю ключей, индексные сегменты и запись о том, какой adapter был привязан к релизу. Снимок машины, в свою очередь, часто захватывает больше, чем нужно, включая временные файлы и секреты, и плохо переносится между площадками.

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

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

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