Containerd 元数据备份完整实操指南从备份到 meta.db 损坏时的恢复【免费下载链接】containerdAn open and reliable container runtime项目地址: https://gitcode.com/GitHub_Trending/co/containerdContainerd 是开源容器运行时负责管理一台机器上镜像、容器和快照的完整生命周期。元数据一旦丢失机器上所有业务都无从找回。这篇关于 Containerd 元数据备份的笔记带你从第一次备份走到真出事时的恢复。一个真实的翻车场景凌晨两点监控告警节点上所有容器起不来。排查后发现/var/lib/containerd/io.containerd.metadata.v1.bolt/meta.db写坏了一半节点上记录的容器、镜像信息全部丢失。另一种常见情况是换机器镜像层目录原样拷过去但没带元数据containerd 不认这些层等于要重新拉一遍镜像。说白了元数据是运行时认领自己数据的唯一索引它一丢全得重来。元数据到底存在哪、长什么样存储引擎是 BoltDB所有元数据都通过BoltDB 初始化逻辑里的事务写入一个事务要么整体落盘要么不动天然避免写一半的脏状态。文件位置固定默认在/var/lib/containerd/io.containerd.metadata.v1.bolt/meta.db目录结构可对照官方运维文档。命名空间隔离同一个 meta.db 内部按命名空间分账k8s 写的和业务侧写的互不干扰。资源引用关系镜像、容器、快照之间的依赖链记在库里垃圾回收靠它判断哪些资源可以清理。换句话说meta.db 像一本总账容器和镜像是条目快照是余额。账本丢了货架上的钱没人认得。容器运行时数据备份要护住的正是这本账以及账指向的落盘数据。从零到自动把备份做成肌肉记忆第一次手动 Containerd 备份先手动走一遍搞清楚每步在干什么停服、拷贝、验证、起服。sudo systemctl stop containerd sudo cp /var/lib/containerd/io.containerd.metadata.v1.bolt/meta.db /backup/meta_$(date %Y%m%d).db go install go.etcd.io/bbolt/cmd/bboltlatest bbolt check /backup/meta_$(date %Y%m%d).db sudo systemctl start containerd记住这一步拷完必须跑bbolt check验证。打不开的备份文件和没备份一样。上面四行就是 Containerd 备份脚本的核心脚本里再让它按时间戳命名、清掉超过 30 天的旧文件即可。把 Containerd 备份脚本交给定时器之后交给定时器写一个 systemd timerOnCalendardaily每天触发配一个 oneshot service 调你的备份脚本systemctl enable --now激活。脚本内容就是上面四行加 30 天清理加上Persistenttrue漏掉的补跑会自动执行。真出事了恢复流程 Checkpoint 兜底Containerd meta.db 恢复三步走停服systemctl stop containerd确保没人再写库。回拷并修库把验证过的备份拷回原路径如果原件只是局部损坏先用bbolt fix做一次元数据损坏修复。起服systemctl start containerd用ctr核对容器和镜像数量。Checkpoint更彻底的保命手段如果你要保的不只是账本用 Checkpoint它把容器的内存、文件句柄连同进程状态一起冻成镜像底层依赖 CRIU实现见CRIU Checkpoint 逻辑。一条命令ctr task checkpoint my-container之后可以把整个容器原样迁到有相同镜像的机器上再恢复这比恢复 meta.db 更彻底。过来人提醒5 条最容易忽视的事停服再备份BoltDB 写入时加锁运行中直接拷贝容易得到半坏文件大节点选低峰窗口执行。拷完必验证bbolt check通过才归档这一步省了等于白备。恢复演练比备份本身重要每月挑一天在测试机上把上面三步真实跑一遍备份是否可用只有演练能回答。元数据不含镜像层meta.db 只记账目镜像层和快照在同级目录完整备份要覆盖整个/var/lib/containerd。异地留存多版本备份放不同物理位置按文件名时间戳保留 30 天版本方便回溯。开头那个凌晨两点的告警到这里就终结了提前备好的 meta.db 和演练过的恢复流程比任何救火都可靠。目录结构和部署细节可看官方运维文档 docs/ops.md。【免费下载链接】containerdAn open and reliable container runtime项目地址: https://gitcode.com/GitHub_Trending/co/containerd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Containerd 元数据备份完整实操指南：从备份到 meta.db 损坏时的恢复
Containerd 元数据备份完整实操指南从备份到 meta.db 损坏时的恢复【免费下载链接】containerdAn open and reliable container runtime项目地址: https://gitcode.com/GitHub_Trending/co/containerdContainerd 是开源容器运行时负责管理一台机器上镜像、容器和快照的完整生命周期。元数据一旦丢失机器上所有业务都无从找回。这篇关于 Containerd 元数据备份的笔记带你从第一次备份走到真出事时的恢复。一个真实的翻车场景凌晨两点监控告警节点上所有容器起不来。排查后发现/var/lib/containerd/io.containerd.metadata.v1.bolt/meta.db写坏了一半节点上记录的容器、镜像信息全部丢失。另一种常见情况是换机器镜像层目录原样拷过去但没带元数据containerd 不认这些层等于要重新拉一遍镜像。说白了元数据是运行时认领自己数据的唯一索引它一丢全得重来。元数据到底存在哪、长什么样存储引擎是 BoltDB所有元数据都通过BoltDB 初始化逻辑里的事务写入一个事务要么整体落盘要么不动天然避免写一半的脏状态。文件位置固定默认在/var/lib/containerd/io.containerd.metadata.v1.bolt/meta.db目录结构可对照官方运维文档。命名空间隔离同一个 meta.db 内部按命名空间分账k8s 写的和业务侧写的互不干扰。资源引用关系镜像、容器、快照之间的依赖链记在库里垃圾回收靠它判断哪些资源可以清理。换句话说meta.db 像一本总账容器和镜像是条目快照是余额。账本丢了货架上的钱没人认得。容器运行时数据备份要护住的正是这本账以及账指向的落盘数据。从零到自动把备份做成肌肉记忆第一次手动 Containerd 备份先手动走一遍搞清楚每步在干什么停服、拷贝、验证、起服。sudo systemctl stop containerd sudo cp /var/lib/containerd/io.containerd.metadata.v1.bolt/meta.db /backup/meta_$(date %Y%m%d).db go install go.etcd.io/bbolt/cmd/bboltlatest bbolt check /backup/meta_$(date %Y%m%d).db sudo systemctl start containerd记住这一步拷完必须跑bbolt check验证。打不开的备份文件和没备份一样。上面四行就是 Containerd 备份脚本的核心脚本里再让它按时间戳命名、清掉超过 30 天的旧文件即可。把 Containerd 备份脚本交给定时器之后交给定时器写一个 systemd timerOnCalendardaily每天触发配一个 oneshot service 调你的备份脚本systemctl enable --now激活。脚本内容就是上面四行加 30 天清理加上Persistenttrue漏掉的补跑会自动执行。真出事了恢复流程 Checkpoint 兜底Containerd meta.db 恢复三步走停服systemctl stop containerd确保没人再写库。回拷并修库把验证过的备份拷回原路径如果原件只是局部损坏先用bbolt fix做一次元数据损坏修复。起服systemctl start containerd用ctr核对容器和镜像数量。Checkpoint更彻底的保命手段如果你要保的不只是账本用 Checkpoint它把容器的内存、文件句柄连同进程状态一起冻成镜像底层依赖 CRIU实现见CRIU Checkpoint 逻辑。一条命令ctr task checkpoint my-container之后可以把整个容器原样迁到有相同镜像的机器上再恢复这比恢复 meta.db 更彻底。过来人提醒5 条最容易忽视的事停服再备份BoltDB 写入时加锁运行中直接拷贝容易得到半坏文件大节点选低峰窗口执行。拷完必验证bbolt check通过才归档这一步省了等于白备。恢复演练比备份本身重要每月挑一天在测试机上把上面三步真实跑一遍备份是否可用只有演练能回答。元数据不含镜像层meta.db 只记账目镜像层和快照在同级目录完整备份要覆盖整个/var/lib/containerd。异地留存多版本备份放不同物理位置按文件名时间戳保留 30 天版本方便回溯。开头那个凌晨两点的告警到这里就终结了提前备好的 meta.db 和演练过的恢复流程比任何救火都可靠。目录结构和部署细节可看官方运维文档 docs/ops.md。【免费下载链接】containerdAn open and reliable container runtime项目地址: https://gitcode.com/GitHub_Trending/co/containerd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考