介绍
定期数据库备份是防止意外数据丢失事件的关键步骤。 通常，备份有两大类：文件系统级（“物理”）备份和逻辑备份。 文件系统级备份涉及在某个时间点对基础数据文件进行快照，并允许数据库使用快照文件中捕获的状态清理自我还原。 逻辑备份包括使用工具（例如mongodump或pg_dump ）将数据库中的数据导出到备份文件中，然后使用相应的恢复工具（例如mongorestore或psql < ）恢复mongorestore 。
在本指南中，我们将演示如何使用Droplet Snapshots执行正在运行的MongoDB安装的文件系统级备份。 另外，我们将介绍如何从快照映像执行还原。
注意：正如DigitalOcean备份指南中详细介绍的那样，使用Droplet快照时会对性能产生一些影响，特别是在高负载数据库上。 您应首先使用带有模拟负载的非生产数据库来测试此过程，以验证此方法是否适用于您的生产部署。
先决条件
在开始使用本指南之前，请确保您已完成以下先决条件步骤：
- 具有sudo权限的非root用户的Ubuntu 16.04 Droplet，详情请参阅初始服务器设置与Ubuntu 16.04
- MongoDB的安装和配置，详见如何在Ubuntu 16.04上安装MongoDB
本指南假定您已安装了MongoDB 3.2+，并使用启用日记功能的默认WiredTiger存储引擎。 另外，要使用本指南，重要的是将dbpath目录（包含数据文件的目录，默认为/var/lib/mongodb ）映射到单个卷。 如果您没有将附加块存储卷附加到Droplet上，则可以按照本指南进行操作。
一旦您登录到Droplet并启动并运行MongoDB，您就可以开始使用了。
第1步 - 验证您的MongoDB安装程序
我们首先要检查日志已启用。
日记功能是一种MongoDB功能，通过将操作写入日志文件来防止数据库故障时的持久性。 要了解有关MongoDB日记的更多信息，请参阅MongoDB手册 。
如果您遵循上述指南，日记将默认启用。 为了确认是这种情况，我们可以检查MongoDB配置文件。
使用您最喜欢的文本编辑器（例如nano）打开/etc/mongod.conf ：
nano /etc/mongod.conf
你应该看到下面的块：
# Where and how to store data.
storage:
dbPath: /var/lib/mongodb
journal:
enabled: true
# engine:
# mmapv1:
# wiredTiger:
这表明日志已启用。 如果你使用的是MongoDB 3.2+，默认的存储引擎是WiredTiger（MMAPv1是MongoDB的原始存储引擎）。
现在我们将插入一些虚拟数据来测试备份和恢复过程。
第2步 - 插入测试数据
如果您已经开始使用干净的服务器，并且还没有任何数据，我们可以将一些示例数据插入虚拟餐馆收藏中，以供演示。 如果您的数据库中已存有一些收藏和文档，请随时跳过此步骤。
首先，使用MongoDB shell连接到正在运行的数据库：
mongo
你应该看到下面的Mongo shell提示符：
MongoDB shell version: 3.2.19
connecting to: test
Server has startup warnings:
2018-02-16T02:40:13.071+0000 I CONTROL [initandlisten]
2018-02-16T02:40:13.071+0000 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
2018-02-16T02:40:13.071+0000 I CONTROL [initandlisten] ** We suggest setting it to 'never'
2018-02-16T02:40:13.071+0000 I CONTROL [initandlisten]
2018-02-16T02:40:13.071+0000 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2018-02-16T02:40:13.071+0000 I CONTROL [initandlisten] ** We suggest setting it to 'never'
2018-02-16T02:40:13.071+0000 I CONTROL [initandlisten]
>
shell使用的默认数据库是测试数据库。
让我们列出测试数据库中存在的集合：
show collections
由于我们还没有向数据库中插入任何内容，因此没有集合，并且我们被带回到没有输出的提示。
让我们将文档插入一个虚拟餐厅集合，我们将在同一时间创建：
db.restaurants.insert({'name': 'Sammy's Pizzeria'})
您应该看到以下输出：
WriteResult({ "nInserted" : 1 })
这表示插入操作成功。 由于餐厅收藏之前并不存在，它同时创建。
让我们再次列出集合：
show collections
我们现在看到我们新创建的餐厅系列：
restaurants
现在我们已经在数据库中存储了一些示例数据，我们已经准备好进行备份。
第3步 - 快照MongoDB Droplet
要执行备份，我们将利用DigitalOcean Droplet快照 。 Droplet快照允许我们在快照启动的时间点创建Droplet的图像。 然后可以将该图像恢复到新的Droplet，在那里可以进行进一步的恢复操作。
鉴于我们使用的是MongoDB 3.2+（启用了WiredTiger和日志功能），我们不需要在发生快照时暂停写入文件系统。 一旦我们恢复映像并启动数据库，MongoDB就会从检查点恢复自身，然后从日志文件重播操作，直到达到发生快照的时间点。 如果您有兴趣进一步探索日记，请参阅MongoDB手册 ），
要开始快照过程，请登录到您的DigitalOcean帐户 ，导航到您的MongoDB Droplet，然后单击边栏中的快照链接。
您应该看到以下提示：
注意：尽管建议在拍摄快照之前关闭Droplet，但在生产部署中，这可能并不总是可行的。 即使在数据库和Droplet运行时，MongoDB的日志功能也可以实现一致且有效的快照。
为您的快照指定一个描述性名称，然后单击“ 实时快照”按钮开始快照过程。
您应该看到以下快照进度指示器：
快照完成后，您可以从图像创建新的Droplet，或将正在运行的Droplet恢复到快照图像中捕获的状态。
我们现在准备好执行备份过程的恢复和验证。
第4步 - 恢复MongoDB Droplet
现在我们将创建一个新的Droplet，它将从我们刚创建的图像中恢复。 我们的MongoDB数据库中可用的数据将与拍摄快照时的数据相同。
使用侧边栏导航回快照 ，并找到已完成的Droplet快照。
点击更多并选择Create Droplet 。
你将被带到Create Droplet菜单，在那里你可以从你的快照中创建一个新的Droplet。
选择与之前拍摄的快照相对应的图像。 在这种情况下，我们将使用mongo-backup-test映像。
完成配置您的恢复Droplet并单击创建 。 一旦您的恢复Droplet启动并运行，请登录。
如果您将MongoDB配置为在Droplet启动时启动，现在应该正在运行。 你可以使用systemctl来检查这个：
sudo systemctl status mongod
您应该看到以下输出：
Output● mongod.service - High-performance, schema-free document-oriented database
Loaded: loaded (/lib/systemd/system/mongod.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2018-02-14 21:14:40 UTC; 4min 53s ago
Docs: https://docs.mongodb.org/manual
Main PID: 1302 (mongod)
Tasks: 19
Memory: 87.2M
CPU: 1.802s
CGroup: /system.slice/mongod.service
└─1302 /usr/bin/mongod --quiet --config /etc/mongod.conf
表明一切正常，MongoDB正确启动。
如果MongoDB没有运行，我们首先需要删除锁定文件，然后启动服务：
rm /var/lib/mongodb/mongod.lock
sudo systemctl start mongod
验证MongoDB是否使用systemctl status正确启动。
一旦MongoDB启动并运行，它将开始自行清理并将其状态恢复到发生快照时的时间点。 这可能需要几分钟的时间，并且在完成之前可能无法使用mongo shell。
一旦服务器可用，我们可以使用mongo命令登录：
mongo
您现在将得到mongo shell提示符：
OutputMongoDB shell version: 3.2.19
connecting to: test
Server has startup warnings:
2018-02-14T21:14:41.923+0000 I CONTROL [initandlisten]
2018-02-14T21:14:41.923+0000 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
2018-02-14T21:14:41.923+0000 I CONTROL [initandlisten] ** We suggest setting it to 'never'
2018-02-14T21:14:41.923+0000 I CONTROL [initandlisten]
2018-02-14T21:14:41.923+0000 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2018-02-14T21:14:41.923+0000 I CONTROL [initandlisten] ** We suggest setting it to 'never'
2018-02-14T21:14:41.923+0000 I CONTROL [initandlisten]
>
如果你已经做到了这一点，恭喜！ 您已成功执行MongoDB数据库的备份和恢复。
作为额外的预防措施，我们可以检查我们馆藏的完整性。
第5步 - 检查数据完整性
在生产使用此备份数据之前，检查已恢复的集合以查找无效的BSON对象很有用。
注意：对于非常大的集合， validate命令可能会很慢。 另外，所有的读写操作都将被阻塞，直到validate命令返回。
在这个例子中，我们有一个叫做餐馆的集合，我们要运行validate命令。
在mongo shell中，运行validate命令：
db.restaurants.validate({full:true})
您应该看到与以下类似的输出：
{
"ns" : "test.restaurants",
"nrecords" : 1,
"nIndexes" : 1,
"keysPerIndex" : {
"test.restaurants.$_id_" : 1
},
"indexDetails" : {
"test.restaurants.$_id_" : {
"valid" : true
}
},
"valid" : true,
"errors" : [ ],
"ok" : 1
}
如果您看到valid: true ，则您收藏的所有方面均有效，并且您可以安全地使用该收藏中的数据进行制作。
结论
在本教程中，我们学习了如何完成正在运行的MongoDB数据库服务器的物理文件系统级备份。
要了解更多关于备份MongoDB数据库的各种方法，请参考MongoDB手册 。
由于DigitalOcean便捷的快速Droplet功能，使得这种特殊的备份技术成为可能。 要了解更多关于Droplet Snapshots的信息，请查阅Snapshot文档 。
另外，您可以使用“备份”功能自动安排这些快照。 要了解有关Droplet备份的更多信息，请参阅备份简介 。
