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/bboltlatest。然后# 第一步停服务避免 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] DescriptionContainerd metadata backup [Service] Typeoneshot ExecStart/usr/local/bin/containerd-backup.shtimer 单元每天跑一次错过会补跑[Unit] DescriptionDaily backup timer for Containerd metadata [Timer] OnCalendardaily Persistenttrue [Install] WantedBytimers.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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
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/bboltlatest。然后# 第一步停服务避免 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] DescriptionContainerd metadata backup [Service] Typeoneshot ExecStart/usr/local/bin/containerd-backup.shtimer 单元每天跑一次错过会补跑[Unit] DescriptionDaily backup timer for Containerd metadata [Timer] OnCalendardaily Persistenttrue [Install] WantedBytimers.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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
