Backup и disaster recovery для self-hosted AI: что бэкапить и как восстанавливать

Backup и disaster recovery для self-hosted AI — это план защиты всей связки из 6-10 сервисов: модели, vector store, embedder-кэша, оркестратора и конфигов. Потеря vector store без бэкапа означает пересчёт эмбеддингов за часы GPU-времени; потеря файнтюна — повторение тренировки. Этот текст описывает что бэкапить, как часто и как тестировать восстановление.

Зачем AI-системе отдельный disaster recovery?

В обычной IT-инфре «бэкап БД + бэкап файлов = почти всё». В AI-стеке появляются специфические сущности:

Файлы моделей — десятки-сотни ГБ на каждую (Llama 70B Q4 ~40 ГБ, gguf-варианты разные).
Vector store — может быть терабайтным, переcчёт = часы GPU-времени.
Embedding-кэши — если потерять, модель пересчитывает заново.
Файнтюн-чекпойнты — если делали свой файнтюн, потеря = повторение тренировки.
Промпт-конфигурации — десятки версионированных промптов в Dify/LangFuse.
Knowledge base оригиналы — PDF, DOCX, страницы внутренних wiki.
Логи диалогов — нужны для compliance и для разбора инцидентов.

Каждое — со своими RPO (сколько данных можно потерять), RTO (как долго можно лежать), и стоимостью пересчёта.

Что бэкапить: матрица

Компонент	Что	Размер	RPO	RTO	Можно пересчитать?
Файлы моделей	`.gguf`, `.safetensors`, конфиги	40-200 ГБ/модель	—	30 мин	Скачать заново (часы при медленной сети)
Файнтюн-чекпойнты	LoRA-адаптеры, full FT-чекпойнты	1-150 ГБ	разовый бэкап после тренировки	по мере надобности	Нет — повторить тренировку
Vector store	snapshot БД + конфиг индексов	1-50 ГБ на 1М векторов	24 часа	30 мин	Можно (часы GPU)
Document store (оригиналы)	PDF, DOCX, MD	от ГБ до ТБ	1-24 часа	1 час	Нет
Метаданные (Postgres/SQLite)	пользователи, роли, диалоги, теги документов	сотни МБ-ГБ	15 мин	30 мин	Нет
Промпт-конфигурации	Dify/LangFuse экспорты	сотни МБ	24 часа	30 мин	Нет (без копии — переписывать)
Embedding-кэши	redis/disk-cache	до сотни ГБ	можно потерять	—	Можно
Логи диалогов	append-only хранилище	растёт постоянно	по compliance	1 час	Нет

Главное правило: документы и метаданные — must-backup. Модели — можно перекачать, но удобнее иметь локально. Vector store — компромисс: бэкап быстрее, чем пересчёт.

Стратегия 3-2-1 для AI

Классическое правило бэкапов: 3 копии, на 2 разных носителях, 1 off-site. Для AI это значит:

Копия 1 (primary): на том же сервере / NAS — быстрый restore.
Копия 2 (secondary): на другом физическом сервере или массиве — защита от сбоя железа.
Копия 3 (off-site): другой ЦОД, или зашифрованный объектный сторадж (S3-совместимый — Yandex Object Storage, MinIO в другом ЦОДе, VK Cloud Storage). Защита от пожара / затопления / физической атаки.

Для self-hosted в ФЗ-152-режиме — off-site обязательно в РФ.

Vector store: специфика бэкапов

Weaviate

Встроенный backup-модуль на S3-совместимый бэкенд.
Команда: POST /v1/backups/{backend} — снимает консистентный snapshot.
Restore — обратная команда, индексы загружаются автоматически.
На больших коллекциях (10M+) backup занимает 10-30 минут.

Qdrant

Snapshots API — снимает копию коллекции в файл.
Можно копировать файл куда угодно (локальный диск, S3, NAS).
Restore — через API recover from snapshot.
Лёгкий формат, быстро.

Milvus

Backup-tool отдельно — milvus-backup CLI.
Сохраняет в S3 / локальный диск.
На distributed-кластерах требует координации между нодами.

pgvector

Стандартный pg_dump — но на больших объёмах медленно (часы).
Логическая репликация на standby — лучше для DR, чем dump.
Physical backup через pg_basebackup или WAL archiving.

