# Бэкап RAG-помощника: что спасать в S3, PostgreSQL и Qdrant, а что пересобрать

> 2026-10-30 · AI Release · @ai_release1

> #RAG #резервное #Kubernetes #PostgreSQL #Qdrant #AI #LLM #векторныебазы

### ⚡ Главное за 5 секунд - Михаил Витко из Рег.облака разобрал, что бэкапить в RAG -помощнике: S3, PostgreSQL и Qdrant в Kubernetes. - Единица восстановления — согласованный набор: версии документов, метаданные, индекс, версии кода и моделей. - Сбой бывает тихим: сервис жив и отвечает, но по старому индексу — «14 дней» вместо «30». ### 🔍 Что случилось В блоге компании Рунити на Хабре вышла первая часть материала Михаила Витко, менеджера PaaS-продуктов Рег.облака, о резервном копировании ИИ-помощника по корпоративным документам. Разбор идёт на конкретной архитектуре: исходники в S3, DBaaS PostgreSQL хранит версии документов, прикладные права и историю диалогов, API и обработчики работают в KaaS. Qdrant команда разворачивает сама — как StatefulSet с PVC и Persistent Volume в том же Kubernetes. Ответы генерирует внешняя LLM по API, эмбеддинги считает отдельная модель. Механика RAG расписана по шагам: при загрузке документа обработчик кладёт исходный файл, выдёргивает текст, режет на фрагменты и считает эмбеддинги. На вопрос приложение находит разрешённые пользователю фрагменты и отдаёт их языковой модели. Компоненты обновляются независимо, и здесь корень проблемы: файл уже в S3, а векторы ещё не все; база знает новую редакцию регламента, а индекс — предыдущую. Автор приводит живой пример: после восстановления помощник отвечает про возврат товара «14 дней» вместо «30». Проверка доступности такой разрыв не ловит. Дальше — инвентаризация. Эмбеддинги и индекс — разные уровни: сохранённые векторы дают пересобрать поисковую структуру без обращения к модели, а если остались только PDF, придётся заново извлекать текст, резать и векторизовать. Модель провайдера скопировать обычно нельзя, поэтому сохраняют идентификатор модели, параметры запросов, промпты и тесты. Историю диалогов резервируют с устойчивыми `conversation_id`, `message_id`, порядком сообщений и ролями. ### 🧠 Наш разбор Наша оценка: это редкий случай, когда вендор пишет не про «мы запустили ещё один сервис», а про то, где у ИИ-приложений реально рвётся. Помощник — не монолит, а несколько хранилищ с разным темпом обновления. Классический бэкап «одной базы» здесь даёт ложное спокойствие. Второй момент — деньги и время. Полная перевекторизация корпуса стоит денег на эмбеддингах и часов простоя, хранение векторов обходится дешевле. Мы считаем, спор не про «бэкапить или не бэкапить», а про то, что команда готова пересобрать, а что обязана хранить. Кто выигрывает: те, у кого документы и индекс версионируются вместе. Проигрывают те, кто считает Qdrant «внутренним делом приложения» и не проверяет согласованность после восстановления. Отдельная засада — версия внешней модели: провайдер её уберёт, и даже полный бэкап не вернёт прежнее поведение. ### ⚠️ Чего мы не знаем В поводе нет цифр: ни объёмов корпуса, ни RPO/RTO, ни сравнения стоимости хранения векторов и пересборки. Вторая часть — про восстановление и проверку — ещё не вышла, так что рецепт согласованного отката мы не видели. И это блог вендора: архитектура привязана к его же сервисам, а Qdrant в примере — зона ответственности команды приложения, а не облака. ### 💬 О чём спорить Что хранить в бэкапе — векторы или исходники плюс модель эмбеддингов, если пересборка индекса занимает часы? Фиксировать версию внешней LLM и держать проверенный запасной вариант — или это борьба с рынком, который меняет модели быстрее, чем вы успеваете их тестировать? История диалогов — часть продукта, которую нельзя терять, или расходный лог, который после сбоя переживём? **Прогноз:** в течение квартала формулировка «согласованный набор данных» вместо «бэкап базы» появится минимум в двух чек-листах от других поставщиков PaaS и облаков — проверю по их публикациям. **Источник:** Хабр / Рунити

[Источник](https://habr.com/ru/companies/runity/articles/1101250/)