わたしの部屋

业务迁移流程#

业务顺利切完并验证通过后，再启动备份端的迁移：

备份迁移流程#

拆成四个桶，每桶一组凭证#

之前在 Spaces 用的是”一个 Space + 五个前缀”。

这次直接拆成一台机器一个桶，每个桶配一组独立的 Object Read & Write Token：

• restic-oracle-amd1
• restic-oracle-amd2
• restic-oracle-arm
• restic-aliyun

（实际桶名带了更完整的机型描述。）

DigitalOcean-SGP1 即将退役，那台的历史仓库不迁，归档桶也直接删掉。

每个桶统一：

• 关闭 Public access 和 r2.dev
• 不配 Custom domain
• Storage class 用 Standard
• Bucket Lock 不开启（原因见后文）
• Object expiration 不配
• Lifecycle 默认靠 R2 自身对未完成分段上传的 7 天自动中止（迁移后我又加了一条 1 天的显式清理，见后文）

env 切到这种形式（敏感值由 /etc/restic/env 管理，不入文章）：

1
export AWS_ACCESS_KEY_ID="<R2 Access Key ID>"
2
export AWS_SECRET_ACCESS_KEY="<R2 Secret>"
3
export AWS_DEFAULT_REGION="auto"
4
export RESTIC_REPOSITORY="s3:https://<ACCOUNT_ID>.r2.cloudflarestorage.com/<对应桶>"

AWS_DEFAULT_REGION=auto 是 R2 的正式区域值。

空值和 us-east-1 也会被映射到 auto，所以不是绝对硬性要求；但显式写上能把”我连的是 R2”直接表达在配置里，省得日后读 env 时再回头翻文档（R2 S3 兼容 API）。

一台机器一个桶，是因为 R2 的长期 Token 只能做桶级授权，不能按前缀做同等程度的永久隔离。

共用一个桶、一组凭证的话，任意一台泄露，攻击者就能删光整桶。

每台一个桶、每桶一组独立 Token 后，单机泄露最多影响自己的仓库，爆炸半径小一个数量级。

把历史快照原样搬过去#

用 rclone copy 整体复制仓库，历史快照也随之保留——Restic 仓库本质是 data/、index/、snapshots/、keys/ 下互相关联的对象，整体复制过去就等于历史全在。

迁移期间的冻结流程：

四台都没装 rclone，而阿里云国内 IP 被官方下载站屏蔽，所以最后是先把官方静态二进制下到本机过 SHA256，再 SCP 推上去，避免不同发行版包源差异。

复制参数：

1
rclone copy "do:${old_path}" "r2:${bucket}" \
2
  --config /etc/restic/rclone-migration.conf \
3
  --immutable \
4
  --fast-list \
5
  --transfers 8 \
6
  --checkers 16 \
7
  --stats 1m --stats-one-line

阿里云链路不稳时调到 --transfers 4 --checkers 8。

然后两边一致性比对：

1
rclone size "do:${old_path}" --json
2
rclone size "r2:${bucket}" --json
3
rclone check "do:${old_path}" "r2:${bucket}" \
4
  --size-only --one-way

--size-only 只比较路径和大小、不比较哈希；--one-way 还会忽略目标端多出来的对象（rclone check 文档）。

所以四个仓库输出 0 differences found 只能说明”源端对象在目标端都存在、大小一致”，不是哈希级校验。

完整的证据链是后面继续跑的 restic check --read-data-subset=1G 和抽样恢复——这两个过了，才能说仓库搬过去了没坏。

迁移完：

• /etc/restic/rclone-migration.conf 这种含双端凭证的临时文件必须物理删
• /etc/restic/env 改完后旧配置留一份 env.pre-r2-20260716，等 R2 稳定几天再删

调保留窗口#

原本四台都是 daily 7 / weekly 4 / monthly 6，之前为了省空间临时缩到 daily 3 / weekly 2 / monthly 1。

但迁完 R2 实际只有 2 GB，离 10 GB 还有 8 GB 的余量，继续牺牲恢复窗口没意义——激进保留意味着两三周后才发现误删，可能已经没有合适的恢复点。

调回 7/4/3，等仓库真长到 8 GB 再说。

砍掉可重建的内容#

AMD2 和 Aliyun 不再备份可从 Git 重新部署的 /www/wwwroot/MyBlog。

