最简单有效的方式是用 2> 捕获 mysqldump 错误日志，因其错误全走 stderr；需配合退出码判断（成功为0）并添加时间戳和命令上下文以准确定位问题。
mysqldump 命令中如何捕获错误日志
直接重定向 2> 是最简单有效的方式，因为 mysqldump 的错误（如权限拒绝、表不存在、连接超时）全走标准错误流，不混在标准输出里。如果只用 > backup.sql，所有报错都会被丢弃，你根本不知道备份失败了。
常见错误现象：mysqldump: Got error: 1045: Access denied for user 'xxx'@'localhost' 这类提示不会出现在 SQL 文件里，必须显式捕获。
- 推荐写法：
mysqldump -u root -p database_name > backup.sql 2> dump_error.log - 若想同时看到屏幕输出和存日志，加
2>&1 | tee error.log，但注意这会把 stderr 和 stdout 合并，后续 grep 错误需更小心 - 不要用
2>&1 > backup.sql—— 这种顺序会导致 stderr 实际仍输出到终端，文件里没错误
如何让日志包含时间戳和命令上下文
纯重定向不带时间信息，出问题后难定位是哪次执行失败。尤其定时任务里，多个备份脚本并发跑时，日志容易混淆。
实操建议：
- 用
date手动打点：echo "=== $(date '+%Y-%m-%d %H:%M:%S') mysqldump start ===" >> backup.log && mysqldump ... 2>> backup.log - 更稳妥的做法是把整个命令包进子 shell 并统一重定向：
(date; echo "cmd: mysqldump -u..."; mysqldump -u... 2>&1) >> full_backup.log - 避免在
crontab中直接写复杂重定向，先封装成脚本，再调用——cron 对2>&1解析有时不一致
备份成功与否怎么判断？光看日志文件大小不行
错误日志为空 ≠ 备份成功。可能连接成功但导出零行（比如 where 条件过滤太严），也可能 SQL 文件开头就中断（磁盘满、kill -9 中断），但 dump_error.log 仍是空的。
必须检查退出状态码：
-
mysqldump成功时返回 0，任何错误（包括警告如Warning: Skipping the data of table xxx）都可能返回非 0 - 写脚本时务必加判断：
if ! mysqldump -u... > backup.sql 2> error.log; then echo "FAIL at $(date)" >> monitor.log; exit 1; fi - 别依赖
ls -l backup.sql | awk '{print $5}'判大小——空文件或半截文件都可能有几百字节
使用 --log-error 参数是否可行？
不可行。mysqldump 本身不支持 --log-error，那是 mysqld 服务端用的参数。试图加上只会报错：Unknown option '--log-error'。
真正能用的日志相关选项只有：
-
--verbose：输出更多过程信息（如正在处理哪张表），但走 stdout，不是错误日志 -
--force：遇到 SQL 错误（如某行数据格式异常）继续导出，但错误仍走 stderr，需配合重定向捕获 - 没有内置“错误写入指定文件”的开关，一切靠 shell 重定向解决
$?，结果半夜备份静默失败，第二天才发现库丢了。stderr 重定向只是第一步，状态判断才是兜底动作。 
