Database Manual / Self-Managed Deployments / Administration / Backup Methods

Back Up and Restore a Self-Managed Deployment with Filesystem Snapshots使用文件系统快照备份和恢复自我管理部署

This document describes a procedure for creating backups of MongoDB standalone servers and replica sets using system-level tools, such as LVM or storage appliance, as well as the corresponding restoration strategies. 本文档描述了使用LVM或存储设备等系统级工具创建MongoDB独立服务器和副本集备份的过程，以及相应的恢复策略。For information on sharded clusters, see Back Up a Self-Managed Sharded Cluster with File System Snapshots.有关分片群集的信息，请参阅使用文件系统快照备份自管理分片群集。

These filesystem snapshots, or "block-level" backup methods, use system level tools to create copies of the device that holds MongoDB's data files. These methods complete quickly and work reliably, but require additional system configuration outside of MongoDB.这些文件系统快照或“块级”备份方法使用系统级工具创建保存MongoDB数据文件的设备的副本。这些方法完成得很快，工作可靠，但需要在MongoDB之外进行额外的系统配置。

Tip

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 supports volume-level back up using the WiredTiger storage engine when the MongoDB instance's data files and journal files reside on separate volumes. 当MongoDB实例的数据文件和日志文件位于单独的卷上时，MongoDB支持使用WiredTiger存储引擎进行卷级备份。However, to create a coherent backup, the database must be locked and all writes to the database must be suspended during the backup process.但是，要创建一致的备份，必须锁定数据库，并且在备份过程中必须暂停对数据库的所有写入。

Encrypted Storage Engine (MongoDB Enterprise Only)加密存储引擎（仅限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:

  • 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.
  • 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.

    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. When started with the --eseDatabaseKeyRollover option, the mongod instance rolls over the database keys configured with AES256-GCM cipher and exits.

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. Checkpoints occur with every 2 GB of data or every minute.

Stale Data

Backups provide a snapshot of the current state of the database. When you restore from a backup, the restored database doesn't include any changes made after the backup was taken, which can result in data loss.

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.

Alternately, store all MongoDB data files on a dedicated device so that you can make backups without duplicating extraneous data.

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.

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.

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. You can also use LVM-based setups within a cloud/virtualized environment.

Note

Running LVM provides additional flexibility and enables the possibility of using snapshots to back up MongoDB.

Snapshots with Amazon EBS in a RAID 10 Configuration

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. As an alternative, you can do one of the following:

Back Up and Restore Using LVM on Linux

This section provides an overview of a simple backup process using LVM on a Linux system. 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.

For information on sharded clusters, see Back Up a Self-Managed Sharded Cluster with File System Snapshots.

Create a Snapshot

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.

To create a snapshot with LVM, issue a command as root in the following format:

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.

This example creates a snapshot named mdb-snap01 located at /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.

The snapshot has a cap of at 100 megabytes, because of the parameter --size 100M. 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.)

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. 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.

    Warning

    This command will create a large gz file in your current working directory. 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:

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. The path to the new device will be /dev/vg0/mdb-new.

    Warning

    This volume will have a maximum size of 1 gigabyte. The original file system must have had a total size of 1 gigabyte or smaller, or else the restoration will fail.

    Change 1G to your desired volume size.

  • Uncompresses and unarchives the mdb-snap01.gz into the mdb-new disk image.
  • Mounts the mdb-new disk image to the /srv/mongodb directory. Modify the mount point to correspond to your MongoDB data file location, or other location as needed.

Note

The restored snapshot will have a stale mongod.lock file. If you do not remove this file from the snapshot, and MongoDB may assume that the stale lock file indicates an unclean shutdown. If you use db.fsyncLock() you will need to remove the mongod.lock file.

Restore Directly from a Snapshot直接从快照还原

To restore a backup without writing to a compressed gz file, use the following sequence of commands:

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

All MongoDB collections have UUIDs by default. 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。当MongoDB恢复集合时，恢复的集合将保留其原始UUID。当还原不存在UUID的集合时，MongoDB会为还原的集合生成UUID。

For more information on collection UUIDs, see Collections.有关集合UUID的更多信息，请参阅集合。

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备份实例，将日志文件放在单独的卷上或不进行日志记录

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. 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.为了使用WiredTiger对MongoDB实例进行卷级备份，数据文件和日志不再需要驻留在单个卷上。但是，必须锁定数据库，并且在备份过程中必须暂停对数据库的所有写入，以确保备份的一致性。

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 you create the snapshot, unlock the database.创建快照后，解锁数据库。

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

db.fsyncUnlock();