Harbor备份需区分静态与动态数据：静态数据（harbor.yml、证书等）一次备份并版本化；动态数据（/data目录下数据库、Redis、镜像存储等）按RPO/RTO执行每日逻辑备份+快照、每周全量物理备份，并在升级前手动紧急备份，恢复须严格按序验证。Harbor 作为企业级私有镜像仓库，其数据可靠性直接关系到整个容器交付链路的稳定性。备份与恢复不是“可选项”，而是上线前必须落地的运维基线。配置合理策略的关键，在于区分静态数据和动态数据，并匹配实际业务节奏。
明确需要备份的两类数据
harbor 数据不能一锅端地 tar -czf，必须分类处理：
-
静态数据（一次备份即可）：Harbor 安装目录下的
harbor.yml（含 hostname、存储驱动、HTTPS 证书路径等核心配置）、ssl/目录中的证书文件（如server.crt和server.key）、自定义脚本或钩子程序。这些文件不随运行变化，备份一次并纳入版本控制即可。 -
动态数据（需周期性备份）：由
data_volume配置项指定的目录（默认是/data），里面包含：- PostgreSQL 数据库（
/data/database）—— 存储项目、用户、权限、复制规则等元数据 - Redis 数据（
/data/redis）—— 缓存镜像标签、作业状态等临时信息 - 镜像存储（
/data/registry）—— 实际的 layer blobs 和 manifest 文件（若用 filesystem 驱动） - Chart 仓库（
/data/chart_storage）—— 若启用 Helm Chart 功能
- PostgreSQL 数据库（
制定可落地的备份策略
策略要兼顾 RPO（恢复点目标）和 RTO（恢复时间目标），避免过度备份或遗漏关键时间点：
- 每日凌晨 2 点执行一次 数据库逻辑备份（
pg_dump），保留最近 7 天；同时对/data/registry执行 硬链接快照（如用rsync --link-dest或cp -al），节省空间且支持秒级回滚 - 每周日执行一次 全量物理备份：打包
/data目录（排除/data/registry/tmp等临时子目录），压缩加密后上传至异地对象存储（如 MinIO 或 S3 兼容服务） - 每次 Harbor 升级或重大配置变更前，手动触发一次 紧急备份，并记录操作上下文（如 “v2.10.2 升级前，harbor.yml 修改了 storage_driver”）
验证有效的恢复流程
备份无效等于没备。恢复必须可验证、可演练：
- 恢复时严格按顺序操作：先停所有 Harbor 容器（
docker-compose down），再还原 PostgreSQL 数据（psql -U postgres harbor ），接着覆盖 <code>/data/registry内容，最后恢复证书与配置文件 - 权限必须一致：备份时用
tar --same-permissions，恢复后执行chown -R 10000:10000 /data（Harbor 默认以 UID 10000 运行），否则启动失败 - 每次备份后，在测试环境自动拉起一套临时 Harbor，尝试拉取一个已知镜像并检查 UI 登录，生成简短报告（成功/失败 + 耗时）
用脚本固化关键动作
避免手工失误，把高频操作写成带参数的脚本：
- 备份脚本示例（
harbor-backup.sh）支持--type=full|daily和--target=s3://bucket/path参数，自动判断是否启用压缩与 GPG 加密 - 恢复脚本（
harbor-restore.sh）接受备份时间戳，自动解压、校验 SHA256、设置权限、重启服务，并输出健康检查结果（如curl -sf http://localhost/api/v2.0/ping） - 所有脚本加入
set -e和日志重定向，失败立即中止并发送企业微信告警
