推荐最小安全备份命令：mysqldump -u root -p --single-transaction --routines --events --triggers --hex-blob --default-character-set=utf8mb4 mydb > /backup/mydb_$(date +%y%m%d).sql，需配合~/.my.cnf密码文件、绝对路径、path设置、错误日志及自动清理策略。
mysqldump 命令怎么写才不丢数据
直接用 mysqldump 默认参数备份，极大概率漏掉表结构或丢失事务一致性。比如没加 --single-transaction，备份期间有写入就会产生不一致；没加 --routines 和 --events，存储过程和事件就没了。
推荐最小安全组合：
-
--single-transaction：对 InnoDB 表保证一致性快照（MyISAM 仍需--lock-all-tables） -
--routines --events --triggers：一并导出存储过程、事件、触发器 -
--hex-blob：避免二进制字段（如 BLOB）在转义时损坏 -
--default-character-set=utf8mb4：防止字符集不匹配导致乱码
示例命令：
mysqldump -u root -p'xxx' --single-transaction --routines --events --triggers --hex-blob --default-character-set=utf8mb4 mydb > /backup/mydb_$(date +\%Y\%m\%d).sql
shell 脚本里怎么安全处理密码和路径
把密码明文写进脚本或命令行，ps aux 一眼就能看到，也容易被历史命令泄露。MySQL 官方推荐用配置文件 + 权限控制，而不是 `-p` 后直接跟密码。
- 新建
~/.my.cnf，内容：[client] user = backup_user password = your_strong_password host = localhost
- 立刻执行
chmod 600 ~/.my.cnf，否则mysqldump会拒绝读取 - 备份路径必须用绝对路径，且确保运行脚本的用户（如
mysql或backup）有写权限 —— 常见坑是定时任务用root运行，但备份目录属主是mysql，结果写失败没报错
crontab 定时执行为什么总失败
本地手动跑通的脚本，放进 crontab 就静默失败，90% 是环境变量和路径问题。cron 不加载你的 ~/.bashrc，所以 mysqldump 可能根本找不到。
- 脚本开头强制指定 PATH：
#!/bin/bash PATH=/usr/local/bin:/usr/bin:/bin
- 所有命令用绝对路径：
/usr/bin/mysqldump而不是mysqldump - 重定向 stderr 到日志：
2>> /var/log/backup.log，否则错误全丢进黑洞 - crontab 条目别用
~，写成完整路径：0 2 * * * /home/backup/backup.sh
备份文件怎么避免越积越多占满磁盘
没人清理的备份，三个月后你会发现 /backup 目录只剩 2% 空间。自动删旧不能靠“大概看看”，得按时间戳精准控制。
- 用
find按修改时间删（比按文件名更可靠）：find /backup -name "*.sql" -mtime +7 -delete
- 如果备份名含日期（如
mydb_20240501.sql），也可用ls | grep -v "$(date -d '7 days ago' +%Y%m%d)" | xargs rm -f，但注意这种依赖文件名格式，不如-mtime稳定 - 加个空间检查再备份：
if [ $(df /backup | awk 'NR==2 {print $5}' | sed 's/%//') -gt 85 ]; then exit 1; fi，超阈值直接退出，避免写到一半磁盘满
真正麻烦的是跨服务器备份或加密传输，那些得另配 ssh key 和 gpg，当前脚本先守住本地一致性——毕竟连本地都备不全，谈什么容灾。
