一个 Linux 运维老炮的备份架构整理

---

前言

最近把自己写的 OpenClaw AI 助手部署在了内网服务器上，日常用它管理知识库、处理任务、对接微信。

但问题来了——AI 助手里存了大量知识库、配置、凭证数据，一旦丢了就是灾难。于是我花了点时间，搭建了一套 三层备份体系，覆盖实时保护、每日全量、云端异地容灾。

这篇文章把技术栈和架构做个梳理，分享给有类似需求的朋友。

---

一、环境概览

项目	内容
操作系统	Ubuntu 24.04 LTS
AI 平台	OpenClaw（开源 AI 助手框架）
服务器位置	内网（192.168.x.x）
云存储	百度网盘
核心原则	纯离线、零成本、可恢复

---

二、技术栈一览

2.1 本地工具

工具	用途	来源
tar	打包压缩	系统自带
cron	定时任务调度	系统自带
inotifywait	文件系统事件监控	apt install inotify-tools
bash	脚本编排	系统自带

2.2 云同步工具

工具	版本	用途
bypy	最新	百度网盘命令行客户端（实时同步用）
rclone	v1.60.1	通用云存储同步工具（全量备份用）
Alist	v3.61.0	多存储聚合网关，提供 WebDAV 接口

2.3 数据流路径

工具链路对比：

bypy:          本地文件 ──→ 百度网盘 API ──→ 云端
rclone+Alist:  本地文件 ──→ rclone ──→ Alist(WebDAV) ──→ 百度网盘

为什么用两套？bypy 适合实时小文件同步，rclone+Alist 适合大文件批量备份，各司其职。

---

三、三层备份架构

┌─────────────────────────────────────────────────────┐
│                   三层备份架构                        │
├─────────────────────────────────────────────────────┤
│                                                     │
│  第一层 │ 实时同步                                   │
│         │ inotifywait 监控 workspace 变化            │
│         │ ──bypy──→ 百度网盘 /openclawbak           │
│         │ 响应速度：秒级                             │
│                                                     │
│  第二层 │ 每日全量备份                               │
│         │ tar 打包整个 /root/.openclaw               │
│         │ ──→ 本地 /data/bak_openclaw_*.tar.gz      │
│         │ 保留策略：2 天，自动清理                   │
│                                                     │
│  第三层 │ 云端异地容灾                               │
│         │ rclone ──Alist(WebDAV)──→ 百度网盘        │
│         │ 只同步 tar.gz 备份包                       │
│         │ 增量上传，不重复传输                       │
│                                                     │
└─────────────────────────────────────────────────────┘

第一层：实时同步（秒级保护）

痛点： 正在编辑的知识库、配置文件，如果服务器突然挂了，会丢失最近几小时的改动。

方案： 用 inotifywait 监控 workspace 目录的文件事件（写入、移动、删除），一旦检测到变化，自动通过 bypy 推送到百度网盘。

技术细节：

• 监控事件：close_write（写入完成）、moved_to（移入）、delete（删除）
• 防抖机制：连续变化时等 5 秒没有新事件再同步，避免频繁触发
• 优点：秒级响应，不丢数据
• 缺点：只覆盖 workspace 目录

第二层：每日全量备份（天级保护）

痛点： 实时同步只覆盖了 workspace，但 OpenClaw 还有配置、凭证、插件等关键数据。

方案： 每天凌晨 3:00 通过 cron 执行打包脚本，把整个 /root/.openclaw 目录打成 tar.gz 存到 /data/。

# 核心就一行
tar -zcvf /data/bak_openclaw_$(date +%Y%m%d).tar.gz -C / root/.openclaw

自动清理： 2 天前的旧备份自动删除，防止磁盘写满。

第三层：云端异地容灾（异地保护）

痛点： 本地备份和服务器一起挂了怎么办？服务器硬盘坏了怎么办？

方案： 每天凌晨 3:30 将本地备份 tar.gz 同步到百度网盘。

链路设计：

rclone sync  /data/bak_*.tar.gz  ──→  Alist(WebDAV)  ──→  百度网盘

