用 nohup 最快救急：nohup mysqldump -u root -p database_name > backup.sql 2>&1 &，必须配 2>&1 和 &；长期备份推荐 tmux；还需排查 MySQL 卡顿、磁盘 IO、锁表及 dump 文件完整性。
备份中途断连？用 nohup 最快救急
SSH 断开、本地终端关掉、网络抖动——这些都会直接 kill 掉前台运行的 mysqldump 进程，导致备份只写一半、甚至损坏 dump 文件。用 nohup 是最轻量的兜底方案，不依赖额外工具，所有 Linux 发行版都自带。
关键不是加 nohup，而是配对使用重定向和 &：
nohup mysqldump -u root -p database_name > backup.sql 2>&1 &- 必须加
2>&1：否则错误（比如权限拒绝、表不存在）会输出到终端并可能卡住进程 - 必须加末尾
&：让命令真正后台运行；漏掉它，nohup会挂起等待输入 - 执行后立刻看
nohup.out是否生成，且大小在缓慢增长，说明已活起来
长期跑大库？tmux 比 nohup 更可控
当备份要持续几小时、你还想中途查进度、切出去干别的、甚至断网重连后继续盯——nohup 就力不从心了。tmux 提供会话保持，是 DBA 级别的实际选择。
- 先运行
tmux new -s mysql-backup创建命名会话 - 里面执行
mysqldump -u root -p --single-transaction --routines database_name > backup.sql - 按
Ctrl-b d脱离会话，SSH 断了也不影响 - 重连后用
tmux attach -t mysql-backup直接回到原界面，还能看到实时输出和报错 - 注意别用
--lock-tables：它会阻塞写入，在tmux里卡住时更难诊断
备份卡住不动？检查这三处真实瓶颈
不是所有“中断”都是网络或终端问题，很多其实是 MySQL 自身卡死，nohup 或 tmux 只是掩盖症状。
- 查
SHOW PROCESSLIST：如果看到State: Sending data停很久，大概率是大表没索引导致全表扫描 - 看磁盘 I/O：
iostat -x 1中%util长期 100%，说明磁盘写满，mysqldump在等 IO，此时加后台也没用 - 确认是否用了
--single-transaction：没加的话，InnoDB 表可能被锁住，其他连接全堵住，你自己也连不进去看状态
备份文件不完整？别只怪后台工具
即使 nohup 成功跑完、tmux 里显示 “Dump completed”，backup.sql 仍可能缺结尾的 ; 或 UNLOCK TABLES，导致恢复时报语法错误。
- 执行前加
--skip-triggers --skip-routines测试最小集，排除存储过程/触发器引发的隐式锁 - 备份后立刻用
tail -n 5 backup.sql看末尾是不是干净的/* End of dump */或; - 用
gzip边压边备：mysqldump ... | gzip > backup.sql.gz，既减体积又靠管道机制自动检测上游是否异常退出
真正麻烦的不是怎么后台运行，而是备份过程中 MySQL 状态不可见、IO 不可测、锁不可控——这些细节一漏，后台跑得越久，恢复时越绝望。
