不能。mongodump默认不备份gridfs，因文件数据分散在fs.files和fs.chunks两个集合中，必须显式指定--collection参数；自定义前缀、--db、--forcetablescan等选项也必须正确配置，否则导致备份缺失或失败。
mongodump 默认不备份 GridFS，因为 fs.files 和 fs.chunks 被视为内部集合，必须显式指定才能导出。直接执行 mongodump --db myapp 后检查 dump 目录，你会发现里面根本没有 fs.files.bson 或 fs.chunks.bson —— 文件“凭空消失”，但 db.getCollectionNames() 里明明能看到它们。
必须用 --collection 显式列出两个集合
GridFS 数据实际存在两个关联集合：fs.files（存元数据）和 fs.chunks（存二进制块），缺一不可。只导出其中一个会导致 restore 后文件无法读取。
- 默认前缀（
fs）：加两次--collection，顺序无关，但建议先files后chunks - 自定义前缀（如
reportbucket）：必须写成--collection reportbucket.files --collection reportbucket.chunks，不能只写前缀或用通配符 - 不加
--db会去 dumpadmin或local库，务必确认当前连接的数据库名是否正确
--forceTableScan 不是可选项，而是 fs.chunks 的救命开关
fs.chunks 通常没有有效索引、文档量极大，mongodump 默认用 cursor 分批读取，容易触发 cursor not found 或超时中断，尤其在旧版 MongoDB（如 3.6）上更常见。
- 加上
--forceTableScan强制全表扫描，绕过游标机制，避免中断 - 该参数对
fs.files影响不大，但加了也无害；对fs.chunks是刚需 - 若备份中途报错
Failed: error reading collection: EOF或卡在某个百分比不动，基本就是没加这个参数
别信 mongofiles 能当备份用
mongofiles 是调试/提取单个文件的工具，不是备份方案。它按文件名查 fs.files.filename，但 GridFS 允许重名（靠 _id 区分），且导出过程不原子——边 dump 边写入就可能漏 chunk。
-
mongofiles -r get "report.pdf"返回空？很可能是大小写或 URL 编码不一致（GridFS 存原始 UTF-8 名，shell 可能转义） - 导出的文件
file report.pdf显示 “data” 而非 “PDF document”？说明 chunk 片段没对齐，已损坏 - 真要按名取文件做验证，应该用驱动脚本：先查
fs.files得到_id，再按files_id查fs.chunks，而不是依赖mongofiles
fs.files 和 fs.chunks 可能在 dump 过程中不同步。哪怕加了 --forceTableScan，也不能替代停写或加库级读锁。这点在生产环境迁移或灾备演练时，常被当成“小概率事件”跳过，结果 restore 后发现部分大文件打不开。
