On this page本页内容
This document describes a procedure for creating backups of MongoDB systems using system-level tools, such as LVM or storage appliance, as well as the corresponding restoration strategies.本文档描述了使用系统级工具（如LVM或storage appliance）创建MongoDB系统备份的过程，以及相应的恢复策略。
These filesystem snapshots, or "block-level" backup methods, use system level tools to create copies of the device that holds MongoDB's data files. 这些文件系统快照或“块级”备份方法使用系统级工具创建保存MongoDB数据文件的设备的副本。These methods complete quickly and work reliably, but require additional system configuration outside of MongoDB.这些方法完成得很快，工作可靠，但需要在MongoDB之外进行额外的系统配置。
Snapshots work by creating pointers between the live data and a special snapshot volume. 快照通过在实时数据和特殊快照卷之间创建游标来工作。These pointers are theoretically equivalent to "hard links." 这些游标在理论上相当于“硬链接”。As the working data diverges from the snapshot, the snapshot process uses a copy-on-write strategy. 当工作数据与快照不同时，快照进程将使用写时拷贝策略。As a result, the snapshot only stores modified data.因此，快照只存储修改后的数据。
After making the snapshot, you mount the snapshot image on your file system and copy data from the snapshot. 创建快照后，将快照映像装载到文件系统上，并从快照中复制数据。The resulting backup contains a full copy of all data.生成的备份包含所有数据的完整副本。
MongoDB 3.2 added support for volume-level back up of MongoDB instances using the WiredTiger storage engine when the MongoDB instance's data files and journal files reside on separate volumes. 当MongoDB实例的数据文件和日志文件位于不同的卷上时，MongoDB 3.2增加了对使用WiredTiger存储引擎对MongoDB实例进行卷级备份的支持。However, to create a coherent backup, the database must be locked and all writes to the database must be suspended during the backup process.但是，要创建一致的备份，必须在备份过程中锁定数据库，并暂停对数据库的所有写入。
Prior to MongoDB 3.2, creating volume-level backups of MongoDB instances using WiredTiger required that the data files and journal reside on the same volume.在MongoDB 3.2之前，使用WiredTiger创建MongoDB实例的卷级备份要求数据文件和日志位于同一卷上。
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加密模式，请勿复制数据文件或从文件系统快照进行恢复（“热”或“冷”）。The database must be valid when the snapshot takes place. 快照发生时，数据库必须有效。This means that all writes accepted by the database need to be fully written to disk: either to the journal or to data files.这意味着数据库接受的所有写入操作都需要完全写入磁盘：要么写入日志，要么写入数据文件。
If there are writes that are not on disk when the backup occurs, the backup will not reflect these changes.如果备份时磁盘上没有写操作，备份将不会反映这些更改。
For the WiredTiger storage engine, the data files reflect a consistent state as of the last checkpoint. 对于WiredTiger存储引擎，数据文件反映了截至最后一个检查点的一致状态。Checkpoints occur with every 2 GB of data or every minute.每2 GB数据或每分钟都会出现检查点。
Snapshots create an image of an entire disk image. 快照创建整个磁盘映像的映像。Unless you need to back up your entire system, consider isolating your MongoDB data files, journal (if applicable), and configuration on one logical disk that doesn't contain any other data.除非需要备份整个系统，否则请考虑在一个不包含任何其他数据的逻辑磁盘上隔离MongoDB数据文件、日志（如果适用）和配置。
Alternately, store all MongoDB data files on a dedicated device so that you can make backups without duplicating extraneous data.或者，将所有MongoDB数据文件存储在专用设备上，以便在不复制无关数据的情况下进行备份。
Ensure that you copy data from snapshots onto other systems. 确保将数据从快照复制到其他系统。This ensures that data is safe from site failures.这确保了数据不会因站点故障而受到影响。
This tutorial does not include procedures for incremental backups. 本教程不包括增量备份的过程。Although different snapshot methods provide different features, the LVM method outlined below does not provide any capacity for capturing incremental backups.虽然不同的快照方法提供了不同的功能，但下面概述的LVM方法不提供任何捕获增量备份的能力。
If your 如果mongod instance has journaling enabled, then you can use any kind of file system or volume/block level snapshot tool to create backups.mongod实例已启用日志记录，则可以使用任何类型的文件系统或卷/块级快照工具来创建备份。
If you manage your own infrastructure on a Linux-based system, configure your system with LVM to provide your disk packages and provide snapshot capability. 如果在基于Linux的系统上管理自己的基础设施，请使用LVM配置系统，以提供磁盘包和快照功能。You can also use LVM-based setups within a cloud/virtualized environment.您还可以在云/虚拟化环境中使用基于LVM的设置。
If your deployment depends on Amazon's Elastic Block Storage (EBS) with RAID configured within your instance, it is impossible to get a consistent state across all disks using the platform's snapshot tool. 如果您的部署依赖于Amazon的弹性块存储（EBS），并且在实例中配置了RAID，那么使用平台的快照工具不可能在所有磁盘上获得一致的状态。As an alternative, you can do one of the following:作为替代方案，您可以执行以下操作之一：
Flush all writes to disk and create a write lock to ensure consistent state during the backup process.刷新对磁盘的所有写入，并创建写入锁，以确保备份过程中的状态一致。
If you choose this option see Back up Instances with Journal Files on Separate Volume or without Journaling.如果选择此选项，请参阅备份实例，其中日志文件位于单独的卷上或不记录日志。
Configure LVM to run and hold your MongoDB data files on top of the RAID within your system.将LVM配置为在系统中的RAID之上运行并保存MongoDB数据文件。
If you choose this option, perform the LVM backup operation described in Create a Snapshot.如果选择此选项，请执行创建快照中描述的LVM备份操作。
This section provides an overview of a simple backup process using LVM on a Linux system. 本节概述了在Linux系统上使用LVM的简单备份过程。While the tools, commands, and paths may be (slightly) different on your system the following steps provide a high level overview of the backup operation.虽然系统上的工具、命令和路径可能（略有）不同，但以下步骤提供了备份操作的高级概述。
Only use the following procedure as a guideline for a backup system and infrastructure. 以下步骤仅作为备份系统和基础架构的指南。Production backup systems must consider a number of application specific requirements and factors unique to specific environments.生产备份系统必须考虑许多特定于应用程序的要求和特定环境特有的因素。
Changed in version 3.2.在版本3.2中更改。
To create a snapshot with LVM, issue a command as root in the following format:要使用LVM创建快照，请以root用户身份以以下格式发出命令：
lvcreate --size 100M --snapshot --name mdb-snap01 /dev/vg0/mongodb
This command creates an LVM snapshot (with the 此命令创建vg0卷组中--snapshot option) named mdb-snap01 of the mongodb volume in the vg0 volume group.mongodb卷的名为mdb-snap01的LVM快照（使用--snapshot选项）。
This example creates a snapshot named 本例创建了一个名为mdb-snap01 located at /dev/vg0/mdb-snap01. mdb-snap01的快照，位于/dev/vg0/mdb-snap01。The location and paths to your systems volume groups and devices may vary slightly depending on your operating system's LVM configuration.根据操作系统的LVM配置，系统卷组和设备的位置和路径可能略有不同。
The snapshot has a cap of at 100 megabytes, because of the parameter 由于参数为--size 100M. --size 100M，所以快照的上限为100MB。This size does not reflect the total amount of the data on the disk, but rather the quantity of differences between the current state of 此大小并不反映磁盘上的数据总量，而是反映/dev/vg0/mongodb and the creation of the snapshot (i.e. /dev/vg0/mdb-snap01.)/dev/vg0/mongodb的当前状态与快照创建（即/dev/vg0/mdb-snap01）之间的差异量。
Ensure that you create snapshots with enough space to account for data growth, particularly for the period of time that it takes to copy data out of the system or to a temporary image.确保创建快照时有足够的空间来考虑数据增长，尤其是在将数据从系统中复制或复制到临时映像所需的时间段内。
If your snapshot runs out of space, the snapshot image becomes unusable. Discard this logical volume and create another.如果快照空间不足，快照映像将无法使用。放弃此逻辑卷并创建另一个。
The snapshot will exist when the command returns. 当命令返回时，快照将存在。You can restore directly from the snapshot at any time or by creating a new logical volume and restoring from this snapshot to the alternate image.您可以随时直接从快照恢复，也可以通过创建新的逻辑卷并从此快照恢复到备用映像来恢复。
While snapshots are great for creating high quality backups quickly, they are not ideal as a format for storing backup data. 虽然快照对于快速创建高质量备份非常有用，但它们并不是存储备份数据的理想格式。Snapshots typically depend and reside on the same storage infrastructure as the original disk images. 快照通常与原始磁盘映像依赖并驻留在同一存储基础结构上。Therefore, it's crucial that you archive these snapshots and store them elsewhere.因此，将这些快照存档并存储到其他地方至关重要。
After creating a snapshot, mount the snapshot and copy the data to separate storage. 创建快照后，装载快照并将数据复制到单独的存储器中。Your system might try to compress the backup images as you move them offline. 您的系统可能会在脱机移动备份映像时尝试压缩它们。Alternatively, take a block level copy of the snapshot image, such as with the following procedure:或者，通过以下步骤获取快照图像的块级副本：
umount /dev/vg0/mdb-snap01
dd if=/dev/vg0/mdb-snap01 | gzip > mdb-snap01.gz
The above command sequence does the following:上述命令序列执行以下操作：
/dev/vg0/mdb-snap01 device is not mounted. /dev/vg0/mdb-snap01设备。Performs a block level copy of the entire snapshot image using the 使用dd command and compresses the result in a gzipped file in the current working directory.dd命令执行整个快照映像的块级复制，并将结果压缩到当前工作目录中的gzip文件中。
This command will create a large 此命令将在当前工作目录中创建一个大的gz file in your current working directory. gz文件。Make sure that you run this command in a file system that has enough free space.确保在有足够可用空间的文件系统中运行此命令。
To restore a snapshot created with LVM, issue the following sequence of commands:要恢复使用LVM创建的快照，请发出以下命令序列：
lvcreate --size 1G --name mdb-new vg0 gzip -d -c mdb-snap01.gz | dd of=/dev/vg0/mdb-new mount /dev/vg0/mdb-new /srv/mongodb
The above sequence does the following:上述顺序执行以下操作：
Creates a new logical volume named 在mdb-new, in the /dev/vg0 volume group. /dev/vg0卷组中创建名为mdb-new的新逻辑卷。The path to the new device will be 新设备的路径将是/dev/vg0/mdb-new./dev/vg0/mdb-new。
This volume will have a maximum size of 1 gigabyte. 此卷的最大大小为1 GB。The original file system must have had a total size of 1 gigabyte or smaller, or else the restoration will fail.原始文件系统的总大小必须小于等于1GB，否则恢复将失败。
Change 将1G to your desired volume size.1G更改为所需的卷大小。
mdb-snap01.gz into the mdb-new disk image.mdb-snap01.gz解压并解压到mdb-new磁盘映像中。mdb-new disk image to the /srv/mongodb directory. mdb-new磁盘映像装载到/srv/mongodb目录。The restored snapshot will have a stale 还原的快照将有一个过时的mongod.lock file. mongod.lock文件。If you do not remove this file from the snapshot, and MongoDB may assume that the stale lock file indicates an unclean shutdown. 如果不从快照中删除此文件，MongoDB可能会认为陈旧的锁文件表示未经清理的关闭。If you're running with 如果在启用storage.journal.enabled enabled, and you do not use db.fsyncLock(), you do not need to remove the mongod.lock file. storage.journal.enabled的情况下运行，并且不使用dbfsyncLock()，则无需删除mongod.lock文件。If you use 如果使用db.fsyncLock() you will need to remove the lock.db.fsyncLock()，则需要移除锁。
To restore a backup without writing to a compressed 要恢复备份而不写入压缩的gz file, use the following sequence of commands:gz文件，请使用以下命令序列：
umount /dev/vg0/mdb-snap01
lvcreate --size 1G --name mdb-new vg0
dd if=/dev/vg0/mdb-snap01 of=/dev/vg0/mdb-new
mount /dev/vg0/mdb-new /srv/mongodb
New in version 3.6:3.6版中新增：
All MongoDB collections have UUIDs by default. 默认情况下，所有MongoDB集合都有UUID。When MongoDB restores collections, the restored collections retain their original UUIDs. MongoDB恢复集合时，恢复的集合将保留其原始UUID。When restoring a collection where no UUID was present, MongoDB generates a UUID for the restored collection.还原不存在UUID的集合时，MongoDB会为还原的集合生成UUID。
For more information on collection UUIDs, see Collections.有关集合UUID的更多信息，请参阅集合。
You can implement off-system backups using the combined process and SSH.您可以使用进程和SSH的组合实现非系统备份。
This sequence is identical to procedures explained above, except that it archives and compresses the backup on a remote system using SSH.这个序列与上面解释的过程相同，只是它使用SSH在远程系统上归档和压缩备份。
Consider the following procedure:考虑以下程序：
umount /dev/vg0/mdb-snap01
dd if=/dev/vg0/mdb-snap01 | ssh username@example.com gzip > /opt/backup/mdb-snap01.gz
lvcreate --size 1G --name mdb-new vg0
ssh username@example.com gzip -d -c /opt/backup/mdb-snap01.gz | dd of=/dev/vg0/mdb-new
mount /dev/vg0/mdb-new /srv/mongodb
Changed in version 3.2.在版本3.2中更改。
If your 如果mongod instance is either running without journaling or has the journal files on a separate volume, you must flush all writes to disk and lock the database to prevent writes during the backup process. mongod实例运行时没有日志记录，或者日志文件位于单独的卷上，则必须刷新对磁盘的所有写入，并锁定数据库，以防止在备份过程中写入。If you have a replica set configuration, then for your backup use a secondary which is not receiving reads (i.e. hidden member).如果您有副本集配置，那么对于备份，请使用不接收读取的辅助服务器（即隐藏成员）。
To flush writes to disk and to "lock" the database, issue the 要刷新对磁盘的写入并“锁定”数据库，请在db.fsyncLock() method in mongosh:mongosh中发出db.fsyncLock()方法：
db.fsyncLock();
To unlock the database after the snapshot has completed, use the following command in 要在快照完成后解锁数据库，请在mongosh:mongosh中使用以下命令：
db.fsyncUnlock();