mongodump默认不备份gridfs因fs.files和fs.chunks被归类为内部集合，需显式指定-c参数导出；恢复时须注意--drop影响范围并校验chunks与files数量匹配。
mongodump 和 mongorestore 能直接备份恢复 GridFS 文件，但必须明确指定 fs.files 和 fs.chunks 集合，否则默认跳过——这是绝大多数人备份后发现文件“丢了”的根本原因。
为什么 mongodump 默认不备份 GridFS？
GridFS 实际由两个集合组成：fs.files（元数据）和 fs.chunks（二进制块），它们不属于用户显式创建的业务集合，mongodump 默认只导出“非系统集合”，而 fs.* 被归类为内部命名空间。不加干预时，备份目录里根本不会出现这两个集合。
正确备份 GridFS 的 3 种方式
必须显式告诉 mongodump 要导出哪些集合：
- 备份整个数据库（含所有集合，包括
fs.files和fs.chunks）：mongodump -d mydb -o /backup - 只备份 GridFS 相关集合（更精准，避免冗余）：
mongodump -d mydb -c fs.files -c fs.chunks -o /backup - 如果使用了自定义 bucket 名（如
attachments），对应集合是attachments.files和attachments.chunks，需替换名称：mongodump -d mydb -c attachments.files -c attachments.chunks -o /backup
⚠️ 注意：-c 参数不能和 -d 分开写成多行；多个 -c 必须在同一命令中连续出现。
恢复时顺序和 --drop 的影响
mongorestore 恢复 fs.* 集合时，顺序无关紧要（驱动会自动处理依赖），但有两点极易出错：
- 恢复前未清空目标库中的同名集合，会导致重复插入相同文件 ID，引发
E11000 duplicate key错误 -
--drop会删掉整个目标数据库，不只是fs.*集合；若只想清理 GridFS 数据，应手动执行：db.fs.files.deleteMany({})和db.fs.chunks.deleteMany({}) - 恢复命令示例（推荐加
--noIndexRestore避免重建索引卡住）：mongorestore -d mydb --noIndexRestore /backup/mydb
验证备份是否完整
仅检查 fs.files 文档数不够，必须确认 fs.chunks 块数量与文件总数匹配：
- 查文件总数：
db.fs.files.countDocuments({}) - 查总块数：
db.fs.chunks.countDocuments({}) - 查某文件实际块数：
db.fs.chunks.countDocuments({files_id: ObjectId("...")})，应等于该文件大小 ÷ 256KB 向上取整
如果 fs.chunks 缺失或损坏，mongorestore 不报错，但后续用 openDownloadStreamByName 读取时会静默失败或返回截断内容——这个坑最隐蔽，必须主动校验。
