Резервное копирование и восстановление

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

Что важно

Создавайте резервные копии, когда применимо:

• базы данных SQLite ThreadCells и связанных с ней файлов SQLite;
• конфигурации и окружения службы, исключая plaintext secrets из специальных архивов;
• файла verifier оператора как отдельно защищённого артефакта, близкого к секрету;
• файла токена бота Telegram, если он настроен, как отдельного зашифрованного файла с учётными данными, с сохранением владельца и режима;
• контекста агента, вложений и журналов, требуемых вашей политикой хранения;
• метаданных управляемых worktree и релизов, необходимых для интерпретации активной работы;
• точных манифестов/идентичностей активного кандидата и кандидата восстановления;
• внешнего состояния провайдера — только согласно поддерживаемой политике резервного копирования этого провайдера.

У Git-репозиториев уже должна быть собственная стратегия резервного копирования/remote. Резервная копия базы данных ThreadCells не заменяет сохранение commit.

Что можно пересобрать

Загруженные Web-зависимости, ревизии браузера, кэши пакетов, временные каталоги сборки и проверенное содержимое кандидата обычно можно воссоздать из исходников и lockfile. Не увеличивайте каждую резервную копию кэшами только потому, что они находятся под путями runtime.

Последовательность согласованного резервного копирования

1. Запишите идентичность активного исходного кода/кандидата и текущее состояние службы.
2. В течение окна снимка не начинайте новые сессии или изменения.
3. Используйте канонический механизм резервного копирования базы данных, а не просто копируйте активный файл SQLite.
4. Проверьте целостность SQLite на резервной копии.
5. Скопируйте нужные конфигурацию, verifier и настроенные артефакты токена Telegram с сохранением прав и без вывода их содержимого.
6. Запишите контрольные суммы и сохраните архив вне рабочего корня состояния.
7. Проверьте, что предполагаемая учётная запись восстановления может просмотреть и прочитать резервную копию.

Если инструмент развёртывания предоставляет команду резервного копирования, используйте её: она знает фактический путь базы данных и координацию служб. Никогда не помещайте plaintext secrets провайдера или оператора в историю оболочки при создании архива.

Проверка

Как минимум проверьте скопированную базу SQLite:

sqlite3 /path/to/backup.db 'PRAGMA integrity_check;'

Ожидаемый результат: ok. Также запишите контрольную сумму и убедитесь, что архив содержит ожидаемые конфигурацию, verifier и идентичность сборки, не раскрывая их содержимое в журналах.

Непроверенная резервная копия — лишь гипотеза. Периодически репетируйте восстановление в изолированный путь и на порт только loopback.

Порядок восстановления

1. Остановите или изолируйте целевую службу ThreadCells.
2. Сохраните текущее неудачное состояние для криминалистического отката.
3. Установите или выберите точный совместимый кандидат.
4. Восстановите базу данных и изменяемое состояние с ожидаемым владельцем runtime-учётной записи.
5. Восстановите конфигурацию службы.
6. Восстановите verifier оператора с отдельным доверенным владельцем, режимом, разрешающим чтение службе, и надёжной цепочкой родительских каталогов; восстановите применимый токен Telegram в $CAO_HOME_DIR/secrets/telegram-bot-token как обычный файл, принадлежащий runtime, с режимом 0600.
7. Выполните проверки целостности до запуска.
8. Запустите на loopback и проверьте health/идентичность сборки.
9. Проверьте активные рабочие процессы, результаты, терминалы, проекты, preflight провайдера и Statistics до повтора работы.

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

Проверка восстановления

После восстановления проверьте:

• Settings → About соответствует предполагаемому кандидату;
• /health успешен;
• присутствуют проекты и история сессий;
• доставленные результаты остаются относимыми к своему источнику;
• доступность провайдера отражает фактическую установку восстановленного runtime-пользователя;
• авторизация оператора сообщает, что настроена, и разблокируется существующим секретом;
• Telegram сообщает ожидаемое безопасное состояние конфигурации и, если восстановлен, проходит явные проверки подключения и тестового сообщения до включения;
• итоги Statistics воспроизводятся без дублирования;
• активные релизы/релизы восстановления определены правильно.

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

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