第 5 章：C 盘爆满那天

“2026 年 3 月 15 日，我的 C 盘红了。”

“64GB 可用空间，一周后只剩 2GB。”

“罪魁祸首，居然是我自己建的备份系统。”

—— 2026 年 3 月 15 日，磁盘清理后的反思

5.1 红色警告

2026 年 3 月 15 日，周一，早上 9 点。

我正准备工作，电脑右下角弹出一个提示：

plaintext

⚠️ 磁盘空间不足C 盘仅剩 2.1GB 可用空间

我愣了一下。

一周前刚看过，还有 64GB 可用。

一周时间，62GB 去哪了？

我打开磁盘分析工具，想看看到底是什么占了空间。

然后我看到了终身难忘的一幕：

plaintext

C:\Users\13908\.openclaw\workspace\├── backup\                    (15GB)│   ├── backup\                (8GB)│   │   ├── backup\            (4GB)│   │   │   └── ...│   ├── scripts_backup_{...}\  (3GB)│   └── workspace_backup_{...}\(4GB)├── backups\                   (12GB)│   ├── backup-20260314-1759\  (6GB)│   ├── backup-20260313-0930\  (3GB)│   └── backup-20260312-1845\  (3GB)├── backup_20260315_175518\    (8GB)└── content\                   (5GB)

我陷入了沉思。

这些备份，都是我亲手建的。

这个嵌套备份的”俄罗斯套娃”，也是我亲手造的。

5.2 备份系统的诞生与失控

故事要从一周前说起。

3 月 8 日，小龙侠配置成功后，我做的第一件事是：

“建个备份系统，数据安全第一。”

初衷是好的：

• 每天自动备份 workspace
• 保留历史版本，防止误删
• 重要文件多地备份

执行也是到位的：

• 写了自动备份脚本 auto-backup.py
• 配置了 Cron，每天 18:00 执行
• 备份到多个位置（本地、E 盘、飞书云）

问题出在哪？

出在”备份备份的备份”。

第一版脚本：

python

# 每天备份到 backup/ 目录backup_to("workspace/backup/")

一周后，我发现 backup/ 里有 7 个备份，占了 15GB。

我想：”这样不行，备份太乱了，得整理。”

于是写了第二版脚本：

python

# 按日期命名备份backup_to(f"workspace/backups/backup-{date}/")

但第一版脚本没删，还在运行。

于是有了两套备份系统，同时运行。

再后来，我又觉得：

• “备份应该保留最近 3 天的”
• “重要文件应该单独备份”
• “脚本修改前后应该各备份一次”

每次”优化”，都增加一套备份逻辑。

每次”增加”，都没删除旧的逻辑。

一周后，就有了 6 套备份系统，同时运行。

结果就是：C 盘爆了。

5.3 清理现场

3 月 15 日那天下午，我做了三件事：

第一步：停止所有备份脚本

bash

# 禁用所有 Cronopenclaw cron disable auto-backupopenclaw cron disable daily-backupopenclaw cron disable weekly-backup# ... 禁用了 6 个备份任务

第二步：删除所有备份

bash

# 全选，删除rm-rf workspace/backup/rm-rf workspace/backups/rm-rf workspace/backup_*/

删除时，我心里在滴血。

那些可都是”数据资产”啊！

但转念一想：

如果一份数据需要备份 6 次才能安全，那不是数据的问题，是人的问题。

第三步：重建备份系统

这次，我只写了一个脚本：

python

#!/usr/bin/env python3# 每周日 20:30 执行，覆盖模式# 只备份关键文件，不累积import shutilfrom datetime import datetimeSOURCE_DIRS =["scripts/","skills/","memory/","00-admin-board/","01-ellemech-company/","02-social-media-matrix/","03-creator-interview/","04-main-commons/"]BACKUP_DEST ="E:\\openclaw 备份\\weekly_backup"# 覆盖老备份，不累积if os.path.exists(BACKUP_DEST):    shutil.rmtree(BACKUP_DEST)# 备份关键文件for src in SOURCE_DIRS:    shutil.copytree(src, os.path.join(BACKUP_DEST, src))print(f"✅ 备份完成：{BACKUP_DEST}")

核心原则：

• ✅ 每周一次（周日 20:30）
• ✅ 覆盖模式（不累积）
• ✅ 只备份关键文件（代码、配置、内容）
• ✅ 排除临时文件（logs/、temp/、node_modules/）

效果：

• 备份时间：约 10 秒
• 备份大小：约 5GB
• 磁盘占用：固定 5GB，不增长

5.4 反思：效率工具变成效率杀手

清理完 C 盘，我算了一笔账：

时间成本

项目	耗时
写第一版备份脚本	30 分钟
写第二版（优化）	45 分钟
写第三版（再优化）	60 分钟
…	…
写第六版	90 分钟
总计	约 5 小时

空间成本

项目	占用
backup/	15GB
backups/	12GB
backup_*	8GB
其他	20GB
总计	55GB

机会成本

这 5 小时和 55GB，如果用在别的地方：

• 可以写 3 篇深度文章
• 可以生成 100 张配图
• 可以分析 10 个行业数据
• 可以陪家人吃 5 顿晚饭

但我用来做什么？

用来备份”还没来得及写的文章”。

用来存储”可能以后会用”的数据。

用来维护”其实根本不需要”的系统。

5.5 三条教训

教训 1：备份是为了恢复，不是为了安心

很多人（包括我）的备份逻辑是：

“备份越多越安全。”

但真相是：

备份越多，恢复越难。

想象一下，如果你需要恢复一个文件：

• 你有 7 个备份位置
• 每个位置有 30 个历史版本
• 你不知道哪个是最新的

那你不是有备份，你是有负担。

正确的逻辑是：

• 备份是为了恢复
• 恢复要快速、简单、确定
• 所以备份要少而精

教训 2：自动化不是越多越好

我当时的想法是：

“所有能自动化的，都要自动化。”

结果是：

• 6 套备份系统同时运行
• 每套系统都认为自己在做正确的事
• 没有一套系统知道其他系统的存在

就像一家公司：

• 6 个部门都在做”重要项目”
• 每个部门都觉得自己的项目最重要
• 但没人知道公司的整体目标是什么

结果：忙得要死，但不知道在忙什么。

教训 3：定期清理比持续备份更重要

我当时以为：

“只要有备份，就不会丢数据。”

但真相是：

数据不是丢的，是被淹没的。

55GB 的备份，大部分是”垃圾”：

• 过时的配置
• 无效的临时文件
• 重复的版本历史

与其花时间备份，不如花时间整理。

5.6 本章小结

核心观点：

1. 备份是为了恢复，不是为了安心
2. 自动化不是越多越好
3. 定期清理比持续备份更重要

金句：

“如果一份数据需要备份 6 次才能安全，那不是数据的问题，是人的问题。”

行动建议：

1. 只保留一套备份逻辑
2. 覆盖模式，不要累积
3. 每周备份一次就够了
4. 每月清理一次备份文件

敬请关注 👇