为什么单人作战更要讲备份
一个人跑全套内容生产、站点部署、数据采集，最大的风险不是写不出，而是写好了却丢了：单台渲染机硬盘坏、脚本被自己改崩、部署覆盖错文件、自动任务半夜把站推成 404。没有运维团队兜底，任何一次单点故障都可能让你一周的产出归零。备份不是"高级习惯"，是单人作战的保命绳。
我们的底线原则：任何一份"今天新生成的、明天还要用的"文件，落盘后 10 分钟内必须有一份副本在另一台机器/另一个目录。本地唯一一份 = 不算备份。
三层备份结构（我们实际在用的）
第一层：每日产出 → 远端服务器
- 所有
.md作战包、政策简报、招标巡检文件，生成后立刻经 pywinrm 推到站点服务器C:\www之外的归档盘； - 传输层用纯 Python 的 pywinrm（不依赖本机 WinRM 客户端服务），单文件分块 + SHA256 校验，落地即比对哈希，不等"命令返回 0"就当成功；
- 站点页部署同理：远端字节数/MD5 必须等于本地，否则判部署失败、自动重推一次。
第二层：关键脚本多副本 + 版本留痕
- 调度主脚本
master_task.py、部署脚本、采集脚本各保留一份"上次能跑"的副本，改坏可秒回退； - 大改前先
git commit或复制为_bak_日期，绝不"边跑边改线上脚本"； - 所有自动化提示词（长文规则）在本地留全量备份，连接器误删也能一键恢复。
真实教训：曾因部署脚本对单文件哈希不匹配直接
throw 整体中止，导致整批政策页没上线。修法是把 throw 改 try/catch、单文件失败记 WARN 继续——备份逻辑也要"失败隔离"，别让一个点炸掉全盘。第三层：防并发的锁文件与清单
- 多个计划任务如果会写同一份索引/台账，用锁文件（lock）或数据库事务串行化，避免两任务同时写把文件写空；
- 已完成的步骤写进状态文件（如
master_task.py step登记），断点续跑靠它，不靠记忆； - 增量部署只传哈希变化的文件，状态文件记各文件 SHA256，重跑秒级跳过未变项。
踩过的坑：一次性部署 20+ 个文件，上百次 winrs 会话把服务器 WinRM 会话池压垮，后续全部失败。改成分批（每批 ≤10、批间 sleep、单调用超时），才稳。
单点渲染机器的风险提醒
你的"生产机"一旦只有一台，它就是整个链条的单点。硬盘、系统、甚至一次手滑 rm 都能让你停摆。最低成本的解法：
- 系统盘与数据盘分离，数据盘定期镜像；
- 关键 Python 环境用 venv 固化，重装机器 5 分钟可恢复；
- 把"能重新生成"和"不能重新生成"分开：后者（客户留资库、台账、记忆）优先级最高，必须异地。
最小备份清单（照抄即可）
- ✅ 每日新增产出 → 远端归档盘（哈希校验）；
- ✅ 调度/部署/采集脚本 → 多副本 + 改前留痕；
- ✅ 客户留资库（SQLite）+ 台账 + 记忆文件 → 每日异地同步；
- ✅ 自动化提示词全量备份 → 本地一份；
- ✅ 锁文件/状态文件防止并发写坏；
- ✅ 增量部署 + 内容级校验，不靠 HTTP 200 当成功。
备份的价值不在"平时"，在"出事那天"。把上面六条变成不动脑子的习惯，单人作战也能睡得着觉。