mysqldump不能直接管道进ossutil或curl，必须分三步：落地→校验→上传；需用绝对路径命令、显式设--check-md5/--update=false/--parallel-num=5/--connect-timeout=60等参数，并确保endpoint与Bucket地域严格匹配。
mysqldump 不能直接管道进 ossutil 或 curl
直接 mysqldump | ossutil cp - oss://bucket/backup.sql 必然失败。对象存储 API 不接受裸 SQL 流，ossutil 的 cp 命令也不支持从 stdin 读取——它会报 InvalidArgument: The specified stream is not seekable 或静默截断。curl 更危险：curl -X PUT --data-binary @- ... 会因缺失 Content-Length 触发 411 错误，或在网络抖动时中断无重试。
必须分三步：落地 → 校验 → 上传。中间任何一步失败，脚本应立即退出，不清理临时文件，方便人工介入。
- 用
mysqldump --single-transaction --routines --triggers --events导出，避免锁表和丢失逻辑对象 - 导出后立刻用
stat -c "%s" backup.sql检查文件大小，grep -q "ERROR\|Warning" backup.sql扫描错误关键词 - 生成带时间戳的绝对路径文件名，例如
/tmp/mydb_$(date +\%Y\%m\%d_\%H\%M\%S).sql，防止 cron 并发覆盖
ossutil cp 必须显式设参数才可靠
默认 ossutil cp 行为对备份场景极不友好：不校验、不限超时、允许覆盖、并发数过低。大库（>2GB）上传大概率失败或覆盖旧备份。
- 强制校验完整性：
--check-md5（上传前算本地 MD5 并写入 OSS Meta） - 防覆盖：
--update=false，否则定时任务重复跑一次，就把昨天的备份冲掉了 - 调高并发但别过头：
--parallel-num=5（默认 3），超过 10 可能触发 OSS 单 IP 请求频率限制 - 延长超时：
--connect-timeout=60 --request-timeout=3600，否则默认 10 秒超时，压缩+上传阶段必中断 - 确认 endpoint 与 Bucket 地域严格匹配，例如杭州 Bucket 必须用
https://oss-cn-hangzhou.aliyuncs.com，写成北京地址会报InvalidEndpoint
crontab 定时执行时环境变量和路径最常出错
脚本在终端能跑，加到 crontab 就报 mysqldump: not found 或 ossutil: command not found，90% 是因为 crontab 默认 PATH 极简（/usr/bin:/bin），且不加载 ~/.bashrc 或 /etc/profile。
- 所有命令用绝对路径：
/usr/bin/mysqldump、/usr/local/bin/ossutil（用which mysqldump确认） - 在脚本开头硬编码 PATH：
export PATH="/usr/local/bin:/usr/bin:/bin"，别依赖 source - 凭据必须预配置：
~/.ossutilconfig要存在且权限为600，RAM 子账号密钥不能硬编码进脚本 - 加锁防并发：
flock -n /tmp/mysql-backup.lock -c "your_backup_command"，避免上一次还没传完，下一次又启动
压缩和命名策略直接影响恢复效率
单个备份文件超 5GB，上传慢、下载慢、恢复时解压耗时长，还容易被勒索软件盯上——备份窗口越长，风险越高。
- 压缩必须流式：
mysqldump ... | gzip -c > file.sql.gz，别先 dump 再 gzip，浪费磁盘空间 - 用
gzip -3（非-9）：CPU 占用低、压缩率够用、速度更快 - 文件名必须含库名 + 时间戳 + 分卷标识（如需）：
mydb_20260609_121000.sql.gz，禁用backup.sql这类静态名 - 上传后立即用
ossutil head oss://bucket/mydb_20260609_121000.sql.gz验证对象是否存在，再删本地临时文件
真正卡住人的不是命令怎么写，而是临时文件没校验就删、ossutil 权限配错却以为是网络问题、crontab 路径不对还去查 ossutil 日志——这些点一旦漏掉，备份就形同虚设。
