MongoDB现在可是很多公司的核心数据库，万一数据丢了，那损失可不是开玩笑的。比如有个电商平台，订单数据存在MongoDB里，一次系统崩溃导致最近两小时的订单全没了，结果当天退款率涨了30%，直接损失近百万。数据恢复就像买保险，平时用不上，真出事了才知道有多重要。不管是初创公司还是大企业，只要用了MongoDB，都得认真对待数据备份和恢复。
数据恢复说白了就是数据丢了之后，想办法把数据救回来的过程。常见的数据丢失原因有硬件坏了、不小心重启、手滑删错，或者脚本写错把库搞乱了。我们一般用RPO（能容忍丢多少数据）和RTO（恢复要花多久）来衡量恢复效果。比如一个用MongoDB存订单的电商，系统崩了只能恢复到10分钟前的备份，RPO就是10分钟，RTO是恢复服务大概花了半小时。MongoDB的恢复难点在于它的分片和副本集架构——单节点出问题要处理复制延迟，分片环境还要保证各分片数据一致。虽然MongoDB自带mongodump、oplog滚动备份等工具，但实际恢复速度还得看网络和脚本优化。所以企业用MongoDB时，一定要把RPO和RTO写进服务协议，避免订单丢失、客户不信任甚至退款这种糟心事。
说到MongoDB备份策略，那可真是门学问。备份就像给数据上保险，全量备份是把所有数据打包存一份，增量备份只存新改动的部分。选哪种得看业务需要和你能接受多长的恢复时间。备份频率和保存周期也得规划好，别存太多占地方。最后，备份的数据得存到安全的地方，最好加密，这样真出问题也能快速恢复，不让客户干着急。
mongodump是MongoDB自带的备份工具，安装很简单，一般系统装个包就能用。基本命令像这样：。加上参数比如 可以控制名称， 能压缩备份文件。比如我们之前全量备份一个50GB的业务库，用 压缩后存到 ，再传到NAS上，结合cron每天自动备份一次。增量备份的话，可以用 条件只备份最近有变动的数据，省空间又高效。这样全量和增量搭配，再加上传输加密，恢复时心里踏实，客户也放心。
mongoexport更像是个“数据挑选工具”，它能把集合导出成JSON或CSV格式，特别适合做报表、迁移数据或者给别的系统用。比如我们要导出订单表里状态是“已完成”且金额超过500块的记录为CSV，命令大概是：。和mongodump的二进制全量备份不同，mongoexport能按条件筛选、只导需要的字段，生成的文本文件在Windows、Linux甚至Excel里都能直接打开，跨平台交换数据特别方便。
用mongoexport导出的文本文件恢复起来是方便，但实际操作可不能大意。之前有团队导完CSV就把原库清空了，恢复时才发现文件里少了近200条订单，来回折腾两小时。所以恢复前一定得先规划策略：确认是要恢复全部还是部分数据，有没有对应的备份。然后检查环境，比如目标数据库版本和导出时是否一致，避免兼容问题。恢复完还要做一致性验证，比如核对导出的行数和原库记录数是否一致。小数据量的补录用CSV导入就行，全量恢复还是mongodump的二进制备份更稳妥。
mongorestore用起来挺顺手，基本命令像这样：。最常用的参数是 ，能在恢复前清空现有数据，避免重复。之前有个项目数据量大概100GB，我们用 启动多线程并行恢复，速度明显快了不少。
再说说mongoimport的恢复技巧，真的很灵活。你可以把备份的JSON或CSV按大小拆分，比如每10万行一个文件，命名成data-01.json、data-02.json。导入命令类似：。如果是CSV，记得加字段映射，比如，并指定。工具会自动处理类型转换，不用担心数值格式问题。提升性能的关键是文件拆分，配合多核并行写入，一个10GB的数据集大概15分钟就能导完。还有个窍门：导入前先删索引，导完再重建，速度能快3倍。
数据恢复的最佳实践，说到底就几个关键点：定期做恢复测试、设置监控告警、尽量自动化。常见错误比如恢复时没先删索引，导致导入特别慢；或者备份方案没测试，真到用时发现不能用。我们有个客户每月做一次恢复演练，结果真在一次硬盘故障前发现了备份问题，及时补救避免了更大损失。自动化备份配合监控告警，能在备份失败时第一时间通知人，这样既省心又保险。
