企业官网建设流程全解析

Containerd 元数据备份与恢复：手动 4 步 + systemd 自动跑，生产环境完整指南

【免费下载链接】containerdAn open and reliable container runtime项目地址: https://gitcode.com/GitHub_Trending/co/containerd

昨晚某个节点的 meta.db 损坏，整台机器上的容器全部起不来。别慌，这篇把 Containerd 元数据备份与恢复讲透：从停服务到校验文件，照着做就行。

丢了会怎样：meta.db 故障的真实代价

• 服务直接断：containerd 读不到容器和任务状态，节点上新部署全部卡死。
• 镜像状态悬空：层数据还在磁盘上，但索引丢了，没人认得它们。
• 快照引用失效：正在跑的容器对应"孤儿层"，占空间不说，排查起来更麻烦。

说白了，meta.db 不是"配置之一"，它丢了，上面这些东西全得手工对账。

30 秒看懂元数据是怎么存的

• 底层用 BoltDB，所有元数据集中在一个 meta.db 文件里，靠事务保证一致性（见 core/metadata/bolt.go）。
• 命名空间做隔离，default之外可以按团队再分桶。
• 容器、镜像、快照之间靠引用关系串起来，引用计数决定谁能被清理。
• GC 按引用计数回收无主资源，所以备份文件必须完整，半截的引用会引发误删。

默认路径就是/var/lib/containerd/meta.db，要备份的也只有它一个。

备份两条路线：手动四步 & systemd 自动跑 🔁

如果你只想偶尔备一次，手动四步够用；节点多的话，更省事的做法是让 systemd 替你跑。

手动备份四步走：停、拷、验、启

校验依赖 bbolt 工具，没装过先执行go install go.etcd.io/bbolt/cmd/bbolt@latest。然后：

# 第一步：停服务，避免 BoltDB 正在写入 sudo systemctl stop containerd # 第二步：拷贝 meta.db，文件名带日期 sudo cp /var/lib/containerd/meta.db /backup/meta_$(date +%Y%m%d).db # 第三步：BoltDB 完整性校验 bbolt check /backup/meta_$(date +%Y%m%d).db # 第四步：起服务 sudo systemctl start containerd

记住第三步，备份没校验过等于没备。

用 systemd 定时器把备份变成日常

脚本放到/usr/local/bin/containerd-backup.sh（备份脚本：停-拷-验-启，带 30 天滚动保留）：

#!/bin/bash # Containerd 元数据备份：停-拷-验-启 DIR=/backup/containerd TS=$(date +%Y%m%d_%H%M%S) mkdir -p "$DIR" systemctl stop containerd cp /var/lib/containerd/meta.db "$DIR/meta_$TS.db" if bbolt check "$DIR/meta_$TS.db"; then systemctl start containerd find "$DIR" -name 'meta_*.db' -mtime +30 -delete else systemctl start containerd echo "meta_$TS.db check failed" >&2 fi

对应的 service 单元：

[Unit] Description=Containerd metadata backup [Service] Type=oneshot ExecStart=/usr/local/bin/containerd-backup.sh

timer 单元，每天跑一次，错过会补跑：

[Unit] Description=Daily backup timer for Containerd metadata [Timer] OnCalendar=daily Persistent=true [Install] WantedBy=timers.target

最后启用这套 systemd 定时备份：

sudo systemctl enable --now containerd-backup.timer

恢复演练：从备份文件到服务拉起

meta.db 恢复就是备份的倒放，全程四行命令。只多一个容易忘的动作：拷完记得改回 root 属主。

sudo systemctl stop containerd sudo cp /backup/containerd/meta_20260901.db /var/lib/containerd/meta.db sudo chown root:root /var/lib/containerd/meta.db # 可选：确认有损坏文件时再跑 bbolt fix sudo bbolt fix /var/lib/containerd/meta.db sudo systemctl start containerd

起不来就先别重启循环，看 journal 里的报错再定位。

进阶速览：Checkpoint 与监控（可选阅读）

• Checkpoint：想连进程状态一起备，就靠 CRIU 打单容器快照，一条命令：ctr container checkpoint --rw my-container my-checkpoint。它补的是"运行中状态"，不能替代 meta.db 备份。
• 监控：containerd 自带 Prometheus 指标，把备份任务成败、meta.db 体积接进告警。容器数据可靠性不是靠运气，是靠告警先于用户发现问题。

上线前 5 条检查清单 📋

• 每月做一次恢复演练，没测过的备份不可信
• 备份异地存放一份，别只留本机磁盘
• 备份成败接入 Prometheus 告警
• 定保留策略，滚动保留最近 30 天
• 用 LVM/ZFS 文件系统快照做增量备份

高频疑问

Q：不停服务能不能直接拷？A：不建议。BoltDB 写入时持锁，热拷容易拿到半截文件。想低峰少停机，可以改用 LVM/ZFS 先打文件系统快照再拷。

Q：备份了 meta.db 就等于备份了镜像？A：不等于。meta.db 只存配置和状态，镜像层、快照文件在/var/lib/containerd下的其他目录里。整机要完整，snapshotter 目录和内容目录得一起带上。

Q：恢复完直接起服务行吗？A：可以，但建议先对新文件跑一遍 bbolt check 确认干净。启动报文件损坏，就补一条 bbolt fix 再起。

备份文件、演练恢复、接上告警，这套 Containerd 元数据备份功课就齐了。更多细节看官方文档 docs/。

【免费下载链接】containerdAn open and reliable container runtime项目地址: https://gitcode.com/GitHub_Trending/co/containerd