使用文件系统快照备份和还原

在本页面

本文档介绍了使用系统级工具（例如LVM或存储设备）创建MongoDB系统备份的过程，以及相应的还原策略。

这些文件系统快照或“块级”备份方法使用系统级工具来创建保存MongoDB数据文件的设备的副本。这些方法可以快速完成并可靠地工作，但是需要在MongoDB之外进行其他系统配置。

也可以看看

MongoDB备份方法以及 使用MongoDB工具备份和还原。

快照通过在实时数据和特殊快照卷之间创建指针来工作。这些指针在理论上等效于“硬链接”。当工作数据与快照不同时，快照过程将使用写时复制策略。因此，快照仅存储修改后的数据。

制作快照后，将快照映像安装在文件系统上并从快照中复制数据。生成的备份包含所有数据的完整副本。

当MongoDB实例的数据文件和日记文件位于单独的卷上时，MongoDB 3.2添加了对使用WiredTiger存储引擎对MongoDB实例进行卷级备份的支持。但是，要创建一致的备份，必须在备份过程中锁定数据库，并且必须暂停对数据库的所有写操作。

在MongoDB 3.2之前，使用WiredTiger创建MongoDB实例的卷级备份要求数据文件和日志位于同一卷上。

对于使用加密模式的加密存储引擎AES256-GCM，AES256-GCM要求每个进程都使用唯一的计数器块值和密钥。

对于 配置了密码的加密存储引擎AES256-GCM：

从4.2开始，如果您从通过“热”备份（即mongod正在运行）获取的文件中还原，则MongoDB可以在启动时检测到“脏”密钥并自动翻转数据库密钥以避免IV（初始化向量）重用。

但是，如果您从通过“冷”备份获取的文件中恢复（即mongod未运行），则MongoDB无法在启动时检测到“脏”密钥，并且IV的重用会使机密性和完整性保证无效。

从4.2开始，为避免从冷文件系统快照还原后重新使用密钥，MongoDB添加了一个新的命令行选项--eseDatabaseKeyRollover。使用该--eseDatabaseKeyRollover选项启动后 ，mongod 实例将滚动使用AES256-GCM密码配置的数据库密钥 并退出。

小费

发生快照时，数据库必须有效。这意味着数据库所接受的所有写入都必须完全写入磁盘：日志或数据文件。

如果备份发生时磁盘上没有写的内容，则备份将不会反映这些更改。

对于WiredTiger存储引擎，数据文件反映了从最后一个检查点开始的一致状态。每2 GB数据或每分钟都会出现一个检查点。

快照会创建整个磁盘映像的映像。除非您需要备份整个系统，否则请考虑在一个不包含任何其他数据的逻辑磁盘上隔离MongoDB数据文件，日志（如果适用）和配置。

或者，将所有MongoDB数据文件存储在专用设备上，这样您就可以进行备份而不必复制多余的数据。

确保将数据从快照复制到其他系统上。这样可以确保数据不会出现站点故障。

本教程不包括增量备份的过程。尽管不同的快照方法提供不同的功能，但是下面概述的LVM方法不提供捕获增量备份的任何功能。

如果您的mongod实例启用了日记功能，则可以使用任何类型的文件系统或卷/块级快照工具来创建备份。

如果您在基于Linux的系统上管理自己的基础结构，请使用LVM配置系统以提供磁盘包并提供快照功能。您还可以在云/虚拟环境中使用基于LVM的设置。

注意

运行LVM提供了更多的灵活性，并使得可以使用快照来备份MongoDB。

如果您的部署依赖于实例中配置了RAID的Amazon弹性块存储（EBS），则无法使用平台的快照工具在所有磁盘上获得一致的状态。或者，您可以执行以下任一操作：

将所有写入刷新到磁盘并创建写入锁，以确保备份过程中状态的一致性。

如果选择此选项，请参阅备份具有单独卷上的日记文件或没有日记的实例。

配置LVM以将MongoDB数据文件运行并保留在系统内RAID之上。

如果选择此选项，请执行创建快照中描述的LVM备份操作。

本节概述了在Linux系统上使用LVM的简单备份过程。虽然您的系统上的工具，命令和路径可能（略有不同），但是以下步骤提供了备份操作的高级概述。

注意

仅将以下过程用作备份系统和基础结构的准则。生产备份系统必须考虑许多特定于应用程序的要求和特定环境所特有的因素。

