3.7 KiB
Rollback — Phase 8
Команды работают по SSH с root из platform/config.yaml. При необходимости
передайте --ssh-config FILE и --remote-node /absolute/path/to/node.
./mcpack rollback
./mcpack rollback-pack 0.0.4
Без подтверждения это только чтение: active/previous, actual binding, состояния операций и список snapshots с временем и исходным релизом. Нет загрузки agent, блокировки, остановки сервера или сборки. Список не заменяет проверку snapshot.
./mcpack rollback-pack 0.0.4 --confirm-compatible
./mcpack rollback --backup SNAPSHOT_ID --accept-progress-loss
Первый режим запускает сохранённый полный релиз с текущим миром. Оператор подтверждает совместимость модов и мира; SemVer её не доказывает. Ручные изменения managed configs блокируют перезапись, если target не содержит ровно эти изменения.
Второй режим восстанавливает весь runtime и исходный релиз snapshot. Прогресс
после указанного времени исчезает из активного runtime, включая данные модов.
Архив, inventory и release проверяются до остановки; распаковка происходит в
отдельном каталоге. Текущий runtime переносится в retired-runtimes/UUID/runtime,
а не удаляется. Дополнительно перед обоими режимами создаётся проверенный backup
текущего состояния при остановленном сервере под общей блокировкой.
.env и секреты сохраняются. Явный MC_BIND_ADDRESS действует и для старого
Compose через временный port overlay; immutable release не переписывается.
Pointers обновляются только после успешного startup/health. Состояние записывается
в rollback-state.json, предыдущий deployment — в operation-history/.
После неудачного deploy snapshot recovery определяет применённый релиз по binding, даже если active ещё указывает на предыдущий. Pack-only в таком состоянии запрещён. При ошибке rollback сервер останавливается; автоматического запуска старой сборки на изменённом мире нет. Незавершённый rollback блокирует следующие операции.
Для ручного восстановления после ошибки сначала изучите state, binding, diagnostics и оба pointers. Сохраните current backup, retired runtime и staged restore. Восстановите проверенный snapshot в отдельный root по backups.md, с host settings этого сервера; удалите остановленный старый контейнер и проверьте source release и health восстановленной копии. Завершать failed state можно лишь после сверки фактического binding и pointers; удаление state само по себе не recovery. Backups и retired runtime автоматически не очищаются.