mysqldump不能直接管道进ossutil或curl？这确实是一个常见的坑。许多用户误以为`mysqldump | ossutil cp - oss://bucket/backup.sql`就能轻松搞定，结果要么遇到`InvalidArgument`报错，要么文件被静默截断。更危险的是直接用curl进行PUT操作，缺少`Content-Length`头，网络一旦波动就会中断——而且没有任何重试机制。 所以，千万别偷懒，必须严格分三步走：先落地文件，再校验完整性，最后上传。中间任何一步失败，脚本就应该立即退出，临时文件也不要清理，方便人工排查问题。 落地这一步，使用`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 的参数必须显式设**，默认行为对备份场景来说相当不友好——不校验文件完整性、超时短、允许覆盖、并发数也低。大库超过2GB时，上传失败几乎是家常便饭。 强制校验可以用`--check-md5`，上传前计算好本地MD5并写入OSS元数据。防覆盖则靠`--update=false`，否则定时任务每天跑一次，昨天的备份就会被冲掉。并发数可以调到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`，90%是因为crontab的默认PATH太简陋（只有`/usr/bin:/bin`），而且不加载`~/.bashrc`或`/etc/profile`。 解决方案很直接：所有命令用绝对路径，比如`/usr/bin/mysqldump`、`/usr/local/bin/ossutil`（用`which`确认一下具体位置）。脚本开头硬编码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日志——这些细节一旦漏掉，备份就形同虚设。