本质风险在于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 在脚本里设置容易被忽略或覆盖，且不阻止已有文件被修改。

更现实的问题是：很多运维习惯把备份丢进 /var/backups 或 /tmp，这些目录默认对 root 或 wheel 组开放写权限，等于把钥匙挂门把手上。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

真正起作用的是三件事：专用用户、目录 chown、目录 chmod 750 —— 缺一不可。

额外加固：防止备份文件被覆盖或误删 即使权限设对了，仍可能因脚本 bug 或手动操作导致覆盖。建议加两道保险：

• 备份文件名强制包含时间戳和校验码，例如：backup_20240615_142301_sha256_8a3f...，避免重名覆盖
• 对每次生成的备份文件立即计算并保存 SHA256，存为同名 .sha256 文件，并用 chown root:backupgroup + chmod 440 锁定校验文件
• 启用文件系统级防删除（如 ext4 的 chattr +a 不适用，但 chattr +i 可用于校验文件 —— 注意：设了 +i 后连 root 都不能改，需在生成后立刻设置

备份目录权限这事，表面是 chmod 几行命令，实际卡点永远在「谁在跑备份」和「谁还能碰这个目录」—— 漏掉任意一个环节，防篡改就形同虚设。