Docs Home → MongoDB Manual

Back Up and Restore with Filesystem Snapshots使用文件系统快照进行备份和恢复

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或存储设备）创建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之外进行额外的系统配置。

Tip

See also: 另请参阅：

Snapshots Overview快照概述

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.制作快照后，将快照映像装载到文件系统上，并从快照中复制数据。生成的备份包含所有数据的完整副本。

Considerations注意事项

WiredTiger Storage EngineWiredTiger存储引擎

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实例的卷级备份需要数据文件和日志位于同一卷上。

Encrypted Storage Engine (MongoDB Enterprise Only)加密存储引擎（仅限MongoDB Enterprise）

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密码的加密存储引擎：

  • Restoring from Hot Backup从热备份恢复
    Starting in 4.2, if you restore from files taken via "hot" backup (i.e. the mongod is running), MongoDB can detect "dirty" keys on startup and automatically rollover the database key to avoid IV (Initialization Vector) reuse.从4.2开始，如果你从通过“热”备份（即mongod正在运行）获取的文件中恢复，MongoDB可以在启动时检测到“脏”键，并自动滚动数据库键，以避免IV（初始化向量）重用。
  • Restoring from Cold Backup从冷备份恢复

    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 --eseDatabaseKeyRollover. 从4.2开始，为了避免从冷文件系统快照恢复后重用键，MongoDB添加了一个新的命令行选项--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密码配置的数据库键并退出。

Tip
  • 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 AES256-GCM encryption mode, do not make copies of your data files or restore from filesystem snapshots ("hot" or "cold").对于MongoDB Enterprise 4.0及更早版本，如果使用AES256-GCM加密模式，请不要复制数据文件或从文件系统快照（“热”或“冷”）进行恢复。

Valid Database at the Time of Snapshot快照时的有效数据库

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数据或每分钟出现一次。

Entire Disk Image整个磁盘映像

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数据文件存储在专用设备上，这样您就可以在不复制无关数据的情况下进行备份。

Site Failure Precaution现场故障预防

Ensure that you copy data from snapshots onto other systems. 确保将数据从快照复制到其他系统上。This ensures that data is safe from site failures.这样可以确保数据不会发生站点故障。

No Incremental Backups无增量备份

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方法不提供任何捕获增量备份的能力。

Snapshots With Journaling带日志的快照

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的设置。

Note

Running LVM provides additional flexibility and enables the possibility of using snapshots to back up MongoDB.运行LVM提供了额外的灵活性，并允许使用快照备份MongoDB。

Snapshots with Amazon EBS in a RAID 10 ConfigurationRAID 10配置中的Amazon EBS快照

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. 如果您的部署依赖于亚马逊的弹性块存储（EBS），并且在您的实例中配置了RAID，那么使用平台的快照工具不可能在所有磁盘上获得一致的状态。As an alternative, you can do one of the following:作为替代方案，您可以执行以下操作之一：

Back Up and Restore Using LVM on Linux在Linux上使用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.虽然您的系统中的工具、命令和路径可能（略有）不同，但以下步骤提供了备份操作的高级概述。

Note

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.生产备份系统必须考虑许多特定于应用程序的要求和特定环境特有的因素。

Create a Snapshot创建快照

Changed in version 3.2.3.2版更改。Starting in MongoDB 3.2, for the purpose of volume-level backup of MongoDB instances using WiredTiger, the data files and the journal are no longer required to reside on a single volume.从MongoDB 3.2开始，为了使用WiredTiger对MongoDB实例进行卷级备份，数据文件和日志不再需要驻留在单个卷上。

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 --snapshot option) named mdb-snap01 of the mongodb volume in the vg0 volume group.此命令创建vg0卷组中mongodb卷的名为mdb-snap01的LVM快照（带有--snapshot选项）。

This example creates a snapshot named mdb-snap01 located at /dev/vg0/mdb-snap01. 此示例创建一个名为mdb-snap01的快照，该快照位于/dev/vg0/mdb-snap02。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，快照的上限为100兆字节。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）之间的差异量

Warning

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.因此，归档这些快照并将其存储在其他地方是至关重要的。

Archive a Snapshot存档快照

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:上述命令序列执行以下操作：

  • Ensures that the /dev/vg0/mdb-snap01 device is not mounted. 确保未装入/dev/vg0/mdb-snap01设备。Never take a block level copy of a filesystem or filesystem snapshot that is mounted.永远不要对装载的文件系统或文件系统快照进行块级拷贝。
  • 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文件中。

    Warning

    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.请确保在具有足够可用空间的文件系统中运行此命令。

Restore a Snapshot恢复快照

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。

    Warning

    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.原始文件系统的总大小必须小于或等于1 GB，否则恢复将失败。

    Change 1G to your desired volume size.将1G更改为所需的卷大小。

  • Uncompresses and unarchives the mdb-snap01.gz into the mdb-new disk image.将mdb-snap01.gz解压缩并取消归档到mdb-new磁盘映像中。
  • Mounts the mdb-new disk image to the /srv/mongodb directory. 将mdb-new磁盘映像装入/srv/mongodb目录。Modify the mount point to correspond to your MongoDB data file location, or other location as needed.修改装载点以对应MongoDB数据文件的位置，或者根据需要修改其他位置。
Note

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 use db.fsyncLock() you will need to remove the mongod.lock file.如果使用db.fsyncLock()，则需要删除mongod.lock文件。

Restore Directly from a Snapshot直接从快照恢复

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
Note

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. When restoring a collection where no UUID was present, MongoDB generates a UUID for the restored collection.当MongoDB恢复集合时，恢复的集合将保留其原始UUID。当恢复一个没有UUID的集合时，MongoDB会为恢复的集合生成一个UUID。

For more information on collection UUIDs, see Collections.

Remote Backup Storage远程备份存储

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

Back up Instances with Journal Files on Separate Volume or without Journaling使用单独卷上的日志文件或不使用日志备份实例

Changed in version 3.2.3.2版更改。Starting in MongoDB 3.2, for the purpose of volume-level backup of MongoDB instances using WiredTiger, the data files and the journal are no longer required to reside on a single volume. 从MongoDB 3.2开始，为了使用WiredTiger对MongoDB实例进行卷级备份，数据文件和日志不再需要驻留在单个卷上。However, the database must be locked and all writes to the database must be suspended during the backup process to ensure the consistency of the backup.但是，必须锁定数据库，并且在备份过程中必须挂起对数据库的所有写入操作，以确保备份的一致性。

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).如果您有副本集配置，那么对于备份，请使用不接收读取的secondary（即隐藏成员）。

1

Flush writes to disk and lock the database to prevent further writes.刷新磁盘写入并锁定数据库以防止进一步写入。

To flush writes to disk and to "lock" the database, issue the db.fsyncLock() method in mongosh:要刷新对磁盘的写入并“锁定”数据库，请在mongosh中发出db.fsyncLock()方法：

db.fsyncLock();
2

Perform the backup operation described in Create a Snapshot.执行创建快照中所述的备份操作。

3

After the snapshot completes, unlock the database.快照完成后，解锁数据库。

To unlock the database after the snapshot has completed, use the following command in mongosh:要在快照完成后解锁数据库，请在mongosh中使用以下命令：

db.fsyncUnlock();