Oracle ARM 新增排除了：

• HTML 图片缓存（/opt/qq-bot/data/html_imgs）
• emoji 缩略图 and Pixiv 爬虫插件的图片下载缓存

仍然保留的是：

• qq-bot SQLite 一致性快照
• new-api PostgreSQL 未压缩 SQL
• qq-bot emoji 与 images
• QQ 数据和会话
• 配置、插件、证书
• Nginx、Compose、cli-proxy auths

prune 的代价#

改完保留窗口和排除路径后，要释放空间必须跑 restic forget --prune。

ARM 这一步特别刺激：先从 Spaces 下载约 3.73 GB 旧 pack，拆出仍在被引用的数据块，重新打包成新 pack，再上传。CPU、内存、网络三头吃紧。

我盯着进度看了快 25 分钟，中途 ARM 还因为负载过高出现 SSH 抖动。

给 prune 进程发 USR1 拿实时进度：

1
kill -USR1 <restic_pid>

ARM 仓库从 12.79 GB 瘦到 1.33 GB。

后来补上 AMD1 那一年多的漏备（见后文），实际占用约 2.51 GB。

分级并发#

四台机器差距很大：

• Oracle AMD1 和 AMD2 都是 1H1G
• Aliyun 2H2G
• Oracle ARM 4H24G

Restic 默认会吃满所有 CPU 核并开 5 条 S3 连接，1H1G 上跑一次大 prune 很容易把宿主机打满甚至触发 OOM Killer。

所以分级设置：

• AMD1、AMD2、Aliyun 用 GOMAXPROCS=1 加 s3.connections=2
• ARM 用 GOMAXPROCS=2 加 s3.connections=3

GOMAXPROCS=1 主要约束 Restic 用几个 Go 线程核心，让 CPU 占用降下来，内存峰值略压一点，但不是严格内存上限。

systemd 的 Nice=10 + IOSchedulingClass=best-effort + IOSchedulingPriority=7 这套调度用来降对业务的 CPU 和 IO 争抢，让 prune 跑得”更礼貌”——CPU 和 IO 都能被压一压，但内存这条控制不了。

真要不 OOM，得加 MemoryMax= / MemoryHigh=，或者用 s3.connections 在源头把并发量压住。这次主要靠后者。

Daily / Weekly 职责分层#

原本四个 daily 脚本都跑了 restic backup、restic forget 和 restic check --no-cache。

Weekly 已经在做 forget --prune + check --read-data-subset=1G，daily 再 check 就是重复请求 R2、抢锁、拉长每日窗口。

改成：

• daily：只做 backup + snapshots --latest 5 + 通知
• weekly：负责 forget --prune + check --read-data-subset=1G + --cleanup-cache
• monthly：可选全量 restic check --read-data

—exclude 外置#

原本每台机器的排除项是一长串 --exclude 塞在脚本里，像噪声。

抽到每台独立的 /etc/restic/excludes（权限 600 root:root），脚本里改用 --exclude-file。

改排除项不用动脚本，可读性好很多。

阿里云的中继做成主备#

阿里云国内机不能直连 api.telegram.org，原本只有 Oracle AMD2 一个 SSH forced-command 中继，是单点。

改成先主后备：

• 主通道走 AMD2 的 SSH 强制命令中继
• 失败后自动重试备用通道 AMD1

两条中继脚本都走 restrict,command=... 的 authorized_keys 锁死。

中继断了不等于备份断了——脚本里中继失败只写 WARN: Telegram SSH 通知中继失败，Restic 快照照样保存成功。

但反过来也成立：通知没断只能说明”任务跑过”，不能说明”服务器还活着”。

timer 根本被 systemd 跳过的情况，中继没机会报。

真正的”机器死了”要靠外部心跳（Healthchecks / Better Stack / 自建 Cloudflare Worker ping），不要指望崩溃的服务器自己发失败通知。

s3.retry-attempts 不是 Restic 选项#

最初给的 diff 里有 restic backup ... -o s3.retry-attempts=5，实际跑下来直接因 unknown/invalid option 失败。

Restic 有很多有效 S3 选项（s3.region、s3.bucket-lookup、s3.list-objects-v1……），但就是没有 s3.retry-attempts。

