Docker Compose Down误删容器数据 ext4日志恢复全记录

不小心误删了 Docker 容器，运行时数据全部丢失？先别慌张，也不要立即输入命令——立刻停下操作、减少磁盘写入才是最关键的步骤。

如果文件系统是 ext3 或 ext4，按照以下几步操作即可见效。首先停止容器，确认文件系统类型：

# 1. 停掉容器，减少磁盘写入
docker compose stop
# 2. 确认文件系统是 ext3/ext4（不是就别往下看了）
df -T /
# 3. 装工具
sudo apt-get install -y ext4magic

然后直接跳到第四节，按步骤执行。越早开始恢复，能够找回的数据就越多。

恢复成功率与删除时长、后续写入量直接相关。本文最终恢复了大部分会话记录和技能文件，但仍有少量数据未能找回——请提前做好心理预期，不要期待 100% 的恢复率。

一、事故背景

服务器上通过 Docker Compose 部署了 CowAgent（开源 AI 助理框架）。某次需要修改上下文配置以修复 LLM 回答丢失的问题，执行了以下命令：

docker compose down && docker compose up -d

重启后发现：所有会话记录、长期记忆、已安装的技能、知识库全部消失。

二、根因分析

2.1 直接原因

使用了 docker compose down 而非 docker compose restart。

两者之间的区别一目了然：

2.2 深层原因

CowAgent 的 docker-compose.yml 中，/home/agent/cow/ 目录没有被挂载到宿主机。所有运行时数据都位于容器的可写层内：

容器内路径 是否持久化
/home/agent/cow/sessions/ ❌ 随容器销毁
/home/agent/cow/memory/ ❌ 随容器销毁
/home/agent/cow/skills/ ❌ 随容器销毁
/home/agent/cow/knowledge/❌ 随容器销毁
/app/config.json✅ bind mount
/app/agent/memory/ (框架代码) ✅ bind mount

已挂载的是框架的 Python 源代码目录（如 cow_agent/memory/、cow_agent/skills/ 等），但这些仅仅是代码，并非运行时生成的数据。

三、恢复方案选型

四、ext4magic 实战

4.1 环境检查

# 确认文件系统类型
df -T /
# /dev/mapper/ubuntu--vg-ubuntu--lv ext4
# 查看日志大小（关键！越大恢复越多）
sudo dumpe2fs /dev/mapper/ubuntu--vg-ubuntu--lv | grep -i journal
# Total journal size: 512M ← 512MB 日志是恢复成功的关键

踩坑 1：ext4magic 的输出目录必须在与源不同的分区，否则直接报错退出。

# ❌ 错误
sudo ext4magic /dev/sda -d /home/recovery ...
# ✅ 正确——用 /dev/shm (RAM disk)
sudo ext4magic /dev/sda -d /dev/shm/recovery ...

4.2 恢复操作

# 安装工具
sudo apt-get install -y ext4magic
# 恢复指定时间点之前的文件
# -a after-timestamp: 时间起点（Unix 时间戳）
# -b before-timestamp: 时间终点
# -r 文件名模式: 支持通配符
# -d 输出目录: 必须在不同分区！
sudo ext4magic /dev/mapper/ubuntu--vg-ubuntu--lv -r "*.db" -d /dev/shm/recovery -a $(date -d "2026-06-18 03:00:00 UTC" +%s) -b $(date -d "2026-06-18 03:52:00 UTC" +%s)

踩坑 2：-a 和 -b 参数中，-a（after）的时间必须早于 -b（before），不要搞反。-a 是时间范围起点，-b 是终点。

4.3 恢复结果分类

ext4magic 会产生两类恢复文件：

/dev/shm/recovery/
├── MAGIC-1/ # 按 inode 恢复，保留目录结构和文件名
│ └── <13111143>/# SQLite 数据库 + WAL/SHM 文件
│ └── <13111268>/# SKILL.md + manifest.json（安全分析技能）
│ └── <13111972>/# Evolution 备份（0.bak, 1.bak, 2.bak）
│
└── MAGIC-2/ # 文件指纹挖掘（File Carving），无文件名
├── text/plain/ # 按 MIME 类型分类
│ ├── I_0033288956.txt # 47KB xx语言安全审计技能
│ ├── I_0033287573.txt # 8.7KB xx框架鉴权审计技能
│ ├── I_0033289140.txt # 7.8KB 每日记忆
│ ├── I_0033288994.txt # 知识库日志
│ └── ...
└── image/png/# 图片碎片

