不能用root做备份，因其权限过大导致凭证泄露即获最高权限；备份账户只需SELECT、LOCK TABLES、SHOW VIEW、TRIGGER四类最小权限，禁用ALL PRIVILEGES和全局授权，密码文件须设600权限。
备份账户必须用最小权限，否则等于给攻击者开了后门
为什么不能用 root 做备份
用 root 账户执行 mysqldump 看似省事，但一旦备份脚本、日志或配置文件泄露，攻击者就直接获得数据库最高权限。更危险的是，某些备份方式（如 --master-data=2）会在 SQL 文件里写入 CHANGE MASTER TO 语句，其中可能包含主从账号密码——如果用 root 备份，这些敏感信息就全暴露了。
-
root可读所有库、所有表，包括mysql系统库里的用户表和权限表 - 备份脚本若被注入或误传到 Web 目录，SQL 文件里可能含明文凭证（尤其
backup-my.cnf或xtrabackup_binlog_info） - 容器或 CI/CD 环境中，
root凭据常被挂载为环境变量，极易被子进程继承或泄漏到/proc/$PID/environ
只给备份账户这 4 条权限就足够
创建专用备份用户时，显式授予最小集合，不依赖 GRANT OPTION 或通配符授权：
-
SELECT：读取数据是基本需求，但仅限目标库（如GRANT SELECT ON myapp.* TO 'backup_user'@'localhost'） -
LOCK TABLES：配合--single-transaction时非必需，但对 MyISAM 或混合引擎仍需；若全为 InnoDB，可省略 -
SHOW VIEW：导出视图定义所需，否则mysqldump会跳过视图或报错 -
TRIGGER：导出触发器逻辑必需，不加则触发器不会出现在备份文件中
绝对不要给 INSERT、UPDATE、DELETE、DROP、CREATE、ALTER，也禁止 ON *.* 全局授权。
配置文件里存密必须设 600 权限
用 .my.cnf 避免命令行传密，但文件本身若权限宽松，等同于裸奔：
- 创建时立即执行
chmod 600 ~/.my.cnf，确保只有属主可读写 - 内容严格限定在
[client]段，且只写user和password，不写host或port（避免意外连错实例） - 生产环境禁用
~/.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后，其生成的~/.mylogin.cnf同样要chmod 600
备份过程中最易被忽略的权限泄露点
即使账户权限收紧，操作不当仍会引入风险：
-
mysqldump --all-databases会尝试 dump 所有库，包括information_schema和performance_schema，而后者可能暴露运行时敏感指标（如查询文本、连接来源） - 使用
--routines导出存储过程时，若过程内硬编码了密码或密钥，会被一并输出到 SQL 文件 -
xtrabackup的backup-my.cnf文件默认含[mysqld]配置，若其中写了loose-plugin-load或自定义插件路径，可能间接暴露系统信息 - 脚本中用
echo $MYSQL_PWD或set -x调试，会让密码出现在 shell 日志或ps aux输出里
真正安全的备份不是“能跑通就行”，而是每一步都确认：这个操作会不会把不该暴露的东西，变成文件、日志或内存里的明文。
