Резервное копирование ИИ-стека: модели, база, настройки

MAATRIX

Развернули свой ИИ-стек на сервере — модель, векторную базу для RAG, обвязку с системными промптами — и рано или поздно встаёт вопрос бэкапа. Стандартный ответ «бэкапьте всё» здесь не работает: часть стека весит десятки гигабайт и восстанавливается за одну команду, а часть весит килобайты и без бэкапа не восстанавливается вообще. Разберём ИИ-стек по компонентам и расставим приоритеты — что копировать обязательно, что можно пересоздать, и как проверить, что система после восстановления работает как раньше, а не только формально запустилась.

Карта компонентов ИИ-стека и что из них теряется без бэкапа

У типичного самостоятельно развёрнутого ИИ-стека — будь то Ollama с обвязкой, vLLM за собственным API, или связка LLM + векторная база для RAG — есть четыре разных по природе слоя данных. Их легко перепутать местами по важности, если мыслить категориями «файлы» и «диск», а не категориями «что уникально и невосстановимо».

Ключевая ошибка, которую видно почти в каждом самодельном скрипте бэкапа ИИ-стека, — обратный порядок: ночной tar гребёт каталог с весами моделей целиком, потому что он самый большой и заметный, а конфиг RAG-пайплайна и системные промпты остаются в head’е разработчика. При аварии веса скачиваются заново, а вот точные параметры чанкинга и текст промпта, который правился три месяца итерациями, восстановить неоткуда.

Общий принцип «одна рабочая копия, один локальный бэкап, одна копия за пределами сервера» для ИИ-стека работает так же, как для любых других данных — подробно он разобран в статье про правило 3-2-1 для бэкапов. Здесь — только специфика того, *что именно* класть в эти три копии применительно к ИИ-инфраструктуре.

Приоритет 1: конфигурация и настройки — маленький объём, критичная скорость восстановления

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

• Системные промпты — если они зашиты в код обвязки, в переменные окружения или в отдельные .txt/.md файлы, а не хранятся в git-репозитории отдельно от сервера.
• Параметры развёртывания — docker-compose.yaml, .env с портами и путями к моделям, systemd unit-файлы, конфигурация обратного прокси перед API.
• Конфигурация RAG-пайплайна — размер чанка (chunk_size), перекрытие (chunk_overlap), используемая модель эмбеддингов, порог похожести при поиске (similarity_threshold), количество извлекаемых фрагментов (top_k).
• Параметры дообучения, если модель кастомизирована — гиперпараметры LoRA (ранг, целевые модули, learning rate), чтобы при необходимости повторить процесс.

Практика: соберите всё это в один каталог с версионированием, а не полагайтесь на память. Пример структуры и минимального скрипта бэкапа:

mkdir -p /opt/backups/ai-config/{prompts,rag,deploy}

