Containerd 元数据备份与恢复两套备份方案、四步救回和三个必避的坑【免费下载链接】containerdAn open and reliable container runtime项目地址: https://gitcode.com/GitHub_Trending/co/containerd深夜一块盘报了坏道节点失联。你重装 containerd 想抢救容器列表、镜像记录、快照关系却全没了。救你的是上周随手备份的那个 meta.db 文件。所以 Containerd 元数据备份这件事最好在灾前就做而不是灾后。 一图看懂元数据在 Containerd 里的位置上面是 Containerd 的经典架构图。看中间那块 Metadata存的不是镜像本身而是一本“地址簿”——哪个容器存在、镜像引用哪些层、快照之间什么父子关系、租约指向谁全都写在一个 BoltDB 数据库文件里。左边 Storage 才是实体数据blob 和快照目录右边 Tasks/Events 是运行期状态。也就是说元数据备份针对的就是 meta.db 这一个文件数据丢了能找回来地址簿丢了数据就没人认。这个存储层的实现在 core/metadata/数据库在 core/metadata/db.go 里打开。 动手前 60 秒先找到你的 meta.db写脚本之前先确认三件事containerd --version ls -lh /var/lib/containerd/io.containerd.metadata.v1.bolt/ mkdir -p /backup/containerd第一条确认版本2.x 与 1.x 默认配置有差异第二条找到真正的 meta.db——注意它在io.containerd.metadata.v1.bolt/子目录下而不是仓库里某些教程写的 /var/lib/containerd/ 根部目录结构可对照 docs/ops.md第三条建好备份目录。这一步防的是备份脚本对着错误文件跑拷出来一份没用的副本。应急式手动备份meta.db 备份命令就四条顺序固定停服务、拷贝、校验、拉起。先判断再动手。BoltDB 同一时刻只允许一个写进程服务运行时拷贝等于边写边拍照文件大概率不完整。systemctl stop containerd防的是不一致状态进备份恢复那天打不开。带时间戳拷贝。cp /var/lib/containerd/io.containerd.metadata.v1.bolt/meta.db \ /backup/containerd/meta_$(date %F).db防的是备份互相覆盖出问题回退不到“昨天的样子”。校验合格才算数。go install go.etcd.io/bbolt/cmd/bboltlatest bbolt check /backup/containerd/meta_2026-09-05.db防的是拷成功但已损坏盘坏、空间不足。check 通过的备份才敢信。拉起服务收工。systemctl start containerd防的是忘了拉起导致节点长时间无服务。停服务前可以先ctr tasks ls看看有没有在跑的关键容器有就挑低峰期。⏰ 让备份自己跑systemd 定时器方案手动方案熟悉后把例行活交给机器。脚本骨架只需要五个动作#!/bin/bash set -e systemctl stop containerd cp /var/lib/containerd/io.containerd.metadata.v1.bolt/meta.db \ /backup/containerd/meta_$(date %Y%m%d).db systemctl start containerd find /backup/containerd -name meta_*.db -mtime 30 -delete # 保留 30 天最后一行是保留策略超过 30 天的备份自动清掉。整套脚本防的是靠人记“该备份了”以及备份目录无限膨胀。再套一个定时器让它每天跑[Timer] OnCalendardaily Persistenttrue以上写入 /etc/systemd/system/containerd-backup.timer对应 service 设Typeoneshot、ExecStart指向脚本然后systemctl enable --now containerd-backup.timer防的是机器重启后定时器没人拉起Persistenttrue还会补跑停机期间漏掉的备份。真出事时四步把 meta.db 救回来按这个顺序来不用多想systemctl stop containerd cp /backup/containerd/meta_20260905.db \ /var/lib/containerd/io.containerd.metadata.v1.bolt/meta.db chown root:root /var/lib/containerd/io.containerd.metadata.v1.bolt/meta.db systemctl start containerd停、放回去、修属主、拉起。属主那行最容易被漏换回的副本如果属主不对containerd 打不开库。起来之后确认地址簿真的回来了ctr images list ctr containers list防的是进程活着但库里是空的“假恢复”。bbolt 校验失败怎么办分两种情况备份时check 报错这份不要入库立刻重拷连续失败就不是文件问题去查dmesg和磁盘 SMART 状态。恢复后containerd 起不来、日志报数据库打开或事务错误确认服务已停再跑一次修复然后重启。bbolt fix /var/lib/containerd/io.containerd.metadata.v1.bolt/meta.dbfix 是会改写文件的修复工具只在“确定坏了”时运行平时别拿来当例行保养。进阶与坑checkpoint 和三个最容易踩的坑只保地址簿是 meta.db 的事要连一个运行中容器的完整状态一起保用 checkpoint——它依赖 CRIU 导出内存和运行期状态实现在 client/container_checkpoint_opts.goctr container checkpoint --rw --task web-demo web-demo-ck ctr container restore --live web-demo-2 web-demo-ck第一条冻结并导出容器含可写层第二条从导出里恢复出一个新容器--live恢复运行时内存。checkpoint 是“单个容器的状态恢复”和整机元数据备份不是一回事别混用。最容易被坑的三处各两行说清坑直接 cp 运行中的 meta.db恢复时打不开。解法先停后拷实在不能停用 LVM/ZFS 快照打一致性时间点。坑只备了 meta.db恢复后镜像、快照报“数据找不到”。解法地址簿不等于数据/var/lib/containerd 整体至少 content 与 snapshotter 目录要一起备。坑备份目录把盘写满恢复时才发现一代备份都没有。解法保留策略设上限并加容量告警每月在测试机上做一次恢复演练。恢复后元数据、镜像层、快照三层要重新互相找得到数据走向可以参考这张图行动清单本周内跑一遍手动备份用bbolt check确认那份 meta.db 合格。部署 systemd 定时器并排一次“停服务 → 放回 → 拉起”的恢复演练。确认机器上是否有 CRIU判断业务是否需要 checkpoint 级别恢复需要就写进值班手册。更多运行目录与配置细节见 docs/ 与 docs/ops.md。【免费下载链接】containerdAn open and reliable container runtime项目地址: https://gitcode.com/GitHub_Trending/co/containerd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Containerd 元数据备份与恢复：两套备份方案、四步救回和三个必避的坑
Containerd 元数据备份与恢复两套备份方案、四步救回和三个必避的坑【免费下载链接】containerdAn open and reliable container runtime项目地址: https://gitcode.com/GitHub_Trending/co/containerd深夜一块盘报了坏道节点失联。你重装 containerd 想抢救容器列表、镜像记录、快照关系却全没了。救你的是上周随手备份的那个 meta.db 文件。所以 Containerd 元数据备份这件事最好在灾前就做而不是灾后。 一图看懂元数据在 Containerd 里的位置上面是 Containerd 的经典架构图。看中间那块 Metadata存的不是镜像本身而是一本“地址簿”——哪个容器存在、镜像引用哪些层、快照之间什么父子关系、租约指向谁全都写在一个 BoltDB 数据库文件里。左边 Storage 才是实体数据blob 和快照目录右边 Tasks/Events 是运行期状态。也就是说元数据备份针对的就是 meta.db 这一个文件数据丢了能找回来地址簿丢了数据就没人认。这个存储层的实现在 core/metadata/数据库在 core/metadata/db.go 里打开。 动手前 60 秒先找到你的 meta.db写脚本之前先确认三件事containerd --version ls -lh /var/lib/containerd/io.containerd.metadata.v1.bolt/ mkdir -p /backup/containerd第一条确认版本2.x 与 1.x 默认配置有差异第二条找到真正的 meta.db——注意它在io.containerd.metadata.v1.bolt/子目录下而不是仓库里某些教程写的 /var/lib/containerd/ 根部目录结构可对照 docs/ops.md第三条建好备份目录。这一步防的是备份脚本对着错误文件跑拷出来一份没用的副本。应急式手动备份meta.db 备份命令就四条顺序固定停服务、拷贝、校验、拉起。先判断再动手。BoltDB 同一时刻只允许一个写进程服务运行时拷贝等于边写边拍照文件大概率不完整。systemctl stop containerd防的是不一致状态进备份恢复那天打不开。带时间戳拷贝。cp /var/lib/containerd/io.containerd.metadata.v1.bolt/meta.db \ /backup/containerd/meta_$(date %F).db防的是备份互相覆盖出问题回退不到“昨天的样子”。校验合格才算数。go install go.etcd.io/bbolt/cmd/bboltlatest bbolt check /backup/containerd/meta_2026-09-05.db防的是拷成功但已损坏盘坏、空间不足。check 通过的备份才敢信。拉起服务收工。systemctl start containerd防的是忘了拉起导致节点长时间无服务。停服务前可以先ctr tasks ls看看有没有在跑的关键容器有就挑低峰期。⏰ 让备份自己跑systemd 定时器方案手动方案熟悉后把例行活交给机器。脚本骨架只需要五个动作#!/bin/bash set -e systemctl stop containerd cp /var/lib/containerd/io.containerd.metadata.v1.bolt/meta.db \ /backup/containerd/meta_$(date %Y%m%d).db systemctl start containerd find /backup/containerd -name meta_*.db -mtime 30 -delete # 保留 30 天最后一行是保留策略超过 30 天的备份自动清掉。整套脚本防的是靠人记“该备份了”以及备份目录无限膨胀。再套一个定时器让它每天跑[Timer] OnCalendardaily Persistenttrue以上写入 /etc/systemd/system/containerd-backup.timer对应 service 设Typeoneshot、ExecStart指向脚本然后systemctl enable --now containerd-backup.timer防的是机器重启后定时器没人拉起Persistenttrue还会补跑停机期间漏掉的备份。真出事时四步把 meta.db 救回来按这个顺序来不用多想systemctl stop containerd cp /backup/containerd/meta_20260905.db \ /var/lib/containerd/io.containerd.metadata.v1.bolt/meta.db chown root:root /var/lib/containerd/io.containerd.metadata.v1.bolt/meta.db systemctl start containerd停、放回去、修属主、拉起。属主那行最容易被漏换回的副本如果属主不对containerd 打不开库。起来之后确认地址簿真的回来了ctr images list ctr containers list防的是进程活着但库里是空的“假恢复”。bbolt 校验失败怎么办分两种情况备份时check 报错这份不要入库立刻重拷连续失败就不是文件问题去查dmesg和磁盘 SMART 状态。恢复后containerd 起不来、日志报数据库打开或事务错误确认服务已停再跑一次修复然后重启。bbolt fix /var/lib/containerd/io.containerd.metadata.v1.bolt/meta.dbfix 是会改写文件的修复工具只在“确定坏了”时运行平时别拿来当例行保养。进阶与坑checkpoint 和三个最容易踩的坑只保地址簿是 meta.db 的事要连一个运行中容器的完整状态一起保用 checkpoint——它依赖 CRIU 导出内存和运行期状态实现在 client/container_checkpoint_opts.goctr container checkpoint --rw --task web-demo web-demo-ck ctr container restore --live web-demo-2 web-demo-ck第一条冻结并导出容器含可写层第二条从导出里恢复出一个新容器--live恢复运行时内存。checkpoint 是“单个容器的状态恢复”和整机元数据备份不是一回事别混用。最容易被坑的三处各两行说清坑直接 cp 运行中的 meta.db恢复时打不开。解法先停后拷实在不能停用 LVM/ZFS 快照打一致性时间点。坑只备了 meta.db恢复后镜像、快照报“数据找不到”。解法地址簿不等于数据/var/lib/containerd 整体至少 content 与 snapshotter 目录要一起备。坑备份目录把盘写满恢复时才发现一代备份都没有。解法保留策略设上限并加容量告警每月在测试机上做一次恢复演练。恢复后元数据、镜像层、快照三层要重新互相找得到数据走向可以参考这张图行动清单本周内跑一遍手动备份用bbolt check确认那份 meta.db 合格。部署 systemd 定时器并排一次“停服务 → 放回 → 拉起”的恢复演练。确认机器上是否有 CRIU判断业务是否需要 checkpoint 级别恢复需要就写进值班手册。更多运行目录与配置细节见 docs/ 与 docs/ops.md。【免费下载链接】containerdAn open and reliable container runtime项目地址: https://gitcode.com/GitHub_Trending/co/containerd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
