mongodump 默认不备份 GridFS 的 fs.files 和 fs.chunks 集合，因其将 fs. 开头集合视作内部结构而跳过；必须显式指定 --collection fs.files --collection fs.chunks 才能完整备份，缺一不可。
mongodump 默认不备份 GridFS 的 fs.chunks 和 fs.files 集合，除非你显式指定它们——这是最常被忽略的根源。
mongodump 不自动包含 GridFS 集合
GridFS 不是“特殊存储”，它只是两个普通集合：fs.files 和 fs.chunks。但 mongodump 默认行为是：只 dump 当前数据库下「用户创建的集合」，而把以 fs. 开头的集合当作内部结构跳过（类似 system.*）。
- 执行
mongodump --db mydb后检查输出目录，你会发现里面没有fs.files.bson或fs.chunks.bson - 即使你用
db.fs.files.countDocuments({})确认有 10 万文件，dump 出来的备份里仍是空的 - 恢复时
mongorestore也不会报错，因为它根本没看到要还原的集合
必须手动指定 GridFS 集合才能备份
正确做法是把这两个集合加进命令行参数，否则备份就是残缺的：
- 用
mongodump --db mydb --collection fs.files --collection fs.chunks -o /backup/ - 如果数据库启用了认证，务必带上
--username、--password和--authenticationDatabase - 注意：不能只 dump
fs.files而漏掉fs.chunks——文件元数据存在前者，二进制块存在后者，缺一不可 - 若用
--gzip，确保 mongodump 版本 ≥ 4.2（旧版本 gzip 支持不完整，可能损坏 chunk 数据）
备份后验证 GridFS 是否真被包含
别依赖“命令没报错”就认为成功。实际检查输出目录结构和内容：
- 进入
/backup/mydb/，确认存在fs.files.bson和fs.chunks.bson两个文件 - 用
ls -lh看文件大小——如果都只有几 KB，大概率是空集合或 dump 失败 - 临时建一个测试库，插入一个 1MB 文件，再跑一遍带
--collection的 dump，对比输出体积是否合理 - 更稳妥的方式：用
mongorestore --dryRun（MongoDB 6.0+）预检还原逻辑，看它是否识别出这两个集合
真正容易被忽略的是：GridFS 文件数量多、chunk 文档小（默认 256KB），导致 fs.chunks 集合可能有数百万文档——mongodump 在这种场景下容易因内存或超时中断，且默认不打印 chunk 级进度。一旦中断，你拿到的就是半截备份，但表面看起来“一切正常”。
