健壮的备份脚本需包含路径检查、时间戳命名、tar压缩、sha256校验、日志记录和错误退出；云存储推荐rclone或官方cli，凭据不硬编码；cron需设环境变量、绝对路径、邮件通知及flock锁；本地与云端均须定期清理旧备份。
用 Shell 脚本定时备份并上传到云存储，核心是三步：写好备份脚本、配置云存储 CLI 工具、用 cron 安排执行。关键不在“能不能做”，而在“是否可靠”——比如失败不报警、压缩没校验、旧备份不清理，都可能让备份形同虚设。
写出可重复、带日志和校验的备份脚本
不要只 tar 一下就完事。一个健壮的备份脚本应包含路径检查、时间戳命名、压缩、SHA256 校验、日志记录和简单错误退出。
- 用 date +%Y%m%d_%H%M 生成唯一文件名，避免覆盖
- 用 tar -czf 打包并压缩，加 --warning=no-file-changed 忽略瞬时变化警告
- 运行 sha256sum backup.tar.gz > backup.tar.gz.sha256 生成校验文件
- 所有 stdout/stderr 重定向到日志文件，例如 >/var/log/backup.log 2>&1
- 每步后加 || { echo "步骤失败"; exit 1; } 做基础错误拦截
选对云工具并完成可信认证
推荐使用官方 CLI：AWS 用 aws-cli，阿里云用 aliyun-cli，腾讯云用 tencentcloud-cli，或通用方案 rclone（支持 70+ 存储，配置更统一）。
- 避免在脚本里硬编码密钥，用 ~/.aws/credentials 或 rclone config 存储凭据
- 测试上传：手动运行 aws s3 cp backup.tar.gz s3://my-bucket/ 确认权限和网络正常
- 上传后建议加一步 aws s3 head-object --bucket my-bucket --key backup.tar.gz 验证对象存在
用 cron 精确调度并监控执行结果
cron 不只是“每天凌晨 2 点跑”，还要考虑环境变量缺失、路径不全、输出无声等问题。
- 在 crontab 中显式声明 SHELL=/bin/bash 和 PATH=/usr/local/bin:/usr/bin:/bin
- 用绝对路径写脚本，例如 0 2 * * * /opt/scripts/backup.sh
- 把执行结果邮件发给自己：0 2 * * * /opt/scripts/backup.sh | mail -s "Backup Report" admin@example.com
- 加个简单的锁机制（如 flock -n /tmp/backup.lock -c "/opt/scripts/backup.sh"），防重复启动
自动清理旧备份，防止空间耗尽
备份不是越多越好，而是“够用且可验证”。本地和云端都要设保留策略。
- 本地保留最近 7 天：find /backup -name "*.tar.gz" -mtime +7 -delete
- 云端清理（以 S3 为例）：aws s3api list-objects-v2 --bucket my-bucket --prefix "backup_" --query 'Contents[?LastModified
- 更稳妥的做法：上传时用日期前缀（如 s3://my-bucket/20240501/backup.tar.gz），再按目录批量清理
不复杂但容易忽略细节。真正上线前，手动跑一次完整流程，检查日志、校验值、云上文件、清理动作，再放开定时任务。
