mongodump不能直接按“文件”语义备份gridfs，但能完整导出fs.files和fs.chunks两个集合；必须确认实际使用的bucket前缀（如mybucket.files），显式指定集合名备份，恢复后须手动创建{filename:1,uploaddate:1}和{files_id:1,n:1}复合唯一索引，否则查询失败。
mongodump 能否直接备份 GridFS 文件
不能直接按“文件”语义备份，但能完整导出 fs.files 和 fs.chunks 两个集合——这正是 GridFS 的全部数据结构。GridFS 本质是逻辑约定，不是特殊存储引擎，所以 mongodump 对它和其他集合没有区别。只要不漏掉这两个集合，备份就是完整的。
常见错误现象：只用 --db mydb 备份，却没确认 fs.files 和 fs.chunks 是否在该库中（默认是，但可自定义前缀）；或误以为要额外指定 --collection fs.*，其实 mongodump 默认导出库内所有集合，包括这两个。
- 务必确认 GridFS 使用的集合名：默认是
fs.files和fs.chunks，但可通过bucket参数自定义，比如mybucket.files和mybucket.chunks - 若用了自定义前缀，必须显式备份对应集合：
mongodump --db mydb --collection mybucket.files --collection mybucket.chunks - 不要用
--query过滤fs.chunks，否则 chunk 缺失会导致文件恢复后损坏（mongorestore不校验 chunk 完整性）
备份时要不要加 --oplog
对 GridFS 备份加 --oplog 没有意义，除非你正在做副本集全量备份且需要时间点一致性。GridFS 文件写入本身是多文档操作（先写 fs.files，再分批写 fs.chunks），--oplog 只能捕获这些操作的顺序，不能保证原子性。更关键的是：mongodump --oplog 要求源为副本集，且会额外读取 oplog 集合，增加负载，而 GridFS 场景下往往数据量大、IO 敏感。
- 如果只是单次迁移或灾备，跳过
--oplog更快更轻量 - 如果必须保证备份时刻所有 GridFS 文件都“已提交”，应在备份前暂停写入，或从 secondary 节点备份（避免影响主节点性能）
-
--oplog对mongorestore恢复无直接帮助——它只用于配合mongorestore --oplogReplay做增量回放，而 GridFS 不支持该模式
mongorestore 恢复 GridFS 数据的关键参数
mongorestore 恢复 GridFS 时，最常踩的坑是忽略集合名映射和索引重建。它不会自动创建 fs.files 和 fs.chunks 上必需的索引，而缺失索引会导致后续文件查询极慢甚至超时。
- 恢复前手动建好索引（必须）：
db.fs.files.createIndex({ "filename": 1, "uploadDate": 1 })<br>db.fs.chunks.createIndex({ "files_id": 1, "n": 1 }, { unique: true }) - 若备份时用了自定义 bucket 名（如
mybucket），恢复后需用mongofiles或驱动指定 bucket，否则应用找不到文件 - 慎用
--drop：它会清空整个目标库，而不仅仅是fs.*集合；如果库中还有业务集合，会一并丢失 - 大文件备份恢复耗时长，建议加
--numParallelCollections 4并行导入（默认为 1），但注意内存占用会上升
备份体积大、速度慢怎么办
GridFS 单个大文件会被拆成多个 255KB 的 chunk，默认每个 chunk 是独立文档，导致 mongodump 要处理海量小文档，效率远低于普通集合。这不是 bug，是设计使然。
- 优先用
--archive+--gzip：减少磁盘 IO 和临时文件膨胀，比目录模式快 30%~50% - 避免
--out目录模式备份 GridFS，尤其当总 chunk 数超千万时，文件系统遍历开销巨大 - 如果只是迁移，考虑跳过
mongodump/mongorestore，改用mongodump --archive --gzip | ssh target mongorestore --archive --gzip直接管道传输，省去中间落盘 - 真正超大规模（TB 级 GridFS）应转向物理快照或云备份，
mongodump的逻辑扫描瓶颈无法靠参数绕过
fs.chunks 上的复合唯一索引。