Грабля: во всех случаях бэкапить нужно вместе с метаданными — конфиги индексов (HNSW параметры), embedder-id (какая модель сделала векторы), маппинг chunk → исходный документ. Без этого восстановленный vector store бесполезен.

Модели: бэкапить или нет

Стандартные публичные модели (Llama, Qwen, DeepSeek) — на бэкап не, на свой Hugging Face mirror — да.

Причины:

Hugging Face может задержать скачивание (rate limit), быть недоступен для российских IP, или модель удалена/заменена.
Локальный mirror (Nexus / простой HTTP-сервер с файлами) — даёт независимость.
Если у вас 5+ моделей и 10+ серверов — каждый раз перекачивать = дни.

Файнтюненные модели — бэкапить обязательно. Тренировка стоит сотни долларов GPU-времени и часы данных. Потеря чекпойнта = повторение всего.

Стандартный путь:

Чекпойнты после тренировки — в S3-совместимый storage с шифрованием.
Хранить минимум 2 последние версии — на случай что новая хуже.
Записывать tag/version + конфиг тренировки рядом.

Документы: оригиналы в первую очередь

Часто забываемый компонент. RAG-индекс — производный артефакт, можно пересчитать. Оригиналы документов — нельзя. Если их нет где-то ещё (CRM, файловая шара) и индекс был единственным местом — потеря фатальна.

Бэкап документов:

Если они лежат в SharePoint / Bitrix / другом источнике — этот источник и есть бэкап. Просто убедись что у источника есть свой backup.
Если AGmind / RAG-система — единственное хранилище — обязательный отдельный backup сырых файлов на S3.
Версионирование: если документы меняются (например, регламенты v2, v3) — хранить историю.

Метаданные: маленькие, но критичные

Конфиги, пользователи, диалоги, теги документов, роли, разрешения — обычно живут в Postgres / SQLite внутри Dify / Open WebUI / своего бэкенда.

Маленькие по объёму — pg_dump каждые 15 минут не проблема.
WAL-архивирование — RPO в минуты.
Хранить retention минимум на 30 дней — для разбора инцидентов.

Шифрование бэкапов

Бэкап на off-site без шифрования = слив всех корпоративных данных при компрометации канала.

AES-256 для files at rest.
Ключ — в KMS (HashiCorp Vault, YC KMS, отдельный hardware key).
Ключ не хранится рядом с бэкапом. Иначе шифрование бессмысленно.
Тестируй decrypt + restore регулярно. Иначе обнаружишь сломанный ключ в момент аварии.

Тестирование восстановления

Бэкап без теста восстановления — не бэкап.

Это правило цитируется во всех DR-гайдах потому, что регулярно нарушается. Сценарии типичных провалов:

Бэкап snapshot есть, а restore-инструкция — нет.
Бэкап на S3 есть, а ключ для расшифровки потерян.
Бэкап делается, но в нём только половина данных (забыли один сервис).
Restore работает, но новая инфра не та же версия — несовместимый формат.

Минимальная программа тестов:

Раз в квартал — полный restore vector store на тестовый стенд.
Раз в полгода — DR-учения: «представь что dc-1 упал». Поднять стек на dc-2 за RTO.
После каждого major-апдейта — smoke-test restore.

Типовые катастрофы и сценарии

Катастрофа 1: «случайно удалили коллекцию»

Самый частый сценарий. Админ через UI или API случайно дропнул коллекцию документов или удалил пользователя.

RTO: 30 минут.

Действия:

Не делать ничего ещё (не перезаписать бэкап).
Найти последний snapshot.
Восстановить в новую коллекцию.
Если был partial loss — merge только удалённого.
Аудит логов: кто, когда, как удалил.

Профилактика: soft delete + retention 30 дней + 2FA на действия удаления.

Катастрофа 2: «vector store повреждён»

Сбой диска, kill -9 в неподходящий момент, баг в БД.

RTO: 1 час. RPO: 24 часа (потеря последних добавленных документов с прошлого snapshot’а).

Действия:

Stop writes на vector store.
Restore последнего snapshot.
Re-index документов, добавленных после snapshot (если есть журнал).
Smoke-test поиска.
Восстановить writes.

