私有镜像仓库灾难恢复核心是快速还原可用镜像数据并验证可拉取：需确认备份含完整存储路径（如/var/lib/registry或Harbor的data/database卷），解压后重启服务，并实测docker pull与UI访问，同时通过定期演练和离线镜像包提升可靠性。
私有镜像仓库的灾难恢复，核心是“快速还原可用镜像数据+验证服务可拉取”，不依赖外部网络或原服务状态。关键在于备份是否真实有效、路径是否准确、恢复步骤是否可执行。
确认备份内容是否完整可用
私有仓库（如 Docker Registry 或 Harbor）的数据本质是存储卷中的文件结构。恢复前必须验证备份本身：
- 检查备份是否包含完整的 /var/lib/registry 目录（Registry 默认路径）或 Harbor 对应的 data 和 database 卷内容
- 用 tar -tf backup.tar.gz | head -20 查看归档内是否有
blobs/、repositories/、manifests/等关键子目录 - 比对备份时间戳与最后一次成功推送镜像的时间，避免使用过期备份
停机后快速恢复仓库服务
恢复不是简单解压，而是替换存储并重启服务：
- 停止原 registry 容器：docker stop registry
- 清空旧数据目录（谨慎操作！先确认路径）：rm -rf /data/registry/*
- 解压备份到原路径：tar -xzf /backup/registry_20260810.tar.gz -C /data/registry/
- 重启容器（确保挂载路径一致）：docker start registry
- 若用 Harbor，还需单独恢复 PostgreSQL 数据库快照，并同步 Redis 缓存（如有）
验证镜像是否真正可拉取
仅容器启动成功不等于恢复完成，必须实测镜像访问链路：
- 在客户端执行：docker pull your-registry-ip:5000/myapp:v1.2
- 检查返回是否含
Status: Downloaded newer image，而非unauthorized或not found - 登录仓库 UI（如 Harbor）查看镜像列表、标签、层大小是否与备份前一致
- 运行一个临时容器测试：docker run --rm your-registry-ip:5000/myapp:v1.2 /bin/sh -c "echo OK"
预防下次灾难：让恢复变成常规动作
真正的高可用不靠“救火”，而靠可重复验证的机制：
- 把恢复流程写成脚本，每月执行一次演练（哪怕只跑通到
docker pull成功） - 备份时附带简短元数据文件，记录镜像总数、最大镜像名、最后推送时间
- 对关键业务镜像，额外用 docker save -o app-latest.tar app:latest 做离线镜像包，存在异地NAS或对象存储中
- Harbor 用户启用自动镜像扫描和内容信任（Notary），避免恢复后拉到被篡改的镜像
