mysqldump不能直接管道进ossutil或curl,必须分三步:落地→校验→上传;需用绝对路径命令、显式设--check-md5/--update=false/--parallel-num=5/--connect-timeout=60等参数,并确保endpoint与Bucket地域严格匹配。
直接 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 行为对备份场景极不友好:不校验、不限超时、允许覆盖、并发数过低。大库(>2GB)上传大概率失败或覆盖旧备份。
--check-md5(上传前算本地 MD5 并写入 OSS Meta)--update=false,否则定时任务重复跑一次,就把昨天的备份冲掉了--parallel-num=5(默认 3),超过 10 可能触发 OSS 单 IP 请求频率限制--connect-timeout=60 --request-timeout=3600,否则默认 10 秒超时,压缩+上传阶段必中断https://oss-cn-hangzhou.aliyuncs.com,写成北京地址会报 InvalidEndpoint
脚本在终端能跑,加到 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 确认)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 日志——这些点一旦漏掉,备份就形同虚设。