踩坑 3：MAGIC-2 中的文件是按文件指纹（Magic Number）从磁盘原始数据中挖掘出来的，没有原始文件名。需要通过内容标题来识别是什么文件。例如 47KB 的文本文件，第一行是 language: xx-Vulnerability，才能确认它是xx语言安全审计技能的 SKILL.md。

踩坑 4：MAGIC-1 中可能存在大量无用的 .pyc 文件、空目录、Docker 容器配置碎片等。需要逐个检查 22 个 inode 目录才能找到有数据的 4 个。

五、SQLite WAL 回放

ext4magic 恢复的 index.db 旁边有 WAL（Write-Ahead Log）和 SHM 文件。直接打开数据库会自动回放：

# 把 db + wal + shm 放到一起
cp index.db /tmp/replay/index.db
cp index.db-wal /tmp/replay/index.db-wal
cp index.db-shm /tmp/replay/index.db-shm
# 用 sqlite3 打开会自动回放 WAL
python3 -c "import sqlite3
conn = sqlite3.connect('/tmp/replay/index.db')
count = conn.execute('SELECT COUNT(*) FROM sessions').fetchone()[0]
print(f'Sessions: {count}')"
# 输出: Sessions: 8（WAL 回放新增了 4 个会话！）

踩坑 5：WAL 文件必须和数据库文件在同一目录下，且文件名必须匹配（xxx.db + xxx.db-wal + xxx.db-shm），sqlite3 才会自动回放。

六、Knowledge Base 前端显示为空

CowAgent 的知识库服务有特殊要求：

# knowledge/service.py 的 list_tree() 逻辑
# 根目录下的 index.md 和 log.md 是特殊文件，不计入列表
# 只有 子目录中的 .md 文件才会被前端渲染

踩坑 6：恢复的知识文件直接放在 knowledge/ 根目录时，前端显示"暂无知识"。必须按分类放到子目录下：

knowledge/
├── index.md # 特殊文件，不在前端列表显示
├── log.md # 特殊文件，不在前端列表显示
├── xx文档/ # ✅ 前端显示
│ └── example.md
└── xx标准/ # ✅ 前端显示
└── example.md

七、恢复成果汇总

已恢复

未恢复内容

八、核心教训

1. 只用 restart，别用 down

# ✅ 正确
docker compose restart
# ❌ 危险——会删除容器及其可写层
docker compose down && docker compose up -d

2. Bind Mount 一切运行时数据

volumes:
# 除了代码和配置，必须挂载运行时数据目录
- ./cow_home:/home/agent/cow # ← 这行是关键

3. 事故后立即停止写入

越早停止容器运行，ext4 日志中被覆盖的 inode 越少，恢复成功率越高。

4. ext4 日志大小直接决定恢复上限

512MB 日志能保留一定时间内的文件系统变更，最终恢复了大部分关键数据。如果日志只有默认的 32MB，恢复成功率会大幅下降。

5. File Carving 是最后的救命稻草

即使文件系统元数据（inode）已被回收，文件内容本身可能仍残留在磁盘上。通过文件指纹（Magic Number）挖掘可以恢复部分内容，缺点是丢失了文件名和目录结构。

6. 上线前自检清单

# 1. 确认所有运行时路径已 bind mount
docker inspect <容器名> --format='{{range .Mounts}}{{.Destination}} ← {{.Source}}{{"\n"}}{{end}}'
# 2. 模拟 down up，验证数据仍在
docker compose down && docker compose up -d
docker exec <容器名> ls /home/agent/cow/AGENT.md
# 应返回文件路径
# 3. 定时备份已配置且测试通过
crontab -l | grep backup
ls -la ./backups/auto/ | tail -3
# 4. 团队统一使用 restart，禁用 down
alias dc-restart='docker compose restart'