第29章 备份、迁移与环境可重建
第28章把风险红线立起来了——红线解决「别踩雷」，但踩雷之后能不能站起来、封号之后能不能重建、换设备之后能不能继续干活，是另一套能力。本章解决「资产到底归不归你」这件事：不能重建的系统不属于你，不能迁移的资产只是平台人质。第30章是终章，给你下一步的具体动作。
29.1 结论先行：资产所有权 = 可迁移性 × 可重建性
先把一人公司的最后一道护城河摊开：
资产所有权 = 可迁移性 × 可重建性其中：
可迁移性 = 把资产搬到新平台/新工具所需的时间与摩擦（越短越高）
可重建性 = 从一台空机器起步，多久能恢复全部生产能力（越快越高）为什么是乘法？呼应第01章的乘法原则——任何一项为零，资产就不属于你。你的代码全锁在某个平台私有仓库（可迁移性为零），平台封号那天，资产瞬间归零；你的 skill 模板散落在十几个对话里从没导出（可重建性为零），换台电脑就全没了。
这把第28章的「风险红线」补完了：红线是别让损失发生，本章是损失发生后还能站起来。两者合起来，才是一人公司完整的业务连续性（Business Continuity）。
来看一个对照。两个独立开发者，表面上资产规模差不多：同样的代码量、同样的文档、同样的客户。但甲把代码托管在单一私有平台、配置只在本机、对话记录从没导出；乙的代码有两个异构远端、配置入 dotfiles 仓库、对话记录每周自动导出 markdown 到自有存储。平台封号那天，甲的业务当场归零，乙在 4 小时内恢复 80% 生产力。 两人的差距不在能力，在可迁移性和可重建性。
这就是为什么本章不放在前面讲。前 28 章你积累的所有资产——第12章的知识库、第11章的工作流、第15–20章的交付物、第21–25章的案例——只有在「能重建、能迁移」的前提下，才真属于你。否则它们全是寄存在别人仓库里的货，随时可能被清零。
铁律：一份从未做过恢复演练的备份，等于没有备份。资产所有权的凭证不是「我存了」，而是「我恢复过」。
理解这一点后，本章其余都在回答一个问题：怎么把代码、文档、知识库、配置、凭据、部署、对话记录这七类资产，做到可迁移 + 可重建？
29.2 资产盘点：到底要保护什么
与「备份 = 复制文件」的差异
很多人把备份理解成「把文件夹拷一份」。这是错觉。一人公司的资产至少有七类，每类的存储介质、迁移方式、重建难度完全不同。
| 维度 | 复制文件 | 资产盘点 | 环境可重建 |
|---|---|---|---|
| 对象 | 一堆文件 | 七类资产 + 它们的关系 | 一套能跑的生产环境 |
| 目标 | 不丢 | 可迁移 | 停机后能恢复 |
| 验证 | 文件还在 | 能在新平台打开 | 从空机重建并跑通 |
| 难度 | 低 | 中 | 高 |
复制文件解决「不丢」，资产盘点解决「能搬」，环境可重建解决「能活」。 一人公司要的是第三个。
七类资产清单
| 序号 | 资产类型 | 典型形态 | 丢失代价 |
|---|---|---|---|
| 1 | 代码 | git 仓库、脚手架、组件库 | 项目返工、复利清零 |
| 2 | 文档 | CLAUDE.md、SOP、手册 | 流程失忆、质量不稳 |
| 3 | 知识库 | 第12章的 KB、问答对、评测集 | AI 产出质量下降 |
| 4 | 配置 | settings.json、.env、dotfiles | 工作流瘫痪 |
| 5 | 凭据 | API key、token、SSH key | 一切停摆 + 安全风险 |
| 6 | 部署 | Dockerfile、CI/CD、域名 | 产品下线 |
| 7 | 对话记录 | 历史会话、子代理 transcript | 经验断档、无法复盘 |
为什么是这七类？ 因为它们恰好覆盖一人公司的全部生产要素：前两类（代码、文档）是产物，第三、四类（知识库、配置）是放大器，第五类（凭据）是钥匙，第六类（部署）是对外交付的出口，第七类（对话记录）是经验沉淀。漏掉任何一类，重建时都会卡壳——你能 clone 代码、恢复配置，却发现历史会话里那个反复打磨的 prompt 模板找不回来了，等于丢了一段隐性资产。
一个常见的盲区：对话记录。很多人不把它当资产，但它承载了你的调试思路、prompt 迭代轨迹、子代理编排放法。第12章的知识库是显性沉淀，对话记录是隐性沉淀的原料。定期导出成 markdown 按会话 ID 索引，是把它从「平台缓存」变成「可检索资产」的唯一办法。
能做什么
- 盘点——把这七类资产逐项列出，标注当前存在哪、有几个副本。
- 冗余——每类资产至少两份异构副本（不同介质、不同位置）。
- 迁移——每类资产都有一个「搬到新平台」的明确路径。
- 重建——有一份从空机起步的重建文档，且演练过。
不能做什么（边界）
- 不能替你做安全决策——凭据要不要进仓库、要不要加密，是第28章的红线，本章只给存储策略。
- 不能保证零损失——RPO（数据丢失窗口）永远大于零，备份是缩小损失，不是消除损失。
29.3 三层备份模型：本地 / 云端 / 仓库
一人公司的三层冗余
┌──────────────────────────────────────────────┐
│ 仓库层 (git) 代码/文档/配置/部署 │
│ ↑ 每类资产都先入 git，分支可追溯 │
├──────────────────────────────────────────────┤
│ 云端层 (对象存储) 知识库/对话记录/大文件 │
│ ↑ 异地副本，客户端加密后上传，跨区域 │
├──────────────────────────────────────────────┤
│ 本地层 (NAS/外置盘) 全量快照 + 凭据加密库 │
│ ↑ 离线可用，应对云服务中断 │
└──────────────────────────────────────────────┘
规则：任何资产至少出现在 2 层；凭据必须 3 层且加密。29.3.1 仓库层（git）
git 仓库是一人公司的事实源（source of truth）。代码、文档、配置、部署脚本、CLAUDE.md 全部入 git。这一层解决「可追溯」和「可迁移」——push 到一个远端，新设备 clone 下来就是半个环境。
- 私有远端：至少两个（异构平台，避免单平台封号同时命中）。
- 敏感过滤：
.env、密钥文件进.gitignore，绝不入库（见第28章）。 - commit 粒度：小步提交，message 可读，便于回滚定位。
- 验证动作：每月在一个干净目录
git clone一次远端，确认能独立跑通——这是这一层的「恢复演练」。
29.3.2 云端层（对象存储）
知识库向量数据、对话记录 transcript、大体积数据集这些不适合入 git的资产，走云端对象存储。
- 客户端加密：本地加密后上传，云端只见密文（零知识架构）。
- 跨区域：选两个地理区域，防单区域故障。
- 格式开放：存 markdown / json / sqlite，不存私有二进制格式——这是「可迁移」的前提。
- 验证动作：每季度下载一份云端备份，本地解密打开，确认文件未损坏、密钥链可用。
29.3.3 本地层（NAS / 外置硬盘）
本地层是离线保险。云服务会宕机、会封号、会涨价，本地副本让你在云端不可用时仍能工作。
- 定期快照：每周一次全量，每日增量。
- 物理隔离：关键备份离线存放（拔线的硬盘不会被勒索软件加密）。
- 凭据库：用密码管理器（如 1Password / KeePass）本地加密存储，主密码人脑记忆 + 纸质封存。
- 验证动作：每季度模拟「断网」，只靠本地层工作一天，确认离线可用性。
三层的验证动作都不是「存完就完」，而是各自一次微型恢复演练。这呼应了 29.1 的铁律：没演练过的不算资产。
铁律：三层不是「三选一」，是「至少两层 + 凭据三层」。冗余的成本永远低于重建的成本。
29.4 七类资产的备份与迁移策略
| 资产 | 主存 | 第二副本 | 迁移路径 | 重建难度 |
|---|---|---|---|---|
| 代码 | git 私有仓库 | 第二远端 + 本地 clone | git clone 即恢复 | 低 |
| 文档 | 仓库内 markdown | 云端对象存储 | 复制 markdown | 低 |
| 知识库 | sqlite / 向量库 | 导出 json + 云端 | 重建索引即恢复 | 中 |
| 配置 | dotfiles 仓库 | 云端 + 本地 | stow / 软链恢复 | 低 |
| 凭据 | 密码管理器 | 加密备份 + 纸质主密码 | 主密码解锁即恢复 | 高（主密码丢=全完） |
| 部署 | IaC 仓库 | 容器镜像仓库 | docker compose up | 中 |
| 对话记录 | 定期导出 md | 云端 + 本地 | 按会话 ID 索引 | 中 |
关键观察：凭据是唯一「主密码丢失即全完」的资产。它的备份策略必须独立设计——主密码人脑记忆 + 纸质封存两份（异地），密码库本身三层冗余。其他六类丢了还能补救，凭据丢了是灾难。
第二观察：代码、文档、配置、部署这四类的共同点是都适合入 git——它们都是文本、可 diff、可回滚。把这四类统一收进 git 仓库（可以分仓，也可以一个 monorepo），等于一次性解决「可追溯 + 可迁移 + 可重建」三件事。这是性价比最高的一步，优先于其他所有备份动作。
第三观察：知识库和对话记录的难点在格式。很多平台用私有二进制或闭源数据库存这些数据，导出时如果只有私有格式，等于把锁和钥匙一起交给了平台。第12章强调过知识库要用开放格式存储，本章补上后半句：导出格式不开放的知识库，不算你自己的知识库。
凭据的四件套
凭据是七类资产里最特殊的一类，单独拆出来讲清楚。它的备份必须满足四个条件，缺一即破：
凭据四件套
1. 主密码 人脑记忆（唯一允许存在于脑中的东西）
2. 密码库 三层加密冗余（本地 + 云端 + 离线外置盘）
3. 主密码副本 纸质封存两份，异地存放
4. 解密链路 每季度验证：用主密码解开密码库，取一个 key 用一次第4点是绝大多数人漏掉的。密码库「存了」不等于「能打开」——加密软件升级、文件损坏、主密码记混，任何一个都能让密码库变成废铁。每季度解一次、用一次，是把它从「存了」变成「活着」。
29.5 迁移：把资产从「平台人质」变成「可携带资产」
迁移决策树
某资产当前依赖某平台，是否可迁移？
│
├─ 数据格式开放（md/json/sqlite）？
│ ├─ 是 → 导出脚本即可迁移，成本低
│ └─ 否 → 写一次性导出工具，或逐步改用开放格式
│
├─ 有定时导出机制？
│ ├─ 是 → 封号前最后一份数据可用
│ └─ 否 → 先建导出 SOP，每周自动跑一次
│
└─ 有替代平台/工具？
├─ 是 → 迁移目标明确，直接演练
└─ 否 → 至少把数据导出存好，等替代品出现平台人质的三个征兆
- 数据只进不出——平台只让你上传，没有导出按钮，或导出格式是私有二进制。
- 能力不可替代——你的工作流深度依赖某个独家功能，离开它就要重写。
- 账号可被单方面封禁——平台可以无理由停你的号，你无有效申诉渠道。
命中任何一条，就要立即启动「数据导出 + 替代方案调研」。这是第28章风险红线在运营层的延续——红线是「不踩」，迁移能力是「踩了也能跑」。
迁移走查（脱敏范式）
讲一个可迁移的工程范式，不涉及具体平台。假设你的某个工作流深度依赖某 SaaS 平台 A，命中了「数据只进不出」和「账号可被单方面封禁」两条。迁移走查分四步：
1. 导出盘点：列出 A 上所有你的数据类型（配置 / 历史 / 资产 / 关系）
对每类判断：能导出吗？格式开放吗？多久导出一次？
2. 格式归一：把私有格式批量转成 md / json / csv / sqlite
这一步往往是最大工作量，写一次性脚本即可
3. 替代选型：找 1-2 个能消费同样开放格式的替代品 B / C
不要求功能对等，要求「核心工作流能跑通」
4. 双轨切换：A 和 B 同时跑一个月，A 主 B 副
一个月后反转，B 主 A 副，再一个月停 A关键：第2步的「格式归一」是整个迁移的灵魂。一旦你的资产以开放格式存在于自己的存储里，平台 A 就从「人质看守所」变回了「可选工具」——你随时能走，它就锁不住你。这也是为什么 29.3.2 强调云端层必须存开放格式。
反例：很多人迁移失败，是因为跳过第2步，直接找「功能一样的替代品」。但功能完全一样的替代品几乎不存在，于是迁移永远拖延，直到某天平台封号，资产瞬间归零。先把数据以开放格式导出来，再慢慢找替代品——这个顺序不能反。
29.6 实战：业务连续性清单（端到端）
业务连续性有两个硬指标，先把基线立起来：
RTO (Recovery Time Objective) 恢复时间目标
从灾难发生到恢复生产力的最长允许耗时
一人公司建议基线：核心工作流 RTO ≤ 4 小时
RPO (Recovery Point Objective) 恢复点目标
灾难发生时最多允许多少数据丢失（按时间计）
一人公司建议基线：核心资产 RPO ≤ 24 小时这两个数字不是拍脑袋，是从你的「停机一天损失多少」反推的。独立开发者通常没有 SLA 压力，但 RTO 超过一周、RPO 超过一周，意味着一次设备故障就能让业务停摆半个月——这是不可接受的。下面的四步，本质都是在压低 RTO 和 RPO。
步骤一：资产盘点（半天）
资产盘点表（填出来）
┌────┬────────┬──────────┬──────────┬──────────┐
│ 类别 │ 当前位置 │ 副本数量 │ 最后备份日 │ 可迁移? │
├────┼────────┼──────────┼──────────┼──────────┤
│ 代码 │ │ │ │ │
│ 文档 │ │ │ │ │
│ 知识库│ │ │ │ │
│ 配置 │ │ │ │ │
│ 凭据 │ │ │ │ │
│ 部署 │ │ │ │ │
│ 对话 │ │ │ │ │
└────┴────────┴──────────┴──────────┴──────────┘验收：每一行都填了，没有空白格；副本数量 ≥2。
步骤二：三层冗余（一天）
为每类资产补齐缺失的副本层。优先级：凭据 > 代码 > 知识库 > 其他。
# 典型动作（示例，按你的实际栈调整）
git remote add backup <第二远端> # 代码加第二远端
rclone sync ./kb/ remote:kb-encrypted/ # 知识库加密上云
tar -czf - ~/.config | gpg -e > backup.tar.gpg # 配置加密打包验收：每类资产在三层中至少出现两层；凭据三层齐全且加密。
步骤三：恢复演练（关键，每季度一次）
这一步是整章的重点。没做过恢复演练的备份，等于没有备份。
恢复演练 SOP（每季度跑一次）
1. 找一台干净设备（或新建一个用户账号）
2. 只凭备份和重建文档，从零搭起工作环境
3. 记录每个卡点：少什么、忘什么、什么文档写错了
4. 修复文档，补齐缺失资产
5. 记录 RTO（从开始到恢复生产力的耗时）验收：能在 4 小时内恢复 80% 的生产力；RTO 每季度缩短或至少持平。
步骤四：迁移演练（每半年一次）
挑一个你最依赖的平台，演练「假设明天被封号，我多久能切到替代方案」。只导出数据不算演练，要真能在替代方案上跑起来。
验收：能在一周内完成核心资产的迁移切换，且关键工作流不中断。
失败边界（演练排查）：
| 症状 | 根因 | 处理 |
|---|---|---|
| 演练时备份打不开 | 格式过时 / 加密密钥丢失 | 立即修格式 + 验证解密链路 |
| 恢复后少了一堆东西 | 盘点漏项 | 回到步骤一重新盘点 |
| RTO 越练越长 | 环境变复杂没更新文档 | 重建文档与代码同步更新 |
29.7 失败边界：五种最常见的死法
死法一：只存在脑子里
症状：关键流程、密码、配置全靠记忆，没有文档。换个人、换台机器、生一场病，业务就停。
根因：把「我记得」当成了资产。但记忆不可迁移、不可重建、还会衰减。
对抗：强制规则——任何操作做过两次，必须写成 SOP 入库（呼应第12章知识沉淀系统）。脑子里只允许存在一件事：密码管理器的主密码。
死法二：凭据无备份
症状：API key 只在某个 .env 里，SSH key 只在本机，密码只靠浏览器记住。机器一丢，全部停摆，还要紧急吊销重置一堆服务。
根因：凭据是最重要却最容易被忽略的资产。它体积小、日常不碰、出事才想起来。
对抗：所有凭据进密码管理器；密码库三层加密冗余；主密码纸质封存两份异地。这是不可让渡的红线。
死法三：平台封号
症状：某天醒来发现某个 SaaS 账号被封，存在里面的数据、配置、工作流瞬间不可用。
根因：单平台依赖 + 没有异地副本。平台对你的资产有生杀大权。
对抗：任何平台上的资产，每周自动导出一次到本地/自有存储；关键平台预先找好替代品并演练过。平台是工具，不是仓库。
死法四：设备损坏 / 丢失
症状：电脑进水、被盗、硬盘坏道。本地唯一副本没了。
根因：本地层是唯一副本，或云端副本早已过期。
对抗：本地层永远不是唯一副本。每日增量备份到云端 + 每周全量到本地外置盘。重要设备开启全盘加密，丢失后可远程擦除。
死法五：备份从未恢复演练
症状：备份一直有，但出事时才发现：备份是坏的、格式过时了、解密链断了、少关键文件。看着一堆备份，一个都用不上。
根因：把「备份」当成了终点，忘了备份只是手段，恢复才是目的。
对抗：每季度做一次 29.6 步骤三的恢复演练。没演练过的备份不算资产，因为它的可重建性是未知的。
红线边界：不可让渡的决策
- 主密码：必须人脑记忆 + 物理封存，不能交给任何线上服务托管。
- 凭据是否入仓库：即便自动化程度再高，密钥永远不入 git（呼应第28章红线）。
- 恢复演练的验收：RTO 是否达标必须人审，不能靠脚本自报通过。
29.8 小结 / 核心心法
不能重建的系统不属于你，不能迁移的资产只是平台人质。资产所有权的凭证是「恢复过」，不是「存了」。
- 资产所有权 = 可迁移性 × 可重建性，乘法关系，任何一项为零资产就不属于你。
- 七类资产（代码/文档/知识库/配置/凭据/部署/对话记录）各有备份策略，凭据是唯一的高危类。
- 三层冗余（仓库/云端/本地）是底线，凭据必须三层且加密。
- 迁移把平台人质变成可携带资产：开放格式 + 定时导出 + 替代方案。
- 恢复演练每季度一次，没演练过的备份等于没有备份。
这呼应第01章的公式三·复利资产——资产只有能被复用、能被迁移、能被重建，复利才成立；一份被平台锁死、换机即丢的资产，复利直接归零。也呼应第12章的知识沉淀系统——沉淀下来的东西如果丢了，沉淀就白做了。备份与迁移，是把前 28 章积累的所有资产「钉死归你」的最后一颗钉子。
执行清单（每季度演练 + 每周自检）：
- [ ] 七类资产盘点表填完，无空白格
- [ ] 每类资产至少两层冗余，凭据三层且加密
- [ ] 本季度做过一次恢复演练，RTO 有记录
- [ ] 本半年做过一次迁移演练，至少一个核心平台有替代方案
- [ ] 所有平台数据每周自动导出到自有存储
- [ ] 主密码人脑记忆 + 两份异地纸质封存
- [ ] 重建文档与代码同步更新，没有过时段落
上一章：第28章 风险红线 下一章：第30章 终章：你的下一步