On this page本页内容
When deploying MongoDB in production, you should have a strategy for capturing and restoring backups in the case of data loss events.在生产环境中部署MongoDB时，您应该有一个在发生数据丢失事件时捕获和恢复备份的策略。
MongoDB Atlas, the hosted MongoDB service option in the cloud, offers two fully-managed methods for backups:云上托管的MongoDB服务选项MongoDB Atlas提供了两种完全受管理的备份方法：
Cloud Backups云备份, which utilize the native snapshot functionality of the deployment's cloud service provider to offer robust backup options. ，它利用部署的云服务提供商的本机快照功能提供强大的备份选项。Cloud Backups provide:云备份提供：
MongoDB Cloud Manager is a hosted back up, monitoring, and automation service for MongoDB. MongoDB Cloud Manager是MongoDB的托管备份、监控和自动化服务。MongoDB Cloud Manager云管理器 supports backing up and restoring MongoDB replica sets and sharded clusters from a graphical user interface.支持从图形用户界面备份和恢复MongoDB副本集和分片群集。
The MongoDB Cloud Manager supports the backing up and restoring of MongoDB deployments.MongoDB Cloud Manager支持备份和恢复MongoDB部署。
MongoDB Cloud Manager continually backs up MongoDB replica sets and sharded clusters by reading the oplog data from your MongoDB deployment. MongoDB Cloud Manager通过从MongoDB部署中读取oplog数据，持续备份MongoDB副本集和分片集群。MongoDB Cloud Manager creates snapshots of your data at set intervals, and can also offer point-in-time recovery of MongoDB replica sets and sharded clusters.MongoDB Cloud Manager以设定的时间间隔创建数据快照，还可以提供MongoDB副本集和分片集群的时间点恢复。
Sharded cluster snapshots are difficult to achieve with other MongoDB backup methods.使用其他MongoDB备份方法很难实现分片群集快照。
To get started with MongoDB Cloud Manager Backup, sign up for MongoDB Cloud Manager. 要开始使用MongoDB Cloud Manager备份，请注册MongoDB Cloud Manager。For documentation on MongoDB Cloud Manager, see the MongoDB Cloud Manager documentation.有关MongoDB Cloud Manager的文档，请参阅MongoDB Cloud Manager文档。
With Ops Manager, MongoDB subscribers can install and run the same core software that powers MongoDB Cloud Manager on their own infrastructure. 有了Ops管理器，MongoDB订户可以在自己的基础设施上安装和运行支持MongoDB Cloud Manager的核心软件。Ops Manager is an on-premise solution that has similar functionality to MongoDB Cloud Manager and is available with Enterprise Advanced subscriptions.Ops管理器是一个内部解决方案，具有与MongoDB Cloud Manager类似的功能，可用于企业高级订阅。
For more information about Ops Manager, see the MongoDB Enterprise Advanced page and the Ops Manager Manual.有关Ops Manager的更多信息，请参阅MongoDB Enterprise Advanced页面和Ops Manager手册。
For encrypted storage engines that use 对于使用AES256-GCM encryption mode, AES256-GCM requires that every process use a unique counter block value with the key.AES256-GCM加密模式的加密存储引擎，AES256-GCM要求每个进程对密钥使用唯一的计数器块值。
For encrypted storage engine configured with 对于配置了AES256-GCM cipher:AES256-GCM密码的加密存储引擎：
mongod is running), MongoDB can detect "dirty" keys on startup and automatically rollover the database key to avoid IV (Initialization Vector) reuse.mongod正在运行）获取的文件进行恢复，MongoDB可以在启动时检测到“脏”键，并自动滚动数据库键以避免IV（初始化向量）重用。However, if you restore from files taken via "cold" backup (i.e. the 但是，如果您从通过“冷”备份（即mongod is not running), MongoDB cannot detect "dirty" keys on startup, and reuse of IV voids confidentiality and integrity guarantees.mongod未运行）获取的文件进行恢复，MongoDB在启动时无法检测到“脏”密钥，并且重复使用IV会导致机密性和完整性保证失效。
Starting in 4.2, to avoid the reuse of the keys after restoring from a cold filesystem snapshot, MongoDB adds a new command-line option 从4.2开始，为了避免在从冷文件系统快照恢复后重用密钥，MongoDB添加了一个新的命令行选项——--eseDatabaseKeyRollover. --eseDatabaseKeyRollover。When started with the 当使用--eseDatabaseKeyRollover option, the mongod instance rolls over the database keys configured with AES256-GCM cipher and exits.--eseDatabaseKeyRollover选项启动时，mongod实例将滚动使用AES256-GCM密码配置的数据库密钥并退出。
AES256-GCM encryption mode, do not make copies of your data files or restore from filesystem snapshots ("hot" or "cold").AES256-GCM加密模式，请勿复制数据文件或从文件系统快照进行恢复（“热”或“冷”）。You can create a backup of a MongoDB deployment by making a copy of MongoDB's underlying data files.您可以通过复制MongoDB的底层数据文件来创建MongoDB部署的备份。
If the volume where MongoDB stores its data files supports point-in-time snapshots, you can use these snapshots to create backups of a MongoDB system at an exact moment in time. 如果MongoDB存储其数据文件的卷支持时间点快照，则可以使用这些快照在某一时刻创建MongoDB系统的备份。File system snapshots are an operating system volume manager feature, and are not specific to MongoDB. 文件系统快照是操作系统卷管理器的一项功能，并不特定于MongoDB。With file system snapshots, the operating system takes a snapshot of the volume to use as a baseline for data backup. 对于文件系统快照，操作系统会获取卷的快照，用作数据备份的基准。The mechanics of snapshots depend on the underlying storage system. 快照的机制取决于底层存储系统。For example, on Linux, the Logical Volume Manager (LVM) can create snapshots. 例如，在Linux上，逻辑卷管理器（LVM）可以创建快照。Similarly, Amazon’s EBS storage system for EC2 supports snapshots.类似地，亚马逊EC2的EBS存储系统也支持快照。
To get a correct snapshot of a running 要获得正在运行的mongod process, you must have journaling enabled and the journal must reside on the same logical volume as the other MongoDB data files. mongod进程的正确快照，必须启用日志记录，并且日志必须与其他MongoDB数据文件位于同一逻辑卷上。Without journaling enabled, there is no guarantee that the snapshot will be consistent or valid.如果未启用日志记录，则无法保证快照的一致性或有效性。
To get a consistent snapshot of a sharded cluster, you must disable the balancer and capture a snapshot from every shard as well as a config server at approximately the same moment in time.要获得分片集群的一致快照，必须禁用均衡器，并在大约相同的时间从每个分片以及配置服务器捕获快照。
For more information, see the Back Up and Restore with Filesystem Snapshots and Back Up a Sharded Cluster with File System Snapshots for complete instructions on using LVM to create snapshots.有关更多信息，请参阅使用文件系统快照备份和恢复以及使用文件系统快照备份分片群集，以获取有关使用LVM创建快照的完整说明。
cp or rsynccp或rsync备份If your storage system does not support snapshots, you can copy the files directly using 如果存储系统不支持快照，可以使用cp, rsync, or a similar tool. cp、rsync或类似工具直接复制文件。Since copying multiple files is not an atomic operation, you must stop all writes to the 由于复制多个文件不是一个原子操作，因此必须在复制文件之前停止对mongod before copying the files. mongod的所有写入。Otherwise, you will copy the files in an invalid state.否则，您将以无效状态复制文件。
Backups produced by copying the underlying data do not support point in time recovery for replica sets and are difficult to manage for larger sharded clusters. 通过复制基础数据生成的备份不支持副本集的时间点恢复，并且对于更大的分片群集，很难进行管理。Additionally, these backups are larger because they include the indexes and duplicate underlying storage padding and fragmentation. 此外，这些备份更大，因为它们包含索引和重复的底层存储填充和分片。mongodump, by contrast, creates smaller backups.mongodump创建的备份更小。
mongodumpmongodump备份mongodump reads data from a MongoDB database and creates high fidelity BSON files which the mongorestore tool can use to populate a MongoDB database. mongodump从MongoDB数据库读取数据，并创建高保真的BSON文件，mongorestore工具可以使用这些文件填充MongoDB数据库。mongodump and mongorestore are simple and efficient tools for backing up and restoring small MongoDB deployments, but are not ideal for capturing backups of larger systems.mongodump和mongorestore是备份和恢复小型MongoDB部署的简单而高效的工具，但对于捕获大型系统的备份并不理想。
mongodump and mongorestore operate against a running mongod process, and can manipulate the underlying data files directly. mongodump和mongorestore针对正在运行的mongod进程进行操作，可以直接操作底层数据文件。By default, 默认情况下，mongodump does not capture the contents of the local database.mongodump不会捕获本地数据库的内容。
mongodump only captures the documents in the database. 只捕获数据库中的文档。The resulting backup is space efficient, but 生成的备份节省空间，但mongorestore or mongod must rebuild the indexes after restoring data.mongorestore或mongod必须在恢复数据后重建索引。
When connected to a MongoDB instance, 当连接到MongoDB实例时，mongodump can adversely affect mongod performance. mongodump可能会对mongod性能产生负面影响。If your data is larger than system memory, the queries will push the working set out of memory, causing page faults.如果您的数据大于系统内存，则查询将使工作组内存不足，从而导致页面错误。
Applications can continue to modify data while 当mongodump captures the output. mongodump捕获输出时，应用程序可以继续修改数据。For replica sets, 对于副本集，mongodump provides the --oplog option to include in its output oplog entries that occur during the mongodump operation. mongodump提供了--oplog选项，以在其输出中包含mongodump操作期间出现的oplog条目。This allows the corresponding 这允许相应的mongorestore operation to replay the captured oplog. mongorestore操作重播捕获的oplog。To restore a backup created with 要恢复使用--oplog, use mongorestore with the --oplogReplay option.--oplog创建的备份，请使用带有--oplogReplay选项的mongorestore。
However, for replica sets, consider MongoDB Cloud Manager or Ops Manager.但是，对于副本集，请考虑MongoDB Cloud Manager或Ops Manager。
mongodump and mongorestorecannot be part of a backup strategy for 4.2+ sharded clusters that have sharded transactions in progress, as backups created with mongodump do not maintain the atomicity guarantees of transactions across shards.对于正在进行分片事务的4.2+分片集群，mongodump和mongorestore不能作为备份策略的一部分，因为使用mongodump创建的备份无法维持跨分片事务的原子性保证。
For 4.2+ sharded clusters with in-progress sharded transactions, use one of the following coordinated backup and restore processes which do maintain the atomicity guarantees of transactions across shards:对于具有进行中分片事务的4.2+分片群集，请使用以下协调的备份和恢复过程之一，这些过程确实维护了跨分片事务的原子性保证：
See Back Up and Restore with MongoDB Tools and Back Up a Sharded Cluster with Database Dumps for more information.有关更多信息，请参阅使用MongoDB工具备份和恢复，以及使用数据库转储备份分片集群。