备份文件权限必须严格限制
MySQL 备份文件（如
mysqldump生成的 SQL 文件或
xtrabackup的备份目录）一旦被未授权用户读取，就等于直接暴露了数据库全部明文数据。Linux 下默认创建的文件权限往往是
644或
755，这会让同服务器其他普通用户也能查看。
实操建议：
执行mysqldump时用
--result-file指定路径，并立即用
chmod 600 /path/to/backup.sql收紧权限 若用
mysqlpump或脚本调用，建议在重定向前加
umask 077，确保新建文件默认无组/他人权限
xtrabackup备份目录需整体设为
700，尤其注意其内部的
xtrabackup_binlog_info和
backup-my.cnf可能含主从凭证 避免把备份存到
/tmp或 Web 可访问路径（如
/var/www/html/backups/），否则可能被直接下载
加密备份内容而非仅加密传输通道
只依赖 SSH 隧道或 SSL 连接做
mysqldump | gzip | ssh传输，无法防止备份文件落地后被窃取。真正安全的备份必须对内容本身加密。
实操建议：
用gpg --symmetric --cipher-algo AES256加密 dump 文件：
mysqldump -u root db | gpg --symmetric --cipher-algo AES256 > backup.sql.gpg密钥不硬编码进脚本，改用
gpg --batch --passphrase-fd 0从 stdin 读取，配合
systemd的
EnvironmentFile或专用密钥管理服务（如 HashiCorp Vault）分发密码 避免使用
openssl enc -aes-256-cbc等弱默认参数组合，务必显式指定
-pbkdf2 -iter 1000000解密验证要纳入恢复流程：
gpg --decrypt backup.sql.gpg | head -n 10确认可解再全量导入
避免在命令行中暴露账号密码
在
mysqldump -u root -p'password' db这类写法中，密码会出现在
ps aux输出和 shell 历史中，极易泄露。MySQL 官方明确警告这是高危行为。
实操建议：
统一使用配置文件方式：创建~/.my.cnf，权限设为
600，内容含
[client]段并写入
user和
password若需多环境隔离，用
--defaults-extra-file=/etc/mysql/backup.cnf指定专用配置，避免污染用户级
.my.cnf临时密码可用
mysql_config_editor set --login-path=backup --user=root --password存储加密凭据，调用时用
--login-path=backup容器化部署时，通过
secret挂载配置文件，禁止用
ENV MYSQL_ROOT_PASSWORD直传密码
备份校验不能只靠文件存在性
备份成功 ≠ 数据可恢复。常见陷阱是
mysqldump因权限不足跳过某些表却静默返回 0，或
xtrabackup在复制期间遭遇磁盘满导致部分文件截断，但备份进程仍退出成功。
实操建议：
每次备份后立即执行gzip -t backup.sql.gz（若压缩）或
head -n 100 backup.sql | grep -q "CREATE TABLE"快速确认基础结构完整 对关键库启用
--single-transaction --routines --triggers --events全量参数，并检查输出末尾是否有
dump completed而非中途中断 定期（如每周）抽样恢复：用
mysql -e "CREATE DATABASE restore_test"+
mysql restore_test ，再查 <code>SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='restore_test'记录并比对备份前后
SELECT COUNT(*) FROM mysql.db和
SHOW GRANTS输出，防止权限元数据丢失 备份的安全性不在“有没有”，而在“谁可见、能否篡改、是否真可用”。最容易被忽略的是恢复链路的完整性——加密密钥轮换后旧备份是否还能解密？权限变更后
.my.cnf是否同步更新？这些细节往往在故障时才暴露。
