Резервное копирование AI-сервиса: что восстанавливать кроме весов

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

Разделить незаменимое и воспроизводимое

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

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

Объект	Что сохранить	Как проверить
База приложения	Данные, схема, миграции	Открыть карточки и проверить связи
Документы	Содержимое, версии, права	Найти нужную редакцию и отказать чужой роли
Индекс	Снимок либо процедуру построения	Сравнить контрольную выборку поиска
Модель	Версия, веса, токенизатор, лицензия	Повторить эталонные запросы
Приложение	Образы, конфигурация, зависимости	Запустить без ручного изменения контейнера

Задать допустимую потерю и простой

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

Измеряйте RTO от принятого момента начала инцидента до подтверждённой работоспособности, включая поиск копии, доступ к инфраструктуре и проверку результата. Время копирования файлов является только частью этого интервала. Уточните, кто имеет право принять восстановленную систему и что пользователи увидят во время работ.

Выбрать подходящую технологию копии

PostgreSQL описывает логические выгрузки, файловое резервирование и непрерывное архивирование как разные подходы 1. Они решают разные задачи и требуют согласованной процедуры. Нельзя считать обычное копирование каталога работающей базы универсально корректной резервной копией. Конкретный метод выбирают с учётом объёма, версии и требований восстановления.

Для Qdrant существуют снимки и специальные процедуры восстановления 2. Тип снимка и режим размещения имеют ограничения; план для одного узла нельзя без проверки перенести на распределённый кластер. Храните инструкцию для используемой версии и отмечайте, сколько свободного места потребуется временно во время восстановления.

Копия должна пережить исходный отказ

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

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

Провести учение до первой аварии

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

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

Полезный результат — подписанный протокол восстановления с известными ограничениями. Он дополняет критерии приёмки LLM и входит в объём эксплуатационной поддержки. Наличие файла с названием backup без такой проверки подтверждает лишь существование файла.