wait4xandGLM-5.3
1d579c2281
验证: 独立复核（@worker-one）确认三级恢复描述与 rollback.sh 行为一致 Spec: 2026-11-05_blog-5n-admin-deep-optimization Co-authored-by: GLM-5.3
1.9 KiB
1.9 KiB
后台回滚指引
一句话版本：改坏了内容 → 后台再保存一次对的就好；整次部署坏了 → Gitea 网页里把坏提交 Revert 掉；全站级灾难 → 找主理人执行灾备开关。
什么时候需要哪一层
| 情形 | 用什么 | 频率预期 |
|---|---|---|
| 某篇文章/瞬间/设置改坏了 | 后台再改一次（Git 只是保险，不是日常工具） | 常见 |
| 一次部署把多处弄坏、说不清单点 | Gitea 网页 Revert（下面三步） | 偶发 |
| 静态站整体故障无法快速修复 | 灾备开关切回旧 Halo（仅主理人执行，见文末） | 理论上不会 |
Gitea 网页 Revert 三步
- 打开提交历史：https://git.wait4x.online/wait4x/blog/commits/branch/main （每次后台「保存」都是一条提交，时间与描述能对上）
- 点开弄坏的那条提交 → 右上角 Revert 按钮 → 确认。Gitea 会自动生成一条反向提交并提示创建 PR/直接合并——选择直接合并到
main - 推送后 30–60 秒自动构建部署，站点回到坏提交之前的状态
注意：
- Revert 撤销的是整条提交（那一次保存改动的所有内容）。如果好改动和坏改动混在同一次保存里，别 Revert，回后台把坏的部分再改回来更精准
- 只想回退构建但保留内容？不存在这种需求场景——构建永远反映 main 最新状态
灾备开关（仅主理人）
infra/deploy/rollback.sh 是整站切换：把 nginx 从静态站切回旧 Halo（127.0.0.1:18090），秒级生效。这是静态站全面故障时的逃生通道，日常内容问题永远用不上它。预演：bash infra/deploy/rollback.sh（默认 dry-run）；执行前建议先 bash infra/deploy/rollback-dryrun.sh 看四要素——Halo 容器若已退役，这个开关就是空枪，dryrun 一眼能看出来；执行需 root + --exec。