备份与恢复 — monitor 文档

数据页有三个按钮。它们碰的是整个数据库，所以边界值得说清楚。

备份

下载一份完整的数据库副本。

副本先写在库文件旁边，权限立刻收到 0600，然后打开即删除——文件只在这次响应活着的时候存在，你半路取消也不会留下一份完整的库躺在磁盘上。

导出走的是自己的一条连接，不占 agent 上报用的那把锁，所以备份期间节点照常上报。

导出的文件就是全部凭证。 里面有节点 token 的明文、GitHub Client Secret、管理员密码哈希和所有登录会话。它和 monitor.db 是同一个密级——按密钥保管，别丢进网盘或者代码仓库。

恢复

用上传的备份覆盖当前库。这是面板上唯一一个能一次删掉所有数据的操作，而文件来自谁的磁盘 hub 并不知道，所以在任何一页被复制之前先逐条检查：

PRAGMA integrity_check 必须是 ok
不能有 view 或 trigger——恢复是逐页复制，本该是表的地方放一个视图，等于让上传者的代码跑在 hub 的写路径上
八张表一张都不能少，否则它不是这个 hub 的备份
schema 版本不能高于当前 hub（来自更新的版本，降级读不了）；低于就在恢复后跑迁移
page size 必须一致

任何一条不过就拒绝，当前库一个字节都不动。

恢复之后

所有登录会话作废，点按钮的人当场换发一张新的，不会把自己踢出去
所有 agent 连接断开，让它们重连去对新的库
快照缓存失效

上传是分片的

单片 4 MiB，所以反代的请求体上限只需要 8 MiB，不随数据库增长—— 256 MiB 的备份也只是 64 个 4 MiB 的请求。

nginx 默认的 client_max_body_size 1m 连一片都放不过去。收到 413 时面板会直接把这个参数念给你看。

回收空间

三件事一起做：按保留天数清过期明细、VACUUM、截断 WAL。

WAL 模式下不截断的话文件只会变大不会变小，所以这三步是一套，不是三个独立按钮。

需要和数据库等量的空闲磁盘。不够就失败回滚，原库不受影响。

搬到另一台机器

# 旧机器：停服务，复制整个数据目录
systemctl stop monitor-hub
tar czf monitor-data.tar.gz -C /opt/monitor data
 
# 新机器：先装 hub，再把数据放回去
sudo sh install-hub.sh
systemctl stop monitor-hub
tar xzf monitor-data.tar.gz -C /opt/monitor
chown -R monitor:monitor /opt/monitor/data
systemctl start monitor-hub

bash

域名指过来之后，所有 agent 会自己重连，什么都不用改——它们连的是域名不是 IP。

如果换了域名，那就得在每台节点上重跑一遍安装命令。

也可以用面板的备份 / 恢复走同一件事，但直接拷目录更省事：连主题目录一起过去了。

定期备份

没有内置的定时备份——那是 cron 的事，不是探针的事：

# 每天凌晨 4 点，保留 14 天
0 4 * * * sqlite3 /opt/monitor/data/monitor.db ".backup '/backup/monitor-$(date +\%F).db'" \
  && find /backup -name 'monitor-*.db' -mtime +14 -delete

bash