（命令解释： 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
Step 1 压缩式备份的命令：
备份后文件的大小，97M
这时候，查看备份文件的格式都变成了.gz的格式
Step 2 将备份文件copy至远程机器上，进行还原：
以下命令是将在172.X.X.246，要求是将文件从X.245 copy至本地
step 3 执行还原的命令
执行的命令
还原后登录MongoDB，执行show dbs，查看此时 数据大小为500M。
补充说明
(1) 如果不采用压缩式的备份，备份后的文件会是多大呢？备份命令 ：
查看此种方法备份后的文件大小--1.5G。
以此QQ_DingDing数据库为例，其压缩率为（文件压缩后的大小与压缩前的大小之比）：97M/1.5G=97/1536=6.3%
(2) 这种压缩备份的方式的会不会带来一些弊端：例如备份时间增长？（恢复时间增加？，请自测一下试试，嘻嘻 @@@）
以 某归档备份库所在实例为例（storageSize 150G，dataSize 600G ）
采用 先备份后压缩的方式耗时1小时55分钟
采用压缩式备份（指定--gzip参数）的方式耗时 2小时33分钟
产生的备份文件大小基本相等，压缩式备份方式产生的备份文件略小
所以 压缩式备份会导致备份时间增长。
但从空间使用的角度来讲，我们仍然建议大家使用压缩式备份，其压缩比非常高（测试案例的压缩比6.3%）。
附：定时清除，保留7天的纪录
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对七叶笔记的支持。
