一、生产环境Harbor备份与恢复的核心需求
生产环境里的Harbor，就像DevOps团队的“专属镜像储物柜”，里面存着项目需要的所有镜像，一旦出问题，小到开发误删镜像导致流水线卡壳，大到Harbor服务器故障，整个部署流程都会陷入瘫痪。
1.1 常见应用场景
我上个月就碰到过真实案例：团队测试同学误删了核心支付服务的镜像，当时没做备份，只能从源码重新构建，花了40分钟耽误了上线计划；还有公司要把Harbor从旧服务器迁到新云服务器，要是没备份，上千个镜像得全量推送，不仅耗时还占带宽；另外，金融类项目要求镜像数据留存半年，备份是满足合规要求的基础，这些都是生产里躲不开的实际场景。
1.2 备份恢复的技术优缺点
优点是操作标准化，Harbor自带的官方备份工具不用写复杂逻辑，降低出错概率；恢复速度快，几百G镜像十几分钟就能搞定；能快速回滚故障，减少业务中断时间。缺点是备份要占和镜像相当的存储空间，100G镜像至少要100G备份，得定期清理旧文件；备份恢复会占用Harbor资源，最好选在业务低峰期做，不然可能影响正常部署；还要定期验证备份能不能用，不然真出事才发现备份是坏的，白忙活一场。
二、Harbor镜像仓库的实战备份方案
2.1 备份的前置准备
目前生产环境最常用的是docker-compose部署的Harbor 2.x版本，所以示例都基于这个场景。备份前要确认：Harbor服务正常运行，有足够存储空间（至少是镜像总大小的1.2倍，留冗余），备份目录要有读写权限，别等脚本跑一半报“没权限”就麻烦了。
2.2 实战备份脚本示例
#!/bin/bash
# Harbor备份脚本，适用于docker-compose部署的Harbor 2.x版本
# 可根据实际部署路径修改下面两个变量
HARBOR_DIR="/opt/harbor"
BACKUP_STORE="/data/harbor_backups"
# 步骤1：停止Harbor服务，确保备份数据一致性，避免备份时数据被修改
cd $HARBOR_DIR
docker-compose down
# 步骤2：创建带时间戳的临时备份目录，避免文件重名，同时创建存储目录
BACKUP_TEMP="$BACKUP_STORE/temp_backup_$(date +%Y%m%d_%H%M)"
mkdir -p $BACKUP_TEMP $BACKUP_STORE
# 步骤3：复制核心配置文件harbor.yml，恢复时必须用，不然配置会丢失
cp $HARBOR_DIR/harbor.yml $BACKUP_TEMP/
# 步骤4：用Harbor自带工具生成全量备份，指定备份目录
$HARBOR_DIR/harbor backup create --destination $BACKUP_TEMP
# 步骤5：将临时备份打包成tar.gz，方便存储和传输，压缩后体积更小
cd $BACKUP_STORE
tar -zcvf harbor_backup_$(date +%Y%m%d_%H%M).tar.gz $(basename $BACKUP_TEMP)
# 步骤6：删除临时目录，节省磁盘空间
rm -rf $BACKUP_TEMP
# 步骤7：重启Harbor服务，恢复业务
cd $HARBOR_DIR
docker-compose up -d
# 步骤8：清理7天前的备份，避免占满磁盘，可根据存储情况调整天数
find $BACKUP_STORE -name "harbor_backup_*.tar.gz" -mtime +7 -delete
echo "Harbor备份完成，备份文件路径：$BACKUP_STORE/harbor_backup_$(date +%Y%m%d_%H%M).tar.gz"
脚本细节解释：停止Harbor是怕备份时有人提交镜像，导致数据库和镜像文件不一致，就像给手机备份时别乱删文件，不然备份会有缺失；复制harbor.yml是因为里面存了Harbor的域名、证书、数据库密码等核心配置，恢复时必须用；清理旧备份是为了避免磁盘占满，就像不会把一年前的手机备份都存在电脑里。
2.3 备份的验证方法
备份完不能直接不管，要确认备份有效：一是看备份文件是否生成，用ls -lh $BACKUP_STORE检查，大小和Harbor镜像总大小差不多就正常；二是解压看看内容，用tar -ztvf 备份文件名.tar.gz，能看到数据库、配置文件等核心内容；三是把备份复制到另一台服务器测试，避免原服务器挂了备份也丢了，就像把手机备份复制到外接硬盘存一份。
三、Harbor镜像仓库的实战恢复方案
3.1 恢复的前置准备
首先要部署和备份时版本完全一致的Harbor，比如备份用的是2.5.1，新环境也得装2.5.1，部署方式要一样；然后停止新Harbor服务，清空新环境里的数据库和镜像存储，避免恢复时冲突；还要把备份文件放到和备份脚本一致的存储目录，确保能找到。
3.2 实战恢复脚本示例
#!/bin/bash
# Harbor恢复脚本，适用于docker-compose部署的Harbor 2.x版本，版本需与备份时一致
# 替换成你实际的备份文件路径，比如要恢复20240520的备份就改这里
BACKUP_FILE="/data/harbor_backups/harbor_backup_20240520_1430.tar.gz"
HARBOR_DIR="/opt/harbor"
# 步骤1：停止新部署的Harbor服务，防止恢复时数据冲突
cd $HARBOR_DIR
docker-compose down
# 步骤2：检查备份文件是否存在，不存在就报错退出，避免后续错误
if [ ! -f $BACKUP_FILE ]; then
echo "错误：备份文件不存在，请检查路径！"
exit 1
fi
# 步骤3：创建临时解压目录
TEMP_DIR="/tmp/harbor_restore_temp"
mkdir -p $TEMP_DIR
# 步骤4：解压备份文件到临时目录
tar -zxvf $BACKUP_FILE -C $TEMP_DIR
# 步骤5：用Harbor自带工具执行恢复，指定解压后的备份目录
$HARBOR_DIR/harbor restore --source $TEMP_DIR/temp_backup_20240520_1430
# 步骤6：删除临时目录，节省空间
rm -rf $TEMP_DIR
# 步骤7：如果新服务器域名/证书和旧的不同，修改harbor.yml配置，比如：
# sed -i 's/旧域名/新域名/g' $HARBOR_DIR/harbor.yml
# 步骤8：重新加载Harbor配置并启动服务
$HARBOR_DIR/prepare
docker-compose up -d
echo "Harbor恢复完成，服务启动后请登录验证项目和镜像是否正常！"
脚本细节解释：版本一致是因为不同版本的Harbor备份格式不兼容，就像安卓13的备份不能恢复到安卓10的手机里；修改harbor.yml是因为新环境的域名可能和旧的不一样，恢复后的证书是旧域名的，访问不了就没用；prepare命令是生成Harbor的核心配置，恢复后必须执行，不然服务启动不了。
3.3 恢复后的验证方法
恢复完必须验证，不然白忙活：一是登录Harbor网页，看原来的项目、镜像标签是不是都在；二是拉取一个恢复后的镜像，比如docker pull 你的Harbor地址/项目/镜像:标签，能正常拉取就是正常的；三是提交一个新镜像，确认Harbor能正常读写，就像恢复手机数据后，打开相册、微信确认都能用。
四、备份恢复的关键注意事项
4.1 备份频率的选择
生产环境至少每天备份一次，选在凌晨业务低峰期做，这个时候没人部署服务，不会影响业务；如果项目有频繁的镜像提交，可设置增量备份，但官方工具是全量备份，新手建议用全量，不容易出错，就像每周做一次全备份，平时不用太勤，省时间。
4.2 备份文件的存储位置
绝对不能把备份存在Harbor所在的服务器，要是服务器坏了，备份也会丢，就像把重要文件存在被水淹没的房子里；要存到NAS网络存储、阿里云OSS这类异地存储，安全有保障，别嫌麻烦，上次有个团队就是因为备份和Harbor在同一服务器，服务器挂了之后镜像全没了，折腾了一周才恢复。
4.3 定期验证备份的可用性
至少每两周试一次恢复，不用恢复到正式环境，自己搭个测试环境就行，就像给手机备份后没事恢复试试，不然真丢数据才发现备份是坏的，哭都来不及；验证恢复的过程也是熟悉流程的过程，下次真出事就能快速上手。
4.4 权限和网络的注意事项
备份目录的权限要设为755，别设成700，不然脚本会报错；要是备份文件要传到云存储，要确保网络通畅，别传一半断了，备份文件损坏，就像传照片到云盘，网断了传一半，照片是坏的看不了。
五、方案总结
总的来说，生产环境的Harbor备份恢复，就是给镜像仓库买一份“免费保险”，不用花钱，只要按步骤做，就能在出问题的时候快速解决；核心就是定期备份、存好备份、定期验证，别嫌麻烦，之前的同事就是因为没备份，耽误了项目上线；这套方案适配大多数docker-compose部署的Harbor，新手也能跟着脚本操作，不用复杂的专业知识，能保障DevOps流程稳定，减少业务中断风险。
评论
围绕“生产环境中Harbor镜像仓库的备份与恢复方案”参与讨论