t2.medium实例Jenkins备份至S3的可行性及性能问题咨询

当前场景 #

在AWS EC2 t2.medium实例上运行Jenkins，包含20条流水线，每条平均1500次构建历史，通过Github Webhook自动触发。计划备份整个Jenkins home目录到S3桶，但现有Shell脚本会先在本地生成压缩包再上传，担心磁盘容量不足导致实例宕机，需要确认实例可用性并获取优化建议。

现有脚本的问题 #

1. 磁盘占用风险：脚本先在本地生成完整压缩包，若Jenkins home体积较大（比如包含大量构建日志、工件），容易占满实例磁盘，引发系统异常。
2. 命令参数错误：tar -cvf jenkins_backup.tar.gz未启用压缩（缺少-z参数），实际生成的是未压缩的tar包，却命名为tar.gz，后续上传会出现格式混淆。
3. 错误处理缺失：set +e会忽略tar命令的错误，即使备份失败也无法及时察觉。
4. 备份一致性问题：未处理Jenkins正在运行的构建，可能导致备份文件包含不完整的日志或配置。

关键优化建议 #

1. 流式上传跳过本地压缩包（核心解决磁盘问题） #

直接通过管道将tar压缩后的内容上传到S3，完全避免在本地生成大文件，彻底消除磁盘容量风险。修改后的命令如下：

# 带时间戳命名备份文件，避免覆盖旧备份
tar -zcv -C $JENKINS_HOME . | aws s3 cp - s3://jenkins-backup-test-bucket/jenkins_backup_$(date +%Y%m%d_%H%M%S).tar.gz

解释：-表示让aws cli从标准输入读取数据，tar的压缩输出直接通过管道传给aws，无需落地磁盘。

2. 修复现有脚本的基础问题 #

如果坚持要在本地生成压缩包，需做以下调整：

# 启用压缩（-z参数），修正tar命令
tar -zcvf jenkins_backup.tar.gz -C $JENKINS_HOME .
# 去掉set +e，添加错误检查
if [ $? -ne 0 ]; then
    echo "备份压缩失败，终止操作"
    exit 1
fi

3. 备份前检查磁盘容量 #

在脚本开头添加磁盘空间检查，避免在空间不足时执行备份：

# 获取Jenkins home所在分区的剩余空间（单位KB）
FREE_SPACE=$(df -P $JENKINS_HOME | tail -1 | awk '{print $4}')
# 设定最小剩余空间阈值（比如1GB=1048576KB）
MIN_FREE_SPACE=1048576
if [ $FREE_SPACE -lt $MIN_FREE_SPACE ]; then
    echo "磁盘剩余空间不足，无法执行备份"
    exit 1
fi

4. 保障备份一致性 #

• 临时暂停构建队列：备份前通过Jenkins API暂停新构建，避免文件被修改：

  # 需要配置Jenkins API Token，替换<USER>和<TOKEN>
  curl -u <USER>:<TOKEN> -X POST http://localhost:8080/queue/cancelQueue
  # 备份完成后恢复队列（可选，根据需求）
  # curl -u <USER>:<TOKEN> -X POST http://localhost:8080/queue/resumeQueue
  

• 使用Jenkins备份插件：推荐使用Backup Plugin，它能安全地快照Jenkins状态，自动处理正在运行的任务，还支持直接上传到S3，无需手动写脚本。

5. 长期优化：清理构建历史 #

20条流水线每条1500次构建会产生大量冗余数据，建议用Log Rotator插件配置自动清理规则：

• 保留最近100次构建
• 删除超过30天的构建
• 限制单条构建日志大小
  这样既能减少Jenkins home的体积，也能加快备份速度，降低磁盘压力。

实例可用性确认 #

t2.medium默认根卷一般为30GB，若当前Jenkins home体积小于20GB，即使落地压缩包（压缩率约30%-50%）也不会占满磁盘；但流式上传方案完全规避了磁盘占用风险，实例可以正常运行。可通过du -sh $JENKINS_HOME查看当前Jenkins home的实际大小。

内容的提问来源于stack exchange，提问作者nagarajukusa24