MongoDB Backup MethodsMongoDB备份方法
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时，您应该有一个在发生数据丢失事件时捕获和恢复备份的策略。
Back Up with Atlas使用Atlas备份
MongoDB Atlas, the hosted MongoDB service option in the cloud, offers two fully-managed methods for backups:MongoDB Atlas是云中托管的MongoDB服务选项，提供了两种完全托管的备份方法：
Cloud Backups云备份, which utilize the native snapshot functionality of the deployment's cloud service provider to offer robust backup options. Cloud Backups provide:，利用部署云服务提供商的本机快照功能提供强大的备份选项。云备份提供：On-demand snapshots随需应变快照, which allow you to trigger an immediate snapshot of your deployment at a given point in time.，允许您在给定的时间点触发部署的即时快照。Continuous Cloud Backups连续云备份, which allow you to schedule recurring backups for your deployment.，允许您为部署安排定期备份。
Legacy Backups旧备份(Deprecated)（已弃用）, which take incremental backups of data in your deployment.，对部署中的数据进行增量备份。
Back Up with MongoDB Cloud Manager or Ops Manager使用MongoDB云管理器或Ops管理器进行备份
MongoDB Cloud Manager is a hosted back up, monitoring, and automation service for MongoDB. MongoDB Cloud Manager是MongoDB的托管备份、监控和自动化服务。MongoDB Cloud ManagerMongoDB Cloud Manager
supports backing up and restoring MongoDB replica sets and sharded clusters from a graphical user interface.支持从图形用户界面备份和恢复MongoDB副本集和分片集群。
MongoDB Cloud ManagerMongoDB云管理器
The MongoDB Cloud ManagerMongoDB云管理器 supports the backing up and restoring of MongoDB deployments.支持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部署中的操作日志数据，不断备份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云管理器备份，请注册MongoDB Cloud Manager. For documentation on MongoDB Cloud Manager, see the MongoDB Cloud Manager documentation.。有关MongoDB云管理器的文档，请参阅MongoDB Cloud Manager文档。
Ops Manager
With Ops Manager, MongoDB subscribers can install and run the same core software that powers MongoDB Cloud Manager on their own infrastructure. 使用Ops Manager，MongoDB用户可以在自己的基础设施上安装和运行与MongoDB云管理器相同的核心软件。Ops Manager is an on-premise solution that has similar functionality to MongoDB Cloud Manager and is available with Enterprise Advanced subscriptions.Ops Manager是一个内部部署解决方案，具有与MongoDB Cloud Manager类似的功能，可通过Enterprise Advanced订阅获得。
For more information about Ops Manager, see the MongoDB Enterprise Advanced有关Ops Manager的更多信息，请参阅MongoDB Enterprise Advanced page and the Ops Manager Manual.页面和Ops Manager手册。
Back Up by Copying Underlying Data Files通过复制基础数据文件进行备份
Considerations for Encrypted Storage Engines using AES256-GCM使用AES256-GCM的加密存储引擎的注意事项
For encrypted storage engines that use 对于使用AES256-GCM加密模式的加密存储引擎，AES256-GCM要求每个进程使用唯一的计数器块值和键。AES256-GCM encryption mode, AES256-GCM requires that every process use a unique counter block value with the key.
For encrypted storage engine configured with 对于配置有AES256-GCM cipher:AES256-GCM密码的加密存储引擎：
Restoring from Hot Backup从热备份恢复Starting in 4.2, if you restore from files taken via "hot" backup (i.e. the从4.2开始，如果你从通过“热”备份（即mongodis running), MongoDB can detect "dirty" keys on startup and automatically rollover the database key to avoid IV (Initialization Vector) reuse.mongod正在运行）获取的文件中恢复，MongoDB可以在启动时检测到“脏”键，并自动滚动数据库键，以避免IV（初始化向量）重用。Restoring from Cold Backup从冷备份恢复-
However, if you restore from files taken via "cold" backup (i.e. the然而，如果您从通过“冷”备份获取的文件中恢复（即mongodis 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当使用--eseDatabaseKeyRolloveroption, themongodinstance rolls over the database keys configured withAES256-GCMcipher and exits.--eseDatabaseKeyRollover选项启动时，mongod实例会滚动使用AES256-GCM密码配置的数据库键并退出。
In general, if using filesystem based backups for MongoDB Enterprise 4.2+, use the "hot" backup feature, if possible.通常，如果MongoDB Enterprise 4.2+使用基于文件系统的备份，请尽可能使用“热”备份功能。For MongoDB Enterprise versions 4.0 and earlier, if you use对于MongoDB Enterprise 4.0及更早版本，如果使用AES256-GCMencryption mode, do not make copies of your data files or restore from filesystem snapshots ("hot" or "cold").AES256-GCM加密模式，请不要复制数据文件或从文件系统快照（“热”或“冷”）进行恢复。
Back Up with Filesystem Snapshots使用文件系统快照进行备份
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. Without journaling enabled, there is no guarantee that the snapshot will be consistent or valid.mongod进程的正确快照，必须启用日志记录，并且日志必须与其他MongoDB数据文件位于同一逻辑卷上。如果不启用日志记录，则无法保证快照的一致性或有效性。
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创建快照的完整说明。
Back Up with cp or rsync使用cp或rsync进行备份
cp or rsyncIf 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. Otherwise, you will copy the files in an invalid state.mongod的所有写入。否则，您将以无效状态复制文件。
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创建的备份较小。
Back Up with mongodump使用mongodump备份
mongodumpmongodump reads data from a MongoDB database and creates high fidelity BSON files which the 从MongoDB数据库读取数据并创建高保真BSON文件，mongorestore tool can use to populate a MongoDB database. 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不会捕获local数据库的内容。
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. If your data is larger than system memory, the queries will push the working set out of memory, causing page faults.mongodump可能会对mongod性能产生不利影响。如果数据大于系统内存，则查询会将工作集挤出内存，从而导致页面错误。
Applications can continue to modify data while 当mongodump captures the output. For replica sets, mongodump provides the --oplog option to include in its output oplog entries that occur during the mongodump operation. mongodump捕获输出时，应用程序可以继续修改数据。对于副本集，mongodump提供了--oplog选项，以便在其输出oplog中包含mongodump操作期间出现的条目。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创建的备份，请将mongorestore与--oplogReplay选项一起使用。
However, for replica sets, consider MongoDB Cloud Manager or Ops Manager.但是，对于副本集，请考虑MongoDB Cloud Manager或Ops Manager。
mongodump and mongorestore cannot 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.mongodump和mongorestore不能作为4.2+正在进行分片事务的分片集群的备份策略的一部分，因为使用mongorestore创建的备份不能维护跨分片事务原子性的保证。
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工具备份和恢复以及使用数据库转储备份分片集群。