警告
字段中带有 $ 前缀的数据转储和恢复冲突
从MongoDB 5.0开始，文档字段名称可以以美元字符 ( $ ) 作为前缀。 但是， mongodump和mongorestore不适用于集合选项中以美元字符为前缀的字段名称。
MongoDB扩展JSON (v 2 )无法区分类型包装器和与类型包装器同名的字段。 如果相应的BSON表示形式可能包含$前缀键，请勿使用扩展JSON格式。 DBRefs机制是该一般规则的例外。
行为
恢复到匹配的服务器版本
使用 mongorestore 加载由 mongodump 创建的数据文件时，源部署和目标部署的 MongoDB 版本必须是以下任一版本：
同一主要版本。
同一特征兼容性版本。
例如，如果转储是通过运行版本 4.4 的 MongoDB 部署创建的，那么恢复到的 MongoDB 部署也必须运行版本 4.4 或将其 FCV 设置为 4.4。
如要更改特征兼容性版本，请参阅 setFeatureCompatibilityVersion。
注意
您可以将从 mongodump 生成的 BSON 文件恢复到与源部署运行相同或更新版本的 MongoDB 部署中。然而，在较新版本的部署中恢复文件并不是升级部署的推荐方法。要了解如何升级部署，请参阅升级文档。
此保证不适用于元数据、存档或 oplog 重放文件。如果尝试使用不同的源部署版本和目标部署版本恢复这些文件，则 mongorestore 进程可能会导致故障、静默故障或元数据损坏。
此外，请务必使用与创建数据文件时所用 mongodump 版本相同的 mongorestore 版本来加载这些数据文件。实际上，使用不同版本的 mongorestore 通常可以正常工作，但如果转储格式在不同版本之间发生变化，则恢复可能会失败或错误地恢复数据。示例，如果使用 mongodump 版本 100.20.1 创建转储，则使用 mongorestore 版本 100.20.1 恢复。
注意
作为此规则的例外，您可以将从 MongoDB 9.0 部署中转储的数据恢复到 Atlas Infinite Database 集群中。您还可以将从 Atlas Infinite Database 集群转储的数据恢复到 MongoDB 9.0 部署中。
仅插入
mongorestore 可以创建新数据库或向现有数据库添加数据。 但是， mongorestore仅执行插入，不执行更新。 如果将文档恢复到现有数据库和集合，并且现有文档与要恢复的文档具有相同的_id字段值，则mongorestore不会覆盖这些文档。
文档顺序
默认， mongorestore可能会按随机顺序插入文档。 要在恢复进程保持文档顺序，请使用--maintainInsertionOrder 。
重建索引
mongorestore 会在恢复数据后重新创建 mongodump 所记录的索引。
注意
对于将 featureCompatibilityVersion ( FCV)设立为 "4.0" 或更早版本的MongoDB安装程序，如果现有文档中的索引键超过限制，创建索引时将出错。
要避免此问题，请考虑使用哈希索引或改为对计算值进行索引。 要解决恢复数据后的索引问题，您可以通过将mongod实例的failIndexKeyTooLong参数设置为 false，对目标数据库禁用默认索引键长度验证。
排除 system.profile 集合
mongorestore 不会恢复system.profile集合数据。
FIPS
mongorestore 自动创建与 配置为使用 FIPS 模式 的mongod / 的符合mongos FIPS 标准的连接。
写关注
如果在 --writeConcern 选项和 --uri 连接字符串选项中都指定了写关注，则 --writeConcern 值将覆盖 URI 字符串中指定的写关注。
时间序列集合
从 MongoDB 5.0 开始，您可以使用 mongorestore 来恢复时间序列集合。有关详细信息，请参阅恢复时间序列集合。
跨时间序列格式转换的 Oplog 重播
MongoDB 8.x 和 MongoDB 9.0 以不同的格式存储时间序列集合：
在 MongoDB 8.x 中，时间序列集合由视图和单独的
system.buckets.<collection>集合组成。从 MongoDB 9.0 开始，时间序列集合是单个集合。
当使用 setFeatureCompatibilityVersion 更改跨此边界的特征兼容性版本 (FCV)时，服务器会将每个 时间序列集合 转换为与新 FCV 匹配的格式。服务器在 oplog 中记录每次转换。
每次转换还会将桶写入的目标命名空间从 system.buckets.<collection> 更改为 <collection>。在转换之前记录的 oplog 条目与其后的集合格式不匹配。
因此，mongorestore 无法重放跨转换的 oplog 范围。将转换两侧的条目恢复为单独的范围，并在两次恢复之间更改目标部署上的特征兼容性版本：
重放在转换之前的 oplog 条目。
在转换前使用 --oplogLimit 停止重播。
更改目标部署上的特征兼容性版本。
在目标上运行 setFeatureCompatibilityVersion 以使 特征兼容性版本 发生相同方向的相同变化，从而产生转换。
目标上的特征兼容性版本更改是必需的。mongorestore 从不更改特征兼容性版本，也不会在转换过程中重写命名空间。如果目标在两次恢复中保持在同一个特征兼容性版本，则第二个范围中的条目命名的命名空间与目标上的集合格式不匹配。恢复将失败。
从 Database Tools 100.18.0 开始，mongorestore 失败，并显示命名转换的消息，因为在 --oplogReplay 期间遇到了转换。Database Tools 的早期版本会报告未知的 oplog 命令。
为避免产生无法恢复的转储，请勿在 mongodump --oplog 运行时更改特征兼容性版本。如果您使用 mongodump --db=local --collection=oplog.rs 自行捕获 oplog 并使用 --oplogFile 重播它，则 mongodump 无法检测 特征兼容性版本 更改，因此请检查您恢复的范围是否跨越了转换。
在Atlas免费版和 Flex 集群上使用 mongorestore
在免费 (M0) 和 Flex 集群上，应用以下限制：
无法在
admin数据库上运行mongorestore。默认情况下，mongorestore跳过此数据库。如果使用--db选项将目标数据库设置为admin，程序将返回错误消息。不能将以下选项与
mongorestore程序一起使用：
在 Atlas Infinite 数据库集群上使用 mongorestore
当您恢复到 Atlas Infinite 数据库 集群时，不能将以下选项与 mongorestore 程序一起使用：
无论转储来源于 MongoDB 9.0 (非 Atlas Infinite 数据库) 还是 Atlas Infinite 数据库集群，都应用此限制。
重要
mongorestore 在恢复开始之前，无法检测目标集群是否为 Atlas Infinite Database 集群。如果您对 Atlas Infinite 数据库集群使用 --oplogReplay 或 --preserveUUID，则 mongorestore 在尝试应用 oplog 时会返回错误。由于 mongorestore 在应用 oplog 之前会恢复非 oplog 数据，因此失败的 oplog 重放可能会导致恢复仅部分完成。
崩溃行为
如果 mongorestore 崩溃，可能会使系统处于不一致状态，在该状态下，只有部分数据得到恢复，而不是所有数据。崩溃后，删除所有恢复的数据，并从头开始重新运行该过程。
必需的访问权限
为了将数据还原到已启用访问控制的 MongoDB 部署中，如果数据不包括 system.profile 集合数据，且您运行 mongorestore时不包含 --oplogReplay选项，那么restore 角色可提供从备份还原数据的必要权限。
注意
如果目标集群是 MongoDB Atlas 集群，则需要 Atlas admin 角色。MongoDB Atlas 不提供单独的 restore 角色、权限或权限操作。要了解更多信息，请参阅 配置数据库用户。
如果备份数据中包含 system.profile 集合数据，或是运行带 --oplogReplay 选项的 mongorestore，则需其他特权：
| 如果备份数据包含 内置角色 |
| 要使用 仅授予必须使用 |
在备份策略中的用法
独立运行/副本集
有关作为备份和恢复策略一部分的 mongorestore 用法概述，请参阅使用 MongoDB 工具进行备份和恢复。
分片集群
要使用mongodump和mongorestore作为分分片的集群的备份策略，请参阅使用数据库转储备份自管理分片集群。
分片集群还可以使用以下协调备份和恢复进程之一，保证跨分片的原子性，同时仍然接受写入：