Containerd 元数据备份从手动到定时5 步搭好安全网【免费下载链接】containerdAn open and reliable container runtime项目地址: https://gitcode.com/GitHub_Trending/co/containerd凌晨三点监控群炸了containerd 起不来日志里反复刷着 meta.db 打不开的报错节点上的容器一个接一个被 k8s 驱逐。我翻出备份目录空的。从那天起Containerd 元数据备份成了我值班清单上的第一项。30 秒搞懂meta.db 里到底存了什么说白了一个节点上有哪些容器、哪些镜像、哪些快照全靠这一个文件记账内容容器记录、镜像记录、快照索引、lease、命名空间配置全部是 BoltDB 里的桶。源码就放在 core/metadata/桶的定义在buckets.go文件头里还写着schemaVersion v1、dbVersion 4。位置默认/var/lib/containerd/meta.db。配置里root指向哪个目录它就落在哪个目录下。丢了会怎样容器和镜像记录全没。ctr查啥都是空k8s 节点上的 Pod 全部失踪只能重拉镜像重建。丢了文件里的数据/var/lib/containerd/下的快照目录还在但没人知道它们属于谁变成一堆孤儿目录。元数据Metadata和存储Storage并列存在这就是为什么单独备份 meta.db 不能解决所有问题——下面会说。第一次手动备份5 分钟搞定就四件事停服 → 拷贝 → 校验 → 重启。先停服务BoltDB 是单写者不停服直接拷等于抄一个正在被改的账本。systemctl stop containerd cp /var/lib/containerd/meta.db /backup/meta.db.$(date %Y%m%d_%H%M%S)拷完先别急着起服务用 bbolt 工具校验备份文件是完整可打开的数据库不是 0 字节、不是截断文件bbolt check /backup/meta.db.*看到 no problems detected 就可以放心重启了systemctl start containerd全程约 2 分钟大头在重启。备份文件大小应该和原文件一致。让备份自己跑systemd 定时器手工活只练手。生产环境交给 systemd配置清单如下共 4 件备份脚本/usr/local/bin/containerd-backup.sh#!/bin/bash set -euo pipefail systemctl stop containerd cp /var/lib/containerd/meta.db /backup/meta.db.$(date %Y%m%d_%H%M%S) bbolt check /backup/meta.db.$(ls -t /backup | head -1) systemctl start containerd⚠️ 注意最后一行无论备份成败服务都会起来不会把你锁在门外。想连快照目录一起备加一行tar即可建议另存一份。服务单元/etc/systemd/system/containerd-backup.service[Unit] DescriptionContainerd metadata backup [Service] Typeoneshot ExecStart/usr/local/bin/containerd-backup.sh定时器/etc/systemd/system/containerd-backup.timer[Unit] DescriptionRun containerd metadata backup daily [Timer] OnCalendar*-*-* 03:30:00 Persistenttrue [Install] WantedBytimers.target关键就一行把OnCalendar*-*-* 03:30:00改成OnCalendarMon *-*-* 03:30:00备份就从每天变成每周一其他都不用动。启用并验证systemctl enable --now containerd-backup.timer systemctl list-timers containerd-backup.timermeta.db 坏了怎么救先看症状对症下药不用慌症状直接操作文件不存在或大小 0 字节停服 → 拷回最近一次校验过的备份 → 起服务bbolt check报 page 结构错误停服 →bbolt fix原地修复 → 再 check → 起服务bbolt fix修不了放弃修复直接回拷备份备份在就别恋战起服务报 schema 不匹配备份和二进制版本对不上换匹配的备份或版本标准恢复就 4 步别急着加戏systemctl stop containerd cp /backup/meta.db.20260801_033000 /var/lib/containerd/meta.db bbolt check /var/lib/containerd/meta.db systemctl start containerd起来之后跑一下ctr container ls能列出容器就算救回来了。踩过的坑 反直觉的点别拷正在写的 meta.db。服务不停就cpBoltDB 页内更新你大概率拷出一个撕裂文件。上面流程里bbolt check那一步不是形式主义是真的能拦下脏备份。停服窗口 节点不可用。备份期间该节点不能调度新容器。窗口放凌晨或者干脆依赖文件系统快照。只备 meta.db 是半套。它只是账本账上的货在/var/lib/containerd/下的快照目录里镜像层、容器 rootfs。只拷账本恢复出来是个空仓库。✅ 完整备份 元数据 快照目录。版本别乱跨。meta.db 里带着版本信息新版本的备份拷回老版本 containerd起不来很正常。跨节点直接互拷备份也别试命名空间和内容哈希对不上。meta.db 突然变小了通常意味着掉电或 I/O 错误。先回拷备份把服务拉起来磁盘问题事后慢慢查别在生产上现场刨根问底。 一套方案就四句停服、拷文件、校验、重启。然后让定时器替你守着。想知道账本内部到底怎么组织直接翻core/metadata/的源码比任何文章都快。【免费下载链接】containerdAn open and reliable container runtime项目地址: https://gitcode.com/GitHub_Trending/co/containerd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Containerd 元数据备份：从手动到定时，5 步搭好安全网
Containerd 元数据备份从手动到定时5 步搭好安全网【免费下载链接】containerdAn open and reliable container runtime项目地址: https://gitcode.com/GitHub_Trending/co/containerd凌晨三点监控群炸了containerd 起不来日志里反复刷着 meta.db 打不开的报错节点上的容器一个接一个被 k8s 驱逐。我翻出备份目录空的。从那天起Containerd 元数据备份成了我值班清单上的第一项。30 秒搞懂meta.db 里到底存了什么说白了一个节点上有哪些容器、哪些镜像、哪些快照全靠这一个文件记账内容容器记录、镜像记录、快照索引、lease、命名空间配置全部是 BoltDB 里的桶。源码就放在 core/metadata/桶的定义在buckets.go文件头里还写着schemaVersion v1、dbVersion 4。位置默认/var/lib/containerd/meta.db。配置里root指向哪个目录它就落在哪个目录下。丢了会怎样容器和镜像记录全没。ctr查啥都是空k8s 节点上的 Pod 全部失踪只能重拉镜像重建。丢了文件里的数据/var/lib/containerd/下的快照目录还在但没人知道它们属于谁变成一堆孤儿目录。元数据Metadata和存储Storage并列存在这就是为什么单独备份 meta.db 不能解决所有问题——下面会说。第一次手动备份5 分钟搞定就四件事停服 → 拷贝 → 校验 → 重启。先停服务BoltDB 是单写者不停服直接拷等于抄一个正在被改的账本。systemctl stop containerd cp /var/lib/containerd/meta.db /backup/meta.db.$(date %Y%m%d_%H%M%S)拷完先别急着起服务用 bbolt 工具校验备份文件是完整可打开的数据库不是 0 字节、不是截断文件bbolt check /backup/meta.db.*看到 no problems detected 就可以放心重启了systemctl start containerd全程约 2 分钟大头在重启。备份文件大小应该和原文件一致。让备份自己跑systemd 定时器手工活只练手。生产环境交给 systemd配置清单如下共 4 件备份脚本/usr/local/bin/containerd-backup.sh#!/bin/bash set -euo pipefail systemctl stop containerd cp /var/lib/containerd/meta.db /backup/meta.db.$(date %Y%m%d_%H%M%S) bbolt check /backup/meta.db.$(ls -t /backup | head -1) systemctl start containerd⚠️ 注意最后一行无论备份成败服务都会起来不会把你锁在门外。想连快照目录一起备加一行tar即可建议另存一份。服务单元/etc/systemd/system/containerd-backup.service[Unit] DescriptionContainerd metadata backup [Service] Typeoneshot ExecStart/usr/local/bin/containerd-backup.sh定时器/etc/systemd/system/containerd-backup.timer[Unit] DescriptionRun containerd metadata backup daily [Timer] OnCalendar*-*-* 03:30:00 Persistenttrue [Install] WantedBytimers.target关键就一行把OnCalendar*-*-* 03:30:00改成OnCalendarMon *-*-* 03:30:00备份就从每天变成每周一其他都不用动。启用并验证systemctl enable --now containerd-backup.timer systemctl list-timers containerd-backup.timermeta.db 坏了怎么救先看症状对症下药不用慌症状直接操作文件不存在或大小 0 字节停服 → 拷回最近一次校验过的备份 → 起服务bbolt check报 page 结构错误停服 →bbolt fix原地修复 → 再 check → 起服务bbolt fix修不了放弃修复直接回拷备份备份在就别恋战起服务报 schema 不匹配备份和二进制版本对不上换匹配的备份或版本标准恢复就 4 步别急着加戏systemctl stop containerd cp /backup/meta.db.20260801_033000 /var/lib/containerd/meta.db bbolt check /var/lib/containerd/meta.db systemctl start containerd起来之后跑一下ctr container ls能列出容器就算救回来了。踩过的坑 反直觉的点别拷正在写的 meta.db。服务不停就cpBoltDB 页内更新你大概率拷出一个撕裂文件。上面流程里bbolt check那一步不是形式主义是真的能拦下脏备份。停服窗口 节点不可用。备份期间该节点不能调度新容器。窗口放凌晨或者干脆依赖文件系统快照。只备 meta.db 是半套。它只是账本账上的货在/var/lib/containerd/下的快照目录里镜像层、容器 rootfs。只拷账本恢复出来是个空仓库。✅ 完整备份 元数据 快照目录。版本别乱跨。meta.db 里带着版本信息新版本的备份拷回老版本 containerd起不来很正常。跨节点直接互拷备份也别试命名空间和内容哈希对不上。meta.db 突然变小了通常意味着掉电或 I/O 错误。先回拷备份把服务拉起来磁盘问题事后慢慢查别在生产上现场刨根问底。 一套方案就四句停服、拷文件、校验、重启。然后让定时器替你守着。想知道账本内部到底怎么组织直接翻core/metadata/的源码比任何文章都快。【免费下载链接】containerdAn open and reliable container runtime项目地址: https://gitcode.com/GitHub_Trending/co/containerd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考