本文整理自网络，侵删。
背景及原理
数据库的备份是灾难恢复的最后一道屏障，不管什么类型的数据库都需要设置数据库备份，MongoDB也不例外。MongoDB 3.0 后 ，数据库可以采用Wiredtiger存储引擎后（3.2 版本默认），在此环境下通过mongodump 备份后，产生的备份文件要远大于数据存储文件的大小。此外，一般MongoDB存储的数据量比较大，备份文件也比较大，占用了很多磁盘空间。所以，研究如何实现MongoDB备份压缩很有必要。
上图是执行命令 db.stats() 查看某数据库的信息。
备份文件的大小一般为dataSize的大小，所以我们希望压缩备份，可以达到storageSize 或者更小。
一般的备份思路是先备份，后对备份文件进行压缩。之前，我们采用的就是这种方式，例如主要压缩命令如下
tar -cf - ${targetpath}/${nowtime} | pigz -p 10 > ${targetpath}/${nowtime}.tgz
（命令解释： targetpath}/${nowtime 为待压缩的备份文件；pigz 是Linux压缩神器，可并行压缩；-p是指定cpu的核数。）
但是这种方式，生成备份文件的过程中还是容易形成磁盘性能压力和空间压力。下图为我们某台Server 采用先备份后压缩方式，形成的磁盘可用空间变化。
真正希望的是在备份的同时进行压缩，这样可用空间就比较平稳了。在MongoDB 3.2 中 引入了一种压缩式备份【此mongodb版本必须不低于3.2】。可以使用gzip进行压缩。这是通过在mongodump和mongorestore中引入一个新的指令行选项“- -gzip”实现的。
压缩可用于目录以及归档模型下创建的备份，压缩还可以减少磁盘空间使用。
测试
测试环境：
|
测试服务器 |
测试数据库 |
端口 |
文件路径 |
|
172.X.X.245 |
实例全备 |
17219 |
/data/mongodb_back |
|
172.X.X.246 |
QQ_DingDing |
17218 |
/data/mongodb_back/QQ_DingDing |
相关阅读 >>
mongodb 数据类型(null字符串数字日期内嵌文档数组等)
更多相关阅读请进入《mongodb》频道 >>
数据库系统概念 第6版
本书主要讲述了数据模型、基于对象的数据库和XML、数据存储和查询、事务管理、体系结构等方面的内容。
