mongodump不支持原生流式加密，因其设计定位是逻辑备份工具，专注输出可读、可移植的BSON/JSON数据，未集成AES/GPG等加密能力；所有加密必须由gpg、openssl等外部工具在管道中完成。
mongodump 输出流本身不加密，必须在管道外加壳处理 —— 直接依赖 mongodump 的 --out 参数或 stdout 无法获得加密备份。
为什么 mongodump 不支持原生流式加密
mongodump 是逻辑备份工具，设计目标是可读、可移植、可增量恢复。它输出 BSON/JSON 文件，不内置 AES 或 GPG 加密能力；所有“加密”动作都需由外部工具完成。官方文档从未声明支持 --encrypt 或类似参数，任何声称“mongodump --encrypt”的教程都是错误的。
常见误解包括：把 TLS 传输加密（--ssl）当成备份文件加密，或混淆存储引擎级加密（WiredTiger TDE）与备份流加密 —— 后者保护的是磁盘上运行时的数据，不是 mongodump 生成的临时文件。
对 stdout 做实时 GPG 加密的可靠写法
最轻量、最可控的方式是用管道将 mongodump 的 stdout 直接喂给 gpg，避免落地明文：
mongodump --host localhost:27017 --db myapp --archive | gpg --cipher-algo AES256 --compress-algo 2 --symmetric --armor > backup-$(date +%Y%m%d).dump.asc
-
--archive是必须的：启用归档模式才能输出到 stdout，否则mongodump拒绝管道输入 -
--symmetric表示使用口令加密（非公钥），适合定时任务配合GPG_AGENT_INFO或gpg-preset-passphrase -
--armor输出 base64 编码文本，便于传输和校验；若追求体积，可去掉并改用.dump.gpg后缀 - 不要用
gzip | gpg双压缩——GPG 自带 zlib 压缩（--compress-algo 2），重复压缩无收益反增 CPU
备份密钥管理与恢复链风险点
加密备份真正难的不是命令怎么写，而是密钥生命周期是否闭环：
- 口令不能硬编码在脚本里，应通过环境变量注入或使用
gpg-agent管理；否则ps aux可能泄露口令 -
gpg --decrypt backup.dump.asc | mongorestore --archive恢复时，若网络中断或管道崩溃，mongorestore可能只写入部分数据且不报错 - WiredTiger 存储引擎加密（TDE）和 GPG 流加密不兼容：TDE 加密的是
mongod运行时的数据文件，而mongodump读取的是解密后的内存视图，所以 GPG 加密的是明文逻辑数据 —— 这没问题，但别误以为开了 TDE 就不用 GPG - 如果用
--query做条件导出，注意查询条件本身可能含敏感字段（如{ssn: /^123/}），这些会出现在 shell 历史中，建议用--queryFile外部加载
替代方案：用 rclone + server-side encryption 上传即加密
如果备份目标是对象存储（如 S3、MinIO），更推荐绕过本地加密，让传输层直接保障安全：
rclone copy --s3-server-side-encryption AES256 ./backup/ remote:backups/mongo/
这种做法把加密委托给存储服务，省去 GPG 口令分发、密钥轮换等运维负担。但前提是信任云厂商的 KMS 实现，且确认 rclone 版本 ≥1.62（旧版 --s3-server-side-encryption 不生效）。
真正容易被忽略的是：无论用 GPG 还是 rclone，mongodump 执行前必须确保数据库处于一致状态 —— 如果没加 --forceTableScan 或没停写，遇上 WiredTiger 的 checkpoint 延迟，备份可能丢失最近几秒提交的事务。这不是加密问题，但会让加密了的备份变成“不可用的假象”。
