使用文件系统Atlas 备份快照备份和恢复自托管部署
在此页面上
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. For information on sharded clusters, see 使用文件系统快照备份自管理分片集群.
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.
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 存储引擎
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. However, to create a coherent backup, the database must be locked and all writes to the database must be suspended during the backup process.
加密存储引擎(仅限 MongoDB Enterprise)
对于使用 AES256-GCM
加密模式的加密存储引擎,
AES256-GCM
要求每个进程使用带有密钥的唯一计数器块值。
对于使用 AES256-GCM
密码配置的加密存储引擎:
- 从热备份恢复
- 从 4.2 开始,如果从通过“热”备份(即
mongod
正在运行)获取的文件进行恢复,MongoDB 可以在启动时检测到“脏”密钥,并自动滚动更新数据库密钥以避免重用 IV(初始化向量)。
- 从冷备份恢复
不过,如果从通过“冷”备份(即
mongod
未运行)获取的文件进行恢复,MongoDB 无法在启动时检测到“脏”密钥,重用 IV 将导致机密性和完整性保证失效。从 4.2 版开始,为了避免从冷文件系统快照恢复后重用密钥,MongoDB 添加了一个新的命令行选项
--eseDatabaseKeyRollover
。使用--eseDatabaseKeyRollover
选项启动时,mongod
实例会滚动使用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. Checkpoints occur with every 2 GB of data or every minute.
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.
注意
Running LVM provides additional flexibility and enables the possibility of using snapshots to back up MongoDB.
通过采用 RAID 10 配置的 Amazon EBS 来创建快照
如果您的部署依赖于 Amazon 的 Elastic Block Storage (EBS),并在实例中配置了 RAID,则无法使用该平台的快照工具在所有磁盘上获得一致的状态。作为替代方案,您可执行下列操作之一:
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.
配置 LVM,以便在您系统内的 RAID 上运行并保存您的 MongoDB 数据文件。
If you choose this option, perform the LVM backup operation described in Create a Snapshot.
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.
注意
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 使用文件系统快照备份自管理分片集群.
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
.)
警告
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.警告
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
.警告
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.
更改
1G
to your desired volume size.Uncompresses and unarchives the
mdb-snap01.gz
into themdb-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.
注意
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
注意
所有 MongoDB 集合默认都有 UUID。MongoDB 恢复集合时,恢复的集合保留其原始 UUID。恢复不存在 UUID 的集合时,MongoDB 会为恢复的集合生成一个 UUID。
有关集合 UUID 的更多信息,请参阅集合。
Remote Backup Storage
You can implement off-system backups using the combined process and SSH.
This sequence is identical to procedures explained above, except that it archives and compresses the backup on a remote system using 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.
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 复制集 configuration, then
for your backup use a 从节点 which is not receiving reads
(i.e. 隐藏成员).
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
:
db.fsyncLock();
Perform the backup operation described in Create a Snapshot.
After you create the snapshot, unlock the database.
To unlock the database after you create the snapshot,
use the following command in mongosh
:
db.fsyncUnlock();