这里 Alist 充当了一个 存储网关 的角色。它把百度网盘包装成一个标准的 WebDAV 接口，rclone 通过 WebDAV 协议读写，完全不用关心底层是百度网盘还是其他存储。

为什么用 Alist 而不是 rclone 直连百度网盘？

• Alist 统一了存储接口，后续可以随时切换后端（阿里云盘、OneDrive 等）
• WebDAV 协议兼容性好，rclone、系统自带工具都能用
• 管理后台可视化，方便查看和操作云端文件

---

四、定时任务总览

# 每天 03:00  本地全量打包备份
0 3 * * * /root/openclaw_full_backup.sh

# 每天 03:30  同步备份包到百度网盘
30 3 * * * /root/sync_backup_to_baidu.sh

# 实时（持续运行） workspace 变化实时同步到百度网盘
bash /root/bd_realtime_backup.sh &

三个任务互不依赖，任意一个挂了不影响其他链路。

---

五、架构图（文字版）

                          ┌───────────────────┐
                          │     OpenClaw      │
                          │   /root/.openclaw │
                          └────────┬──────────┘
                                   │
                ┌──────────────────┼──────────────────┐
                │                  │                  │
                ▼                  ▼                  ▼
        ┌───────────────┐  ┌───────────────┐  ┌───────────────┐
        │  实时同步      │  │  每日全量      │  │  云端容灾      │
        │  inotifywait   │  │  tar          │  │  rclone        │
        │  + bypy        │  │  + cron       │  │  + Alist       │
        └───────┬───────┘  └───────┬───────┘  └───────┬───────┘
                │                  │                  │
                ▼                  ▼                  ▼
        ┌───────────────┐  ┌───────────────┐  ┌───────────────┐
        │  百度网盘      │  │  本地 /data/  │  │  Alist WebDAV │
        │  /openclawbak │  │  tar.gz 包    │  │  ↓            │
        └───────────────┘  └───────────────┘  │  百度网盘      │
                                              │  /openclawdata│
                                              └───────────────┘

        响应速度：秒级          频率：每天          频率：每天
        覆盖范围：workspace     覆盖范围：全量      覆盖范围：异地容灾

---

六、一些思考

为什么不用 Docker？

这套备份方案是跑在宿主机上的。OpenClaw 本身也没用 Docker 部署，因为在内网场景下，少一层抽象就少一层故障点。bash + cron 的组合虽然"土"，但可靠。

为什么是百度网盘？

内网服务器通常没有公网 IP，用公有云对象存储（OSS/S3）需要外网带宽。百度网盘免费、容量大、有现成的 CLI 工具（bypy），对内网备份来说性价比很高。

关于恢复

备份做得好不好，最终看恢复。这套方案中：

• 实时同步：文件改了立即上云，基本不丢
• 全量备份：每天一次完整状态，可以恢复到任意一天的快照
• 异地容灾：服务器全炸了也不怕，重新部署后从百度网盘拉下来就行

恢复命令很简单：

# 从百度网盘下载
rclone copy alist:/百度网盘/apps/bypy/openclawdata/ /data/

# 解压恢复
tar -xzf /data/bak_openclaw_20260603.tar.gz -C /

---

七、SMB/CIFS 配置（Windows 直接访问）

备份文件在服务器上，有时想在 Windows 上直接拖文件、打开查看，配个 SMB 共享最方便。

安装配置

# 安装 samba
apt install -y samba

# 添加共享目录 /data
cat >> /etc/samba/smb.conf << 'EOF'

[data]
   comment = OpenClaw 备份数据
   path = /data
   browseable = yes
   read only = no
   guest ok = no
   create mask = 0644
   directory mask = 0755
   force user = root
EOF

# 设置 samba 密码（用系统已有用户）
smbpasswd -a root

# 重启服务
systemctl restart smbd nmbd

Windows 上访问

打开文件管理器，地址栏输入：

\\服务器IP\data

输入用户名和密码（上面设置的）即可像本地磁盘一样读写 /data/ 目录下的文件。

八、结语

这套方案谈不上多高级，但胜在简单、可靠、零成本。适合跟我一样在搞个人/小团队私有化部署的朋友。

三个脚本 + 一个 cron，24 小时无人值守，三层保护兜底。技术不在新，管用就行。