mysql不支持备份数据自动透明加密，需先启用tde保护原始数据，再通过物理备份（如percona xtrabackup）完整保留加密状态与密钥环文件，mysqldump仅导出明文且无法恢复加密属性。
MySQL 本身不提供“对备份数据自动透明加密”的功能。所谓“敏感备份数据的透明加密存储”，实际是两件事的组合：先让数据库启用 TDE（透明数据加密）保护原始数据文件，再确保备份过程完整保留加密状态和密钥——否则备份出来仍是明文或无法还原。
mysqldump 备份无法保留 TDE 加密状态
mysqldump 读取的是 MySQL 服务层解密后的内存页，导出的 SQL 文件里全是明文。它不会记录 ENCRYPTION='Y' 属性，也不会导出密钥环内容。恢复后表默认未加密，且若密钥未加载，执行 ALTER TABLE ... ENCRYPTION='Y' 会报错 ERROR 3182 (HY000): Unable to load master key。
常见误操作：
- 用 mysqldump 做“合规备份”，以为导出文件自带加密 → 实际只是明文文本，需额外用
gpg或openssl enc手动加密 - 只备份
.ibd文件，忽略密钥环 → 恢复后查表直接报ERROR 1794 (HY000): Tablespace is encrypted but the keyring cannot be accessed
物理备份必须同时包含密钥环文件
TDE 的安全性完全依赖密钥环（keyring）——它独立于数据文件存在。物理备份不是“拷几个 .ibd 就完事”，而是三件套缺一不可：
- 数据文件：
ibdata1（若用系统表空间）、各库目录下的.ibd、ib_logfile*（若启用了innodb_encrypt_log=ON） - 密钥环文件：路径由
keyring_file_data配置项指定，典型为/var/lib/mysql-keyring/keyring；权限必须为600，属主为mysql - 配置快照：备份时刻的
my.cnf中关键项，如early-plugin-load=keyring_file.so、keyring_file_data=...、innodb_encrypt_tables=ON
漏掉密钥环文件，等于只偷到了锁住的保险箱，没拿到钥匙。
Percona XtraBackup 是唯一推荐的 TDE 友好备份工具
xbbackup（v8.0+）原生支持 TDE，但默认不备份密钥环，必须显式传参：
- 加
--keyring-file-data=/path/to/keyring：工具会把密钥环复制进备份目录的./keyring/子目录 - 加
--no-backup-locks：避免高并发写入时因锁冲突失败，错误类似Failed to acquire backup lock: Lock wait timeout exceeded - 验证不能只看
xbstream -x是否解压成功，必须启动临时实例，加载该备份 + 对应密钥环，再执行SELECT COUNT(*) FROM encrypted_table
注意：innodb_encrypt_log=ON 开启后，redo log 也加密，此时 xtrabackup 必须用 v8.0.30+ 版本，否则可能跳过日志加密校验导致恢复失败。
社区版 TDE 密钥管理极易翻车
MySQL 社区版仅支持 keyring_file 插件（component_keyring_file），密钥以明文形式存于本地文件。这是最大风险点：
- 密钥环文件被设为 world-readable（如
chmod 644）→ 攻击者直接cat出主密钥 - 密钥环放在 MySQL 数据目录下（如
/var/lib/mysql/keyring）→mysqldump --all-databases或 rsync 全量备份时一并泄露 - 从未轮换主密钥 → 一把密钥用三年，一旦泄露，所有历史备份全部失效
真正安全的做法是：密钥环路径必须独立于数据目录、日志目录、临时目录；生产环境强烈建议升级到企业版，用 keyring_encrypted_file（密钥环自身加密）或对接 keyring_aws/keyring_hashicorp 等外部 KMS。