Профилактика: journaling, регулярные snapshots, replication где это разумно.

Катастрофа 3: «упал ЦОД»

Электричество, охлаждение, физическая авария.

RTO: 4-24 часа в зависимости от того, есть ли горячий стенд. RPO: 1 час (если репликация в другой ЦОД), 24 часа (если только бэкапы).

Действия:

Развернуть стек в резервном ЦОДе (в идеале — заранее подготовленный, IaC).
Restore данных из off-site бэкапа.
Переключить DNS / load-balancer.
Смоук-тесты.
После восстановления primary — обратная репликация.

Профилактика: IaC (Terraform/Ansible), регулярные DR-учения, off-site бэкап в другом ЦОДе.

Катастрофа 4: «зашифровал ransomware»

Worst case, и не такой редкий как кажется.

RTO: 1-2 дня. RPO: 1-24 часа (если бэкап не успели зашифровать).

Действия:

Изолировать заражённый сегмент.
Развернуть стек заново на чистом железе.
Restore из off-site бэкапа (который не имел сетевого доступа из заражённой зоны — иначе тоже зашифрован).
Полный security-аудит до возврата в production.

Профилактика:

Off-site бэкап immutable (S3 Object Lock, ZFS snapshots с retention) — не может быть стёрт даже от имени root.
Минимум привилегий: учётка с access на backup-storage не имеет прав в production.
Regular vulnerability scanning.

Катастрофа 5: «модель сошла с ума после апдейта»

Не катастрофа в классическом смысле, но требует rollback.

RTO: 15 минут.

Действия:

Rollback версии модели (предыдущий тэг в реестре моделей).
Если файнтюн — rollback на предыдущий чекпойнт.
Анализ почему новая хуже.

Профилактика: semantic versioning моделей, eval-сет перед промоутом в production, blue-green deployment.

Стандартный план DR для AGmind-стека

Компонент	Бэкап	Куда	Частота	Retention
Postgres (метаданные)	WAL + base backup	S3 (Yandex Object Storage)	base 1×/день, WAL непрерывно	30 дней
Vector store (Weaviate)	snapshot	S3	1×/день	14 дней
Документы (оригиналы)	sync	S3 + другой ЦОД	при каждом upload	бессрочно
Файнтюн-чекпойнты	копия после тренировки	S3 + локальный mirror	разово	бессрочно (последние 3 версии)
Промпт-конфиги (Dify)	export YAML	git-репозиторий	при изменении	git history
Логи диалогов	append-only	S3 + tape (для compliance)	непрерывно	по compliance
Конфиги Ansible/Terraform	git	git-репозиторий	при изменении	git history

Шифрование AES-256, ключ в Vault, off-site копии в другом ЦОДе РФ.

Что часто упускают

1. Бэкап конфигов и инфры. Без terraform/ и ansible/ восстановление — это часы или дни ручного труда. Хранить в git.

2. Версионирование embedder’а. Если бэкап сделан с эмбеддером bge-m3 v1.5, а восстановили на v2.0 — векторы несовместимы. Нужно записывать версию embedder’а вместе со snapshot’ом.

3. Время реальной перекачки моделей. «100 ГБ Llama» по медленной сети из Hugging Face — это 4-6 часов. Локальный mirror решает.

4. Зависимости от внешних сервисов. Если ассистент дёргает GigaChat или YandexGPT API — что делать когда они упали? План B нужен, или явное «зависим от поставщика».

5. Документация. План DR, который никто не читал и не тренировал — план в стиле «открой в момент аварии и попытайся понять». Учения раз в полгода — must.

Чек-лист

Итог

Self-hosted AI без backup-плана — мина. Vector store, файнтюн-чекпойнты, оригиналы документов, промпт-конфиги — всё это специфические сущности, которые легко забыть в плане. Стандартное правило 3-2-1 + immutable off-site + регулярные тесты восстановления = реальная защита.

В AGmind backup-конфигурация — часть пакета развёртывания: автоматизированные snapshots, шифрование, off-site в другом ЦОДе РФ, ежеквартальные restore-тесты. Это часть «деплой → интеграция → поддержка», не отдельный счёт.

Связанные тексты: архитектура в закрытом контуре, vector DB сравнение, сколько стоит сервер для AI, внедрение под ключ.