背景及原理
数据库的备份是灾难恢复的最后一道屏障,不管什么类型的数据库都需要设置数据库备份,MongoDB也不例外。MongoDB 3.0 后 ,数据库可以采用Wiredtiger存储引擎后(3.2 版本默认),在此环境下通过mongodump 备份后,产生的备份文件要远大于数据存储文件的大小。此外,一般MongoDB存储的数据量比较大,备份文件也比较大,占用了很多磁盘空间。所以,研究如何实现MongoDB备份压缩很有必要。

上图是执行命令 db.stats() 查看某数据库的信息。
备份文件的大小一般为dataSize的大小,所以我们希望压缩备份,可以达到storageSize 或者更小。
一般的备份思路是先备份,后对备份文件进行压缩。之前,我们采用的就是这种方式,例如主要压缩命令如下

真正希望的是在备份的同时进行压缩,这样可用空间就比较平稳了。在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 压缩式备份的命令:
补充说明(1) 如果不采用压缩式的备份,备份后的文件会是多大呢?备份命令 :
采用压缩式备份(指定–gzip参数)的方式耗时 2小时33分钟
产生的备份文件大小基本相等,压缩式备份方式产生的备份文件略小

所以 压缩式备份会导致备份时间增长。
但从空间使用的角度来讲,我们仍然建议大家使用压缩式备份,其压缩比非常高(测试案例的压缩比6.3%)。
附:定时清除,保留7天的纪录
#!/bin/bashtargetpath='/backup/mongobak'nowtime=$(date -d '-7 days' "+%Y%m%d")if [ -d "${targetpath}/${nowtime}/" ]thenrm -rf "${targetpath}/${nowtime}/"echo "=======${targetpath}/${nowtime}/===删除完毕=="fiecho "===$nowtime ==="本篇文章到此结束,如果您有相关技术方面疑问可以联系我们技术人员远程解决,感谢大家支持本站!