网络重试由后端默认行为处理，真要调的是 --stuck-request-timeout，不是虚构一个重试次数（Restic FAQ）。

为了”看起来更稳”堆参数，最坏的情况是在备份窗口里让脚本因为 unknown option 直接退出，把”备份数据”变成”白跑一趟”。

每条 Restic 参数都要能对应到官方文档。

restic check --no-cache 改成 restic check 也没用#

简单把 --no-cache 删掉并不会让 check 复用长期缓存。

Restic 0.16 起 check 会自动为每次校验创建新的临时缓存，要真正复用现有缓存必须显式 --with-cache（Restic 0.16 完整性检查说明）。

最干净的做法是每日根本不跑 check，校验整个交给 Weekly。

--compression auto 是默认值#

仓库格式 v2 下 auto 本来就是默认，加它只是增加命令噪声（Restic 调优参数）。

还有一条描述错误#

最初的优化报告说”废弃 SSH 通知中继”时，描述成”AMD1/AMD2/ARM 三台机器都通过 AMD2 做 SSH 中继”。

实际只有 Aliyun 用中继，AMD1/AMD2/ARM 都是直接 curl Telegram。

这种描述错误如果不纠正，会让人把通知代理改成全局 HTTPS_PROXY，结果把 Restic 到 R2 的流量也送进 Telegram 代理，把备份自己搞挂。

只在 Telegram 的 curl 局部指定 curl --proxy "$TELEGRAM_PROXY" ...，Restic 命令完全不碰代理环境变量。

容器启停一致性#

卷里有十几个 SQLite 文件。

直接备份运行中的 SQLite 不一定坏，但 WAL 模式下恢复不可靠——备份到一半可能正把 WAL 合并回主库，文件就是不一致的。

备份前短暂停止容器。trap 必须先安装，再执行 docker stop，否则中间会留一段”容器已经停止、但 trap 还没生效”的盲区：

1
WAS_RUNNING=$(docker inspect -f '{{.State.Running}}' qq-bot-core 2>/dev/null)
2

3
cleanup() {
4
  if [ "$WAS_RUNNING" = "true" ]; then
5
    docker start qq-bot-core >/dev/null 2>&1 || true
6
  fi
7
}
8
trap cleanup EXIT INT TERM
9

10
# trap 已装好，再停容器
11
docker stop qq-bot-core >/dev/null 2>&1
12

13
restic backup "${BACKUP_PATHS[@]}" ...

WAS_RUNNING 记录执行前状态，避免把”原本就没跑的容器”误拉起。

trap ... EXIT INT TERM 覆盖正常退出、异常退出、SIGINT、SIGTERM，但不包括 SIGKILL。

我只抽查了 reactions.db，PRAGMA integrity_check 返回 ok。

这不能证明卷里每个 SQLite 都验过，但容器在整个备份窗口里是停的，数据库都没在写；至少确认了这条恢复链路能走通。

trap 救不回 SIGKILL 和掉电

Shell 的 trap 捕获不到 SIGKILL（kill -9、部分 OOM Kill）、主机掉电、内核崩溃。只靠 trap 兜底不够：

• restart: unless-stopped 处理的是 daemon 自己重启时的自动恢复，Docker 官方写明手动 docker stop 过的容器不会被该策略在 daemon 重启后重新拉起（Docker restart policy）
• 第二层兜底更靠谱的是独立 watchdog 或 systemd 恢复单元
• cleanup 函数要幂等，收到 INT/TERM 后明确退出，不要清理完继续往下跑

顺便一起收掉的小问题：

• /var/backups/db 不再整个清空，只删明确的导出文件（sub-bot.sqlite / qq-bot.sqlite / new-api-postgres.sql 及对应 .tmp），保护恢复清单、成功时间戳等静态文件
• 数据库导出加了 test -s 非空校验，导出失败或空文件直接失败报警，不静默用旧副本”假成功”
• /etc/restic/excludes 纳入备份路径，恢复后脚本能跑，排除文件不能丢
• flock 冲突不再 exit 0，改成记录 + Telegram 报警”任务因锁冲突跳过”
• Telegram 失败通知日志从最后 40 行截到 2500 字符，防止超 4096 字符上限被 Telegram 拒收
• systemd Description 从 “DigitalOcean Spaces” 改为 “Cloudflare R2”，过时的显示信息容易误导排查