本质风险在于MySQL不校验备份文件完整性，攻击者获备份目录写权限即可篡改；必须用专用用户chown+chmod 750锁定OS层访问权限，缺一不可。
备份文件被篡改的本质风险在哪
MySQL 自身不校验备份文件完整性，mysqldump、mysqlpump 或物理备份（如 xtrabackup）生成的文件一旦写入磁盘，就完全依赖操作系统层的权限控制。攻击者只要能登录到备份服务器、且对备份目录有写权限，就能替换、删改甚至注入恶意 SQL —— 这不是 MySQL 的漏洞，而是权限配置缺失的后果。
关键判断：仅靠 MySQL 用户权限或备份脚本加密码，完全无法防篡改；必须从 OS 层锁定目录的写入主体。
设置备份目录权限的实操要点
直接用 chmod 和 chown 锁死目录所有权和访问范围是最有效手段，但要注意几个实际约束：
- 备份进程（如
mysqldump）必须由专用低权限系统用户运行（例如 backupuser），不能用 root 或 mysql 用户执行
- 备份目录归属必须设为该专用用户 + 专用组，例如：
chown backupuser:backupgroup /backup/mysql
- 目录权限严格设为
750（所有者读写执行，组内只读执行，其他无权限），禁止 777 或 755：chmod 750 /backup/mysql
- 确保备份脚本本身（如
/usr/local/bin/backup-mysql.sh）也设为 750，且属主同为 backupuser
为什么不能只靠 umask 或备份命令加 --single-transaction
--single-transaction 只保证备份时数据一致性，和文件落地后的安全性无关；umask 在脚本里设置容易被忽略或覆盖，且不阻止已有文件被修改。
mysqldump）必须由专用低权限系统用户运行（例如 backupuser），不能用 root 或 mysql 用户执行chown backupuser:backupgroup /backup/mysql
750（所有者读写执行，组内只读执行，其他无权限），禁止 777 或 755：chmod 750 /backup/mysql
/usr/local/bin/backup-mysql.sh）也设为 750，且属主同为 backupuser
--single-transaction 只保证备份时数据一致性，和文件落地后的安全性无关；umask 在脚本里设置容易被忽略或覆盖，且不阻止已有文件被修改。
更现实的问题是：很多运维习惯把备份丢进 /var/backups 或 /tmp，这些目录默认对 root 或 wheel 组开放写权限，等于把钥匙挂门把手上。
真正起作用的是三件事：专用用户、目录 chown、目录 chmod 750 —— 缺一不可。
额外加固：防止备份文件被覆盖或误删
即使权限设对了，仍可能因脚本 bug 或手动操作导致覆盖。建议加两道保险：
- 备份文件名强制包含时间戳和校验码，例如：
backup_20240615_142301_sha256_8a3f...，避免重名覆盖
- 对每次生成的备份文件立即计算并保存 SHA256，存为同名
.sha256 文件，并用 chown root:backupgroup + chmod 440 锁定校验文件
- 启用文件系统级防删除（如 ext4 的
chattr +a 不适用，但 chattr +i 可用于校验文件 —— 注意：设了 +i 后连 root 都不能改，需在生成后立刻设置
备份目录权限这事，表面是 chmod 几行命令，实际卡点永远在「谁在跑备份」和「谁还能碰这个目录」—— 漏掉任意一个环节，防篡改就形同虚设。
backup_20240615_142301_sha256_8a3f...，避免重名覆盖.sha256 文件，并用 chown root:backupgroup + chmod 440 锁定校验文件chattr +a 不适用，但 chattr +i 可用于校验文件 —— 注意：设了 +i 后连 root 都不能改，需在生成后立刻设置
