翻译或纠错本页面

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备份的过程

在 3.2 版更改: 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.

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备份方案 and Back Up and Restore with MongoDB Tools.

快照概述

快照的工作原理是在现有数据和快照的卷上创建指针。这些指针理论上是与 “hard links.”相同的。工作数据与快照分开，快照处理使用即写即拷技术。快照只存储被标记数据

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.

在创建快照之后，你将在你的文件系统上挂载快照映像并且从快照中拷贝数据。最后备份中含有所有数据的拷贝

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 MMAPv1 storage engine, if writes are in progress when the backup occurs, the data files will reflect an inconsistent state. With journaling, all data file states resulting from in-progress writes are recoverable; without journaling, you must flush all pending writes to disk before running the back up operation and must ensure that no writes occur during the entire back up procedure. If you do use journaling, the journal must reside on the same volume as the data.

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.

Entire Disk Image

快照将创建整个磁盘的映像，除非你需要备份整个系统。考虑到隔离你的MongoDB数据文件，日志（如果适用）和配置，在磁盘上不要有其他的数据。

另外，在专用的设备上存储所有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.

Snapshots With Journaling

如果你的 mongod 实例关闭了日志功能，之后你能够使用任何一种文件系统或者卷/块级别的快照工具去创建备份

如果在Linux系统上管理你的基础设备，你可以通过 LVM 使用磁盘封装和快照功能。你同样可在拥有LVM的云/虚拟化环境中使用

注解

运行 LVM 提供了额外的灵活性并且能够快照备份MongoDB

在RAID10下的Amazon EBS使用快照的配置

如果您的部署的实例依赖于RAID配置的亚马逊的弹性块存储（EBS），那么就不可能通过使用平台快照工具在所有磁盘中得到一个一致的状态。作为一种替代方法，您可以执行下列操作之一：

Back Up and Restore Using LVM on Linux

本部分提供一个简单备份过程的概述，在Linux系统中使用 LVM 。尽管在工具，命令，路径上可能与你的系统有细微差别。下文中的步骤提供备份操作的介绍

注解

只能使用如下的步骤作为指导备份系统和基础设施的准则。备份系统必须考虑一些应用独特的需求和在特殊环境中的独特因素

创建一个快照

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

使用 LVM 来创建快照，在root下输入以下命令：

lvcreate --size 100M --snapshot --name mdb-snap01 /dev/vg0/mongodb

该命令创建一个 LVM 快照（通过``–snapshot`` 选项），在``vg0`` 卷组中的 mongodb 卷中命名``mdb-snap01``

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.

由于参数 --size 100M，导致快照有100MB的上限。此大小并不反映磁盘数据上的总量，更确切地说是反映 /dev/vg0/mongodb``的当前状态和创建快照时（即/dev/vg0/mdb-snap01``）的差异数量

警告

确保在足够的空间里创建映像来应对数据的增长，特别是在一段时间里，需要将数据复制到系统外，或一个临时映像。

快照在空间不足时将无法创建。那么需要放弃这个逻辑卷并创建另一个。

在命令返回时快照将会存在。在任何时候，你可以新建一个逻辑卷并将数据从快照中直接恢复，并从该快照恢复至备用镜像。

尽管快照非常适合快速地创建备份，但是作为存储备份数据的格式依然不理想。快照通常保存在原始磁盘镜像中。因此，将这些快照存储至其他地方是非常重要的。

归档快照

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

上述命令执行以下操作：

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

    警告

    该命令将会在当前工作目录中创建一个非常大的``gz``文件。请确保拥有足够的空间！

恢复快照

恢复通过上述方法创建的快照，请输入以下命令

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

上述命令执行以下操作：

  • 在``mdb-new``中，创建一个命名为``mdb-new``的逻辑卷，该路径为 /dev/vg0/mdb-new

    警告

    该卷将拥有最大1GB的空间。原始文件系统的大小必须为1GB或者更小，否则恢复操作将会失败

    将目标卷的大小修改为``1G``

  • Uncompresses and unarchives the mdb-snap01.gz into the mdb-new disk image.

  • 将``mdb-new``挂载到``/srv/mongodb`` 目录下。将挂载点调整至你的MongoDB数据文件地点，或者是其他需要的地点

注解

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’re running with storage.journal.enabled enabled, and you do not use db.fsyncLock(), you do not need to remove the mongod.lock file. If you use db.fsyncLock() you will need to remove the lock.

直接从快照中恢复

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

远程备份存储

你可以使用 combined process 和SSH实施一个离线的备份

这些过程与上述的过程是相同的，但是在远程系统上它的归档和压缩备份使用SSH。

参考以下过程

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

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

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. If you have a replica set configuration, then for your backup use a secondary which is not receiving reads (i.e. hidden member).

重要

In the following procedure to create backups, you must issue the db.fsyncLock() and db.fsyncUnlock() operations on the same connection. The client that issues db.fsyncLock() is solely responsible for issuing a db.fsyncUnlock() operation and must be able to handle potential error conditions so that it can perform the db.fsyncUnlock() before terminating the connection.

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 the mongo shell:

db.fsyncLock();
2

Perform the backup operation described in 创建一个快照.

3

After the snapshot completes, unlock the database.

To unlock the database after the snapshot has completed, use the following command in the mongo shell:

db.fsyncUnlock();

Additional Resources

See also MongoDB Cloud Manager for seamless automation, backup, and monitoring.

© MongoDB, Inc 2008-2017. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.

Report a Problem