# системные промпты — если хранятся файлами
cp -r /opt/ai-stack/prompts/*.txt /opt/backups/ai-config/prompts/

# конфигурация RAG-пайплайна
cp /opt/ai-stack/rag/config.yaml /opt/backups/ai-config/rag/config-$(date +%F).yaml

# параметры деплоя
cp /opt/ai-stack/docker-compose.yaml /opt/backups/ai-config/deploy/
cp /opt/ai-stack/.env /opt/backups/ai-config/deploy/env-$(date +%F)

tar czf /opt/backups/ai-config-$(date +%F).tar.gz -C /opt/backups ai-config

Пример содержимого config.yaml RAG-пайплайна, которое стоит зафиксировать именно текстом, а не держать в голове:

embedding_model: intfloat/multilingual-e5-large
chunk_size: 512
chunk_overlap: 64
top_k: 5
similarity_threshold: 0.75
vector_store: qdrant
collection_name: knowledge-base-v3

Если восстановленная система выдаёт другие ответы на те же вопросы, часто причина именно здесь: параметры чанкинга или модель эмбеддингов при восстановлении «на глаз» оказались не те, что были в оригинале, а векторный индекс без них воспроизвести один в один нельзя.

Держите этот бэкап в git-репозитории (без секретов) или зашифрованным архивом рядом с остальными — весит он копейки, снимать его можно при каждом изменении конфига, а не только по расписанию раз в сутки.

Приоритет 2: векторная база — бэкапить индекс или пересоздавать из исходников

Здесь начинается настоящий выбор, а не автоматическое «да, бэкапить». Векторный индекс — это производная структура: он построен из исходных документов конкретной моделью эмбеддингов с конкретными параметрами чанкинга. Если у вас сохранены и исходные документы, и конфигурация из предыдущего раздела — индекс в теории воспроизводим полностью.

Вопрос в другом: что дешевле — хранить бэкап самого индекса или пересоздавать его при восстановлении?

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

Команды бэкапа отличаются от базы к базе — единого стандарта, увы, нет:

# Qdrant: создать снимок коллекции через API, забрать файл
curl -X POST 'http://localhost:6333/collections/knowledge-base-v3/snapshots'
# файл появится в /qdrant/storage/collections/knowledge-base-v3/snapshots/

# Chroma: персистентный каталог — просто архив
tar czf chroma-backup-$(date +%F).tar.gz -C /opt/ai-stack/chroma_data .

# pgvector (Postgres с расширением): обычный дамп таблицы
pg_dump -h localhost -U rag -t documents_embeddings ragdb | gzip > pgvector-$(date +%F).sql.gz

# FAISS: индекс — это просто файл на диске
cp /opt/ai-stack/faiss_index/index.faiss /opt/backups/faiss-index-$(date +%F).faiss

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

Приоритет 3: веса моделей — когда бэкап не нужен, а когда обязателен

Здесь работает чёткое правило, и его стоит проговорить прямо, потому что интуиция часто подсказывает обратное — «модель самая большая, значит, самая важная для бэкапа».

Открытые модели без дообучения бэкапить не нужно. Если вы используете модель как есть — скачанную с Hugging Face или через ollama pull — при аварии её можно скачать заново из того же публичного источника. Тратить место в бэкапе и трафик на ежедневное копирование условных 15 ГБ весов, ни один байт которых не менялся с момента скачивания, бессмысленно.

Кастомно дообученные модели — обязательный бэкап без вариантов. Если модель дообучена под ваши данные — например, через LoRA, — результат существует в единственном экземпляре и нигде больше не восстановим. Полное дообучение (full fine-tuning) само по себе тяжёлое и редкое для домашней инфраструктуры, а вот LoRA-адаптеры сегодня — стандартный способ кастомизации именно потому, что дёшевы в обучении и малы по объёму хранения:

# LoRA-адаптер — это отдельный, компактный набор файлов рядом с базовой моделью
ls -la /opt/ai-stack/lora-adapters/my-assistant-v2/
# adapter_config.json
# adapter_model.safetensors
# tokenizer_config.json (если менялся)

tar czf /opt/backups/lora-my-assistant-v2-$(date +%F).tar.gz \
  -C /opt/ai-stack/lora-adapters my-assistant-v2

Сам адаптер обычно на порядки меньше базовой модели — точный вес зависит от ранга (r) и набора целевых модулей, но порядок величины принципиально иной, чем у полных весов. Это случай, когда маленький бэкап защищает большую работу: часы или дни обучения на арендованном GPU превращаются в файл, который поместится даже в бесплатный тариф облачного хранилища. Подробнее про сам процесс обучения — в статье про LoRA-дообучение своей модели.

Не забудьте про сам adapter_config.json — без него safetensors-файл с весами адаптера бесполезен: там записаны ранг, целевые модули и база, к которой адаптер применяется. Потерять этот файл — то же самое, что потерять сам адаптер.

Приоритет 4: логи диалогов — как обычные бизнес-данные, не больше и не меньше

Если ИИ-стек ведёт лог диалогов с пользователями — это ценность того же порядка, что переписка в CRM или тикеты в service desk. Не критичнее конфигурации, из-за которой система вообще не сможет отвечать правильно, но и не то, чем можно пренебречь: это история реального взаимодействия, аналитика по качеству ответов, а иногда и материал для будущего дообучения.

Практический подход — то же расписание, что и для остальных бизнес-данных компании: ежедневный инкрементальный бэкап новых записей, ротация по сроку хранения, который определяете вы сами исходя из назначения логов и применимых требований к персональным данным. Технически это обычно таблица в базе (Postgres, SQLite) или файлы в структурированном формате — бэкап делается теми же средствами, что и для любой другой СУБД, без специфики именно ИИ-стека.

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

Как собрать всё в одно расписание с разной частотой на компонент

Ошибка — снимать бэкап всего стека раз в сутки одним скриптом с одинаковой периодичностью для всех компонентов. У разных слоёв данных принципиально разная скорость изменения и разная цена потери:

/etc/cron.d/ai-stack-backup

# конфигурация и промпты — при каждом изменении вручную + контрольный ночной снимок
0 2 * * * root /opt/backups/scripts/backup-config.sh

# LoRA-адаптеры — сразу после каждого нового обучения, отдельным вызовом вне cron
# (запускается вручную по завершении ollama create / peft save)

# векторный индекс — раз в сутки, если решили бэкапить индекс, а не только исходники
0 3 * * * root /opt/backups/scripts/backup-vector-index.sh

# логи диалогов — инкрементально, каждый час
0 * * * * root /opt/backups/scripts/backup-dialog-logs.sh

Такое разделение решает две задачи сразу: маленькие критичные бэкапы (конфиг, LoRA) снимаются часто и почти бесплатно по ресурсам, а тяжёлые (векторный индекс) — реже, с учётом реальной скорости изменения базы знаний. Копия за пределами сервера обязательна для всех четырёх компонентов, но конфиг и LoRA-адаптеры можно держать во внешнем хранилище с полной историей версий, а тяжёлый индекс — только последние две-три копии.

Тестирование восстановления: «поднялось» не значит «отвечает как раньше»

Общий принцип регулярной репетиции восстановления справедлив для любой инфраструктуры и подробно разобран в статье про репетицию восстановления. Для ИИ-стека у него есть существенное дополнение, которое легко упустить: технический успех восстановления — сервис стартовал, порт слушает, API отвечает 200 — не означает, что система восстановилась *качественно*.

ИИ-стек может подняться и отвечать, но деградировавшим: устаревшая конфигурация чанкинга, не та модель эмбеддингов, потерянный при восстановлении LoRA-адаптер (система тихо откатилась на базовую модель без дообучения), неполный векторный индекс после оборванной реиндексации. Формально всё «работает». По факту — качество ответов заметно хуже, а техподдержка узнаёт об этом от пользователей, а не от мониторинга.

Поэтому после восстановления любого компонента ИИ-стека нужен второй, содержательный этап проверки — прогон подготовленной батареи тестов на реальных вопросах с заранее известными ожидаемыми ответами, а не просто curl к /health. Как собрать такую батарею тестов и на что в ответах модели обращать внимание — отдельная тема, разобранная в статье про батарею тестов для своей LLM.

Минимальный чек-лист именно для ИИ-стека после восстановления:

• Сервис отвечает на API-запрос без ошибок (базовая техническая проверка).
• Список моделей и LoRA-адаптеров совпадает с тем, что было до аварии.
• Векторный поиск по контрольному запросу возвращает те же (или эквивалентные) документы, что и раньше.
• Прогон батареи тестовых вопросов даёт ответы того же качества, что и эталонный прогон до аварии — не «плюс-минус», а сравнение с сохранённым эталонным набором.
• Системный промпт в ответах модели виден по поведению — не только по факту, что файл на месте, а по факту, что модель ведёт себя как настроено.

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

Частые вопросы