MySQL备份安全需严控权限、内容加密和存储隔离：禁用命令行密码，改用600权限的.my.cnf或mysql_config_editor；备份输出立即用gpg AES256加密；文件权限设为600、目录700，禁止存于/tmp或Web路径；专用backup_user仅授SELECT等最小权限；自动化流程须原子化执行权限收紧、加密、校验与推送。
备份文件泄露账号和数据，根本原因不是备份工具本身，而是权限、内容、存储三处失控。只要控制住这三点，泄露风险可压到极低。
mysqldump 命令里别写密码
这是最常见也最危险的泄露点。mysqldump -u root -p'123456' db 这种写法会让密码直接出现在 ps aux 输出、shell 历史、系统日志里，任何能登录服务器的人都可能翻到。
- 改用
.my.cnf配置文件：在[client]段写user=backup_user和password=xxx，然后立即执行chmod 600 ~/.my.cnf - 生产环境更推荐
--defaults-extra-file=/etc/mysql/backup.cnf，该文件属主设为专用用户（如backup），权限必须是600 - 或用
mysql_config_editor存储登录路径：mysql_config_editor set --login-path=backup --user=backup_user --password，后续用--login-path=backup调用
备份文件本身要加密
即使权限收紧、密码不外泄，备份文件一旦被拷走，里面全是明文 SQL —— 表结构、数据、甚至 CREATE USER 或 CHANGE MASTER TO 语句里的账号密码全暴露。
- 用
gpg --symmetric --cipher-algo AES256加密输出：mysqldump -u backup_user db | gpg --symmetric --cipher-algo AES256 > backup.sql.gpg - 解密验证必须纳入流程：
gpg --decrypt backup.sql.gpg | head -n 10确认可解，再全量导入 - 避免用
openssl enc -aes-256-cbc默认参数，务必加-pbkdf2 -iter 1000000提高暴力破解成本
备份目录权限和存放位置要严控
Linux 下默认新建文件权限是 644，意味着同服务器其他普通用户能直接 cat 你的 backup.sql；存到 /tmp 或 Web 目录更是等于公开发布。
- 执行
mysqldump前先设umask 077，确保生成文件默认权限为600 - 若用
xtrabackup，整个备份目录（含内部的xtrabackup_binlog_info和backup-my.cnf）必须chmod 700 - 绝对禁止存到
/var/www/html/、/tmp、/home/xxx/public_html这类路径 - 推荐分层存储：本地临时区（
/backup/tmp，600权限）→ 推送至内网备份服务器（SFTP + chroot）→ 归档至对象存储（开启 SSE 和版本控制）
备份账户权限必须最小化
用 root 备份，等于把数据库钥匙连同保险柜图纸一起交出去。一旦备份文件泄露，攻击者不仅拿到数据，还可能顺出主从账号、系统表结构甚至哈希密码。
- 创建专用用户：
CREATE USER 'backup_user'@'localhost' IDENTIFIED BY 'StrongPass@123'; - 只授必要权限：
GRANT SELECT, LOCK TABLES, SHOW VIEW, TRIGGER ON myapp.* TO 'backup_user'@'localhost'; - 禁用全局授权：
REVOKE ALL PRIVILEGES ON *.* FROM 'backup_user'@'localhost'; - 特别注意：不要给
REPLICATION CLIENT或PROCESS，除非真需要--master-data；这些权限可能暴露 binlog 位置和运行中查询
真正容易被忽略的，是备份后那几秒——文件刚生成、还没来得及 chmod 或 gpg 加密的窗口期。自动化脚本里必须把权限收紧、加密、校验、推送四步串成原子操作，中间不能断。否则，一次手动调试、一次脚本中断，就可能留下裸奔的备份文件。
