Резервное копирование¶

Эта глава описывает штатный резервный контур НайсСофт — ИИ Студии 0.3.66 и правила эксплуатации, необходимые для реального аварийного восстановления.

Что изменилось в текущем выпуске¶

С 0.3.62 резервирование больше не является только скриптом создания архива. В продукте есть отдельная служба nicesoft-ai-studio-backup-manager и административная вкладка «Параметры → Резервное копирование». В 0.3.63 исправлены маршруты проверки/восстановления, а в 0.3.64 длительные действия получили явный прогресс и блокировку конфликтующих операций.

Текущий формат — .nsbackup, а не старый tar.gz.

1. Критерий полезной резервной копии¶

Резерв считается пригодным только если выполнены все четыре условия:

копия создана
+ целостность проверена
+ ключ восстановления хранится отдельно
+ восстановление реально тестировалось

Снимок ВМ может быть дополнительной защитой, но не заменяет прикладную резервную копию.

2. Изоляция службы¶

backup-manager:

работает во внутренней сети compose;
не публикует внешний порт;
не получает Docker socket;
вызывается через административный шлюз после проверки роли;
включён в системный health и Prometheus;
не отдаёт обычному пользователю доступ к резервам или ключу восстановления.

3. Что является авторитетным состоянием¶

Копируются:

MongoDB;
PostgreSQL/pgvector;
пользовательские загрузки и изображения;
база интеграции Яндекс Облака;
авторизованный JSON-ключ Яндекс Облака;
состояние управления моделями;
TLS, локальный УЦ и Let's Encrypt;
навыки и расширения;
runtime/configuration bundle для disaster recovery;
перечень установленных локальных моделей.

Не копируются по умолчанию:

модельные веса;
Redis;
Meilisearch;
история Prometheus;
контейнерные журналы.

Это осознанное разделение авторитетных данных и воспроизводимых производных данных.

4. Криптографическая модель¶

.nsbackup защищён:

AES-256-CTR
+
HMAC-SHA256

У каждой установки есть уникальный 256-битный ключ восстановления. Он не вкладывается в архив.

Обязательная административная операция после установки¶

Скачайте ключ восстановления через «Параметры → Резервное копирование → Скачать ключ восстановления» и переместите его в отдельное защищённое хранилище.

Не храните единственную копию ключа:

в той же ВМ;
рядом с .nsbackup без дополнительного контроля доступа;
в Git;
в тикете поддержки;
в обычной общей папке.

5. Политика хранения по умолчанию¶

Текущий baseline:

Параметр	Значение
Расписание	ежедневно, 03:00
Retention	последние 7 копий
Минимальный свободный запас	2 ГиБ
Локальный каталог	`backups/`

Расписание и retention изменяются в административном интерфейсе.

6. Что показывает панель¶

Администратор видит:

последнюю копию;
список .nsbackup;
размер каждой копии;
занятый резервами объём;
свободное место;
состояние и прогресс текущей операции;
расписание;
глубину хранения.

7. Создание копии¶

В интерфейсе нажмите «Создать копию сейчас» либо локально выполните:

./nicesoft.sh backup

После создания используйте действие «Проверить». Для критических изменений не полагайтесь только на факт появления файла.

8. Выгрузка с сервера¶

Хотя локальная копия полезна для быстрого отката состояния, она не переживёт полную потерю диска/ВМ.

Минимальная схема:

рабочая ВМ
  └─ локальная .nsbackup
       ↓
внешнее защищённое хранилище
  ├─ .nsbackup
  └─ отдельно управляемый recovery key

Для критичных систем используйте дополнительную immutable/offline-копию.

9. Проверка архива¶

Перед изменением данных служба проверяет:

HMAC;
структуру контейнера;
манифест;
SHA-256 каждого вложенного объекта;
совместимость версии.

Действие «Проверить» можно выполнять отдельно от восстановления.

10. Восстановление из интерфейса¶

Восстановление — разрушительная административная операция. Интерфейс требует ввести:

ВОССТАНОВИТЬ

После этого backup-manager сначала проверяет архив, затем включает maintenance mode и последовательно восстанавливает авторитетные хранилища.

Что восстанавливается¶

MongoDB;
pgvector;
YC state/key;
uploads/images;
model-manager state;
TLS/Let's Encrypt;
skills/extensions.

Что не перезаписывается автоматически¶

Текущие host-файлы запуска — .env, compose.yml и другие deployment-файлы — не заменяются скрытно при live restore. Их копии внутри архива предназначены для полной аварийной реконструкции и ручной сверки.

11. Аварийное восстановление без веб-панели¶

./nicesoft.sh restore /путь/к/backup.nsbackup

Команда использует тот же защищённый сервисный путь.

Warning

Не возвращайтесь к инструкциям 0.3.61, утверждавшим, что универсального restore нет. Это больше не соответствует 0.3.66.

12. Совместимость версий¶

Копия из более новой версии продукта не восстанавливается в старую версию. При полной потере ВМ разверните такую же или более новую поддерживаемую совместимую версию, затем восстановите данные.

13. Что делать с локальными моделями¶

Веса штатно не входят в архив. После аварии их нужно получить повторно согласно сохранённому модельному состоянию.

Для offline-контура дополнительно резервируйте:

сами модельные файлы;
SHA-256;
источник/лицензию;
runtime profile;
точную версию среды выполнения.

14. Recovery drill¶

Не реже установленного организацией периода выполняйте проверочное восстановление на отдельной ВМ.

Проверьте:

расшифрование резервной копии сохранённым ключом;
вход ADMIN;
вход тестового USER;
диалоги и проекты;
файл + RAG;
локальную или облачную модель;
сертификат;
yc-doctor, если YC используется;
отрицательные тесты прав.

15. Резерв перед обновлением¶

В 0.3.66 новый updater проверяет обязательность резервной копии и её верификации в preflight. Однако сам updater текущего выпуска ещё не выполняет install/switch/rollback. Перед фактическим ручным обновлением резерв всё равно должен быть создан и проверен.

16. Что фиксировать в журнале эксплуатации¶

Для каждой значимой копии сохраните:

дата и время
версия продукта
имя .nsbackup
размер
результат verify
место внешнего хранения
идентификатор recovery key/хранилища
последний успешный restore-test

Не записывайте сам recovery key в обычный журнал.