Redis的RDB文件默认以明文形式存储，官方从未提供内置加密能力。依赖requirepass或tls-cert-file来保护磁盘上的dump.rdb，完全是方向性错误——这些配置仅控制连接与传输安全，与文件内容本身无关。生产环境中，真正可行的方案只有两条：要么修改Redis源码在RDB写入前执行加密（不推荐），要么利用落盘后的hook机制，借助外部工具对文件进行加密。后者是经过验证、可审计且无需编译的成熟路径。
Redis RDB文件本身不支持加密，必须在落盘前或落盘后处理
save或bgsave生成的dump.rdb始终是明文二进制格式。Redis官方从未实现任何内置加密机制（如AES密封、密钥派生），因此不要指望配置项来保护它。实际操作中，可行的两条路径分别是：在RDB写入前加密（需修改源码，不推荐），或者在保存完成后通过外部工具加密文件。后者是生产环境唯一稳定且免编译的方案。
save和bgsave成功后会触发notify-keyspace-events？不，该机制与RDB无关，仅对key事件有效。- Redis没有
on-rdb-complete回调，但我们可以通过save命令返回成功，再结合INFO persistence中的rdb_last_save_time进行轮询判断。 - 更可靠的做法是配合
redis.conf中的dir和dbfilename，监控对应路径下文件的mtime变更，并验证size是否非零。
用inotifywait监控RDB落盘并触发gpg加密（推荐轻量方案）
Linux下最直接的方法，就是监听dir目录中dbfilename的写入完成事件。但注意：不能监听CREATE，因为bgsave先写临时文件（如temp-123.rdb），再通过rename覆盖原文件。我们要捕获的是MOVED_TO事件。
inotifywait -m -e moved_to --format '%w%f' /var/lib/redis/ | while read file; do
if [[ "$file" == "/var/lib/redis/dump.rdb" ]]; then
gpg --batch --yes --passphrase-fd 0 --cipher-algo AES256 \
-c "$file" < /etc/redis/rdb-passphrase.txt
# 加密后保留 .gpg 后缀，原文件可按策略删除或保留
rm "$file"
fi
done
- 务必使用
--batch --yes避免交互阻塞；--passphrase-fd 0从stdin读取密码，避免泄露到ps aux中。 - 不要用
echo "xxx" | gpg ...，因为密码会出现在shell历史或进程参数里；改用cat /path/to/passphrase.txt | gpg ...或上述重定向方式。 inotifywait进程需要随Redis一起启动，建议用systemd service管理，并设置Restart=always防止崩溃漏监。- 加密后的
dump.rdb.gpg无法被Redis直接加载；恢复时必须先gpg -d dump.rdb.gpg > dump.rdb，再启动Redis。
Linux全盘加密（LUKS）能替代RDB加密吗？不能，但可以补位
LUKS加密的是块设备——只要系统未解锁，RDB文件在磁盘上就是密文。但它完全不解决运行时风险：一旦root登录、Redis进程运行、或者备份脚本执行，dump.rdb在内存和page cache中全程明文，而且可以被cp、tar、rsync等任意工具读出。
- LUKS对防物理窃盘有效，但对运维误操作、恶意进程、容器逃逸、备份管道泄露均无防护。
- 如果Redis和备份脚本在同一台机器上运行，且备份走本地文件系统，LUKS无法阻止备份过程中的明文暴露。
- 真正需要的是“数据静止态加密”（at-rest）+“数据移动态加密”（in-transit）+“数据使用态最小化”（in-use）三层防护，LUKS只覆盖第一层。
- 如果已经启用了LUKS，仍然建议对RDB单独加密——相当于给保险箱再加一把挂锁，两把钥匙分属不同管理员。
恢复时解密RDB的关键检查点
加密不是目的，可恢复才是。很多团队加密了却忘了验证还原流程，上线后才发现gpg版本不兼容、密钥丢失、或者解密后文件损坏。
- 每次加密脚本更新后，务必手动执行一次完整恢复测试：
gpg -d dump.rdb.gpg > /tmp/test.rdb && redis-check-rdb /tmp/test.rdb。 redis-check-rdb是Redis自带的工具，能快速验证RDB结构完整性，比启动Redis再用info keyspace更快更安全。- 不要依赖
file dump.rdb.gpg判断是否加密成功——GPG加密后仍是二进制，file输出可能还是“data”，得靠gpg --list-packets查看packet类型。 - 如果用
openssl enc替代gpg，注意OpenSSL 1.1.1+默认加salt，但老版本不加；跨环境迁移时，salt和IV处理逻辑必须一致，否则解密失败。
最容易被跳过的一步：没有把解密密钥纳入密钥管理系统（比如HashiCorp Vault、AWS KMS），而是硬编码在脚本或文件里。一旦服务器被入侵，加密形同虚设。
