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

Skrum — универсальная панель управления проектами с ИИ: командный чат, задачи и спринты, нативные видеовстречи и входящая активность кода в одном рабочем пространстве, где каждое действие ИИ ждёт подтверждения человека.

Резервное копирование — ответственность оператора. Skrum поставляет скрипты и цикл хранения; вы задаёте расписание, внешнее хранилище, мониторинг и учебные восстановления.

Цели восстановления и расписание

• Рекомендуемая частота: полный набор каждую ночь и учебное восстановление раз в квартал. Если потеря суток недопустима, выполняйте копирование каждые шесть часов или чаще.
• RPO: не больше интервала между успешными наборами плюс длительность прерванного запуска. Ночное копирование даёт 24 часа только при мониторинге и успехе каждого запуска.
• RTO: измеряйте восстановлением объёма, близкого к производственному. Четыре часа — начальная эксплуатационная цель; фактический замер является главным.
• Хранение: начальная политика — 7 ежедневных, 4 еженедельных и 12 ежемесячных полных наборов, минимум одна копия вне хоста приложения и основного объектного хранилища.

Настройте оповещения о пропуске запуска, ненулевом коде или отсутствии MANIFEST.txt. Не удаляйте последний исправный набор до полной записи нового и его контрольных сумм.

Создание резервной копии

./scripts/backup/backup-all.sh

Скрипты читают только переменные резервного копирования из корневого .env, если они отсутствуют в процессе. Явно заданные переменные, включая пустые, имеют приоритет; файл не выполняется через source или eval, секреты не выводятся.

Обязательны MONGODB_URI, DATABASE_URL, S3_ENDPOINT, S3_ACCESS_KEY, S3_SECRET_KEY и S3_BUCKET. BACKUP_TARGET=local пишет в BACKUP_DIR; BACKUP_TARGET=s3 загружает под BACKUP_S3_PREFIX. Mongo, Postgres и объекты снимаются последовательно; для согласованной спокойной точки восстановления приостановите входящие записи и workers.

Цикл очистки по сроку хранения

Ежедневная задача BullMQ retention-sweep архивирует без потерь сообщения, комментарии к задачам и события графа работы, подлежащие очистке, в холодное хранилище по пути archive/{accountId}/{kind}/{sha256}.ndjson.gz перед удалением. Число дней хранения по тарифу соответствует historyDays (30 / 90 / 365 / неограниченно). На тарифах без ограничения задача ничего не делает.

Ожидания от восстановления

Восстановление разрушительно: Mongo использует --drop, Postgres — --clean --if-exists, а зеркало объектов удаляет лишнее. Запланируйте обслуживание, остановите записи API/workers и проверьте назначения.

./scripts/backup/restore-all.sh <BACKUP_SET_DIR_OR_S3_URI>

Команда проверяет манифест и все хеши до изменений, затем восстанавливает Mongo, Postgres и MinIO. До открытия записей:

1. Запустите API и workers и дождитесь успешных healthchecks.
2. Проверьте вход, чтение пространства/проекта/задачи/сообщения и загрузку известного файла.
3. Проверьте очереди, миграции и свежие события аудита.
4. Запишите время, набор и результат smoke-теста для обновления измеренного RTO.

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

• Управляемый хостинг? На управляемом тарифе резервное копирование — наша ответственность.
• Можно ли изменить окно хранения? Да — retention_policies для каждого аккаунта позволяет только уменьшить срок.
• Заменяет ли хранение приложения аварийные копии? Нет, жизненный цикл полных наборов — отдельная эксплуатационная политика.

См. также: Документация Skrum