警告
字段中带有 $ 前缀的数据转储和恢复冲突
从MongoDB 5.0开始，文档字段名称可以以美元字符 ( $ ) 作为前缀。 但是， mongodump和mongorestore不适用于集合选项中以美元字符为前缀的字段名称。
MongoDB扩展JSON2 (v) 无法区分类型包装器和与类型包装器同名的字段。如果相应的BSON表示形式可能包含 前缀键，请勿使用扩展JSON格式。$ DBRefs 机制是该一般规则的例外。
行为
恢复到匹配的服务器版本
使用 mongorestore 加载由 mongodump 创建的数据文件时，源部署和目标部署的 MongoDB 版本必须是以下任一版本：
同一主要版本。
同一特征兼容性版本。
例如，如果转储是通过运行版本 4.4 的 MongoDB 部署创建的，那么恢复到的 MongoDB 部署也必须运行版本 4.4 或将其 FCV 设置为 4.4。
要更改特征兼容性版本，请参阅setFeatureCompatibilityVersion 。
注意
您可以将从 mongodump 生成的 BSON 文件恢复到与源部署运行相同或更新版本的 MongoDB 部署中。然而，在较新版本的部署中恢复文件并不是升级部署的推荐方法。要了解如何升级部署，请参阅升级文档。
此保证不适用于元数据、存档或 oplog 重放文件。如果尝试使用不同的源部署版本和目标部署版本恢复这些文件，则 mongorestore 进程可能会导致故障、静默故障或元数据损坏。
此外，确保加载数据文件时使用的 mongorestore 版本与创建数据文件时使用的 mongodump 版本相同。实际上，使用不同版本的 mongorestore 通常可行，但如果转储格式在版本之间发生变化，则恢复可能会失败或错误地恢复数据。示例，如果使用 mongodump 版本 100.19.1 创建转储，请使用 mongorestore 版本 100.19.1 来恢复转储。
注意
作为此规则的例外，您可以将从MongoDB 9.0部署转储到Atlas无限数据库集群的数据恢复。您还可以将从Atlas无限数据库集群转储的数据恢复到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在目标上运行 ，以在与产生转换的方向相同的方向上进行相同的FCV更改。
目标上的特征兼容性版本更改是必需的。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无限数据库集群上使用 mongorestore
恢复到Atlas无限数据库集群时，不能在 mongorestore 程序中使用以下选项：
无论转储来自MongoDB 9.0（非 Atlas 无限数据库）还是Atlas无限数据库集群，此限制均适用。
重要
mongorestore 在恢复开始之前，无法检测目标集群是否为Atlas无限数据库集群。如果您对Atlas无限数据库集群使用 --oplogReplay 或 --preserveUUID，则 mongorestore 在尝试应用oplog时会返回错误。由于 mongorestore 会在应用oplog之前恢复非 oplog 数据，因此失败的oplog重放可能会使恢复仅部分完成。
崩溃行为
如果 mongorestore 崩溃，可能会使系统处于不一致状态，在该状态下，只有部分数据得到恢复，而不是所有数据。崩溃后，删除所有恢复的数据，并从头开始重新运行该过程。
必需的访问权限
要将数据恢复到启用了访问权限控制的MongoDB 部署，如果数据不包括restore system.profile集合数据，并且您在没有 选项的情况下运行 ，则mongorestore --oplogReplay角色提供从备份恢复数据所需的特权。
注意
如果目标集群是MongoDB Atlas 群集，则需要Atlas admin 角色。 MongoDB Atlas不提供单独的restore 角色、权限或权限动作。要学习；了解更多信息，请参阅配置数据库用户。
如果备份数据包含 集合数据，或者使用system.profile 选项运行mongorestore --oplogReplay，则需要额外特权：
| 如果备份数据包括 内置角色 |
| 要使用 仅授予必须使用 |
在备份策略中的用法
独立运行/副本集
有关作为备份和恢复策略一部分的 mongorestore 用法概述，请参阅使用 MongoDB 工具进行备份和恢复。
分片集群
要使用mongodump和mongorestore作为分分片的集群的备份策略，请参阅使用数据库转储备份自管理分片集群。
分片集群还可以使用以下协调备份和恢复进程之一，保证跨分片的原子性，同时仍然接受写入：