mysql备份脚本必须先用mountpoint -q校验nfs挂载，失败则尝试mount并exit 1；需确保客户端mysql用户uid与服务端目录权限匹配；避免mysqldump | gzip直写nfs，应分步落盘再压缩；cron任务需加失败重试和日志推送。
MySQL备份脚本必须检查NFS挂载状态
直接写入未挂载的NFS路径会导致备份静默失败，mysqldump 生成空文件或报错 Cannot open file，但脚本可能继续执行后续压缩和清理，最终留下无效备份。必须在脚本开头显式校验挂载点。
- 用
mountpoint -q "/nfs_shared/163"判断是否已挂载，返回非零值即失败 - 失败时应尝试
mount /nfs_shared/163，并用|| exit 1中断流程，避免误写本地磁盘 - 不要依赖
df -h输出判断——它可能显示旧挂载残留（如服务端已关机但客户端未 umount）
备份目录权限和用户UID需与NFS服务端对齐
NFS默认以客户端UID映射写入，若MySQL备份进程用 mysql 用户运行，而服务端 /shared 目录属主是 root 且无写权限，备份会因 Permission denied 失败，且错误常被 mysqldump 的 stdout/stderr 混淆掩盖。
- 服务端创建共享目录后，执行
chown -R mysql:mysql /shared（前提是服务端也存在 UID 匹配的mysql用户） - 或在
/etc/exports中加all_squash,anonuid=27,anongid=27，强制所有写入归为指定 UID/GID - 验证方式：在客户端
sudo -u mysql touch /nfs_shared/163/test，成功即表示权限通路正常
mysqldump + gzip 写入NFS时性能明显下降，需调整参数
NFS的同步写入特性（尤其是 sync 选项）会让 mysqldump 直接输出到远程文件变慢，且 gzip 管道式压缩无法缓冲，容易触发超时或中断。
- 避免
mysqldump ... | gzip > backup.sql.gz—— 这种管道在NFS上极易卡死 - 改为两步：先
mysqldump ... > backup.sql，再gzip backup.sql，确保落盘完成后再压缩 - 若备份库较大，可在客户端本地临时目录生成 SQL，再
mv到 NFS 目录（mv在同一文件系统内是原子操作，NFS上也比cp更可靠）
定时任务要避开NFS服务端维护窗口
cron 触发备份时，若恰逢 NFS 服务端重启或网络抖动，mount 可能失败，而默认 cron 不重试也不告警，导致连续多日无有效备份。
- 在 crontab 中添加重试逻辑，例如：
*/5 * * * * /usr/local/bin/mysql_backup.sh || sleep 60 && /usr/local/bin/mysql_backup.sh - 把备份结果写入日志并用
logger推送系统日志，便于用journalctl -u cron | grep mysql_backup快速排查 - 关键点：NFS挂载本身不保证高可用，异地备份≠高可用备份——服务端单点故障仍会导致备份中断