在版本3.2中进行了更改：从MongoDB 3.2开始，出于使用WiredTiger进行MongoDB实例的卷级备份的目的，不再需要数据文件和日志位于单个卷上。

要使用LVM创建快照，请以root身份以以下格式发出命令：

此命令创建一个LVM快照（带有--snapshot选项）mdb-snap01，该快照以 卷组mongodb中的vg0卷命名。

本示例创建mdb-snap01位于 的快照/dev/vg0/mdb-snap01。系统卷组和设备的位置和路径可能会略有不同，具体取决于操作系统的LVM配置。

由于参数，快照的上限为100兆字节 。此大小并不反映磁盘上的数据总量，而是反映快照的当前状态和创建快照之间的差异量（即）。--size 100M/dev/vg0/mongodb/dev/vg0/mdb-snap01

警告

确保创建的快照具有足够的空间来说明数据增长，尤其是在将数据复制到系统外或复制到临时映像所花费的时间段内。

如果快照空间不足，快照映像将无法使用。丢弃此逻辑卷并创建另一个。

该命令返回时，快照将存在。您可以随时直接从快照还原，也可以通过创建新的逻辑卷并将其从快照还原到备用映像进行还原。

尽管快照非常适合快速创建高质量的备份，但它们并不是存储备份数据的理想格式。快照通常依赖于并驻留在与原始磁盘映像相同的存储基础结构上。因此，存档这些快照并将其存储在其他位置至关重要。

创建快照后，请安装快照并将数据复制到单独的存储中。当您将备份映像脱机时，系统可能会尝试压缩备份映像。或者，例如通过以下过程获取快照映像的块级副本：

上面的命令序列执行以下操作：

确保/dev/vg0/mdb-snap01未安装设备。切勿对已安装的文件系统或文件系统快照进行块级复制。

使用dd 命令执行整个快照映像的块级复制，并将结果压缩到当前工作目录中的压缩文件中。

警告

此命令将gz在您当前的工作目录中创建一个大文件。确保在具有足够可用空间的文件系统中运行此命令。

要恢复使用LVM创建的快照，请发出以下命令序列：

上面的序列执行以下操作：

mdb-new在/dev/vg0 卷组中创建一个名为的新逻辑卷。新设备的路径为/dev/vg0/mdb-new。

警告

该卷的最大大小为1 GB。原始文件系统的总大小必须为1 GB或更小，否则还原将失败。

更改1G为所需的音量大小。

解压缩并将其归档mdb-snap01.gz到 mdb-new磁盘映像中。

将mdb-new磁盘映像安装到/srv/mongodb目录。修改安装点以对应于您的MongoDB数据文件位置，或根据需要的其他位置。

注意

恢复的快照将具有一个过时的mongod.lock文件。如果您不从快照中删除此文件，MongoDB可能会认为该过时的锁定文件表示关闭异常。如果在storage.journal.enabled启用状态下运行，并且不使用db.fsyncLock()，则不需要删除mongod.lock文件。如果使用 db.fsyncLock()，则需要取下锁。

要恢复备份而不写入压缩gz文件，请使用以下命令序列：

注意

3.6版的新功能：

默认情况下，所有MongoDB集合都具有 UUID。当MongoDB还原集合时，还原的集合将保留其原始UUID。还原不存在UUID的集合时，MongoDB会为已还原的集合生成U​​UID。

有关集合UUID的更多信息，请参见 集合。

您可以使用组合的过程和SSH 实施系统外备份。

此序列与上述过程相同，除了它使用SSH在远程系统上存档和压缩备份外。

请考虑以下过程：

在版本3.2中进行了更改：从MongoDB 3.2开始，出于使用WiredTiger进行MongoDB实例的卷级备份的目的，不再需要数据文件和日志位于单个卷上。但是，在备份过程中必须锁定数据库，并且必须暂停对数据库的所有写操作，以确保备份的一致性。

如果mongod实例运行时没有日志记录，或者日志文件位于单独的卷上，则必须将所有写操作刷新到磁盘并锁定数据库，以防止在备份过程中发生写操作。如果您具有副本集配置，则对于备份，请使用不接收读取的辅助数据库（即隐藏成员）。

要刷新对磁盘的写入并“锁定”数据库，请db.fsyncLock()在mongo外壳程序中发出该 方法：

要在快照完成后解锁数据库，请在mongo外壳程序中使用以下命令：