干这行最怕半夜电话响，尤其是那种带着哭腔说“库挂了”的。MongoDB虽然好用，但真出事儿的时候，副本集脑裂、磁盘写满、误删集合，哪个都够喝一壶。我见过太多人，平时备份开着，真到恢复那天手忙脚乱，连备份文件放哪儿都找不着。说白了，恢复这事儿拼的不是运气，是预案和流程。今天就把我从备份到实战恢复的完整套路捋一遍，全是踩过坑换来的经验。
先说备份这步，很多人有个误区，觉得开了副本集就万事大吉，主节点挂了从节点顶上，数据丢不了。但你要清楚，副本集同步的是操作日志，要是有人手抖执行了，这条命令会照样同步到从节点，全库瞬间清空。所以别指望副本集当备份，它只能防硬件故障，防不了逻辑错误。正经的备份得靠或者文件系统快照，前者逻辑备份，后者物理备份，各有各的适用场景。我一般建议小库（几个GB以内）用mongodump，简单直接；上了TB级别的库，老老实实用文件系统快照，或者MongoDB Atlas的连续备份，不然恢复时间长到能让你怀疑人生。
mongodump这工具看着简单，实际坑不少。默认情况下它只备份数据，不带索引，恢复的时候要重新建索引，大表重建索引能跑几个小时。所以备份命令里一定要加上参数，这样能拿到备份时间点之后的增量操作日志，恢复的时候可以做到时间点恢复，不至于丢最近几分钟的数据。命令大概是。还有，别忘了压缩，磁盘空间能省一大半。定时任务用crontab跑，每天凌晨低峰期执行，日志留够，出问题能追溯。
光有备份文件还不够，得定期演练恢复。这话我说了无数遍，但真按我说的做的没几个。你以为备份文件是好的，结果恢复的时候发现文件损坏，或者mongodump版本跟线上MongoDB版本不匹配，直接报错。最稳妥的办法是每个月挑个周末，在测试环境把最新备份完整恢复一遍，顺便验证数据完整性，比如查一下关键集合的文档数、跑几条业务SQL。我见过最惨的案例，备份跑了半年，恢复的时候才发现mongorestore跟MongoDB 4.4的兼容性有问题，全得重来。演练这事儿，真不是浪费时间。
真到恢复那一刻，千万别慌，先评估损失范围。是单个集合被误删，还是整个库都没了？是物理机磁盘坏了，还是集群配置出错？不同的故障类型，恢复策略完全不同。如果只是单个集合误删，别急着全库恢复，用mongorestore的参数，只恢复那一个集合，速度快得多，也不影响其他正在跑的业务。如果是全库故障，那就得做完整恢复，这时候时间点就很重要。备份文件里如果有oplog，可以先恢复到备份完成时的时间点，再用oplog增量重放到故障发生前一刻。这操作要求你对oplog的起止时间有精确记录，所以备份脚本里一定要把时间戳写到文件名里，别偷懒。
恢复过程中最容易被忽略的是分片集群的情况。如果你用的是mongos + config server + shard的架构，恢复的时候不能只恢复某一个shard，config server里的元数据也得同步恢复，不然路由信息全乱套。我吃过这个亏，有一次只恢复了shard节点，忘了config server，结果mongos连不上，整个集群瘫痪了俩小时。所以分片集群的备份，一定要把config server的备份也包含进去，恢复的时候按顺序来：先恢复config server，再恢复shard节点，启动mongos。顺序错了，整个集群起不来。
再说说恢复后的验证，这一步很多人草草了事，觉得数据能查出来就完事了。但你要知道，mongorestore恢复的数据默认不带索引，如果你没在备份的时候保留索引定义，恢复完业务查询会慢得跟蜗牛一样。所以恢复完第一件事，检查索引是否重建完毕，用看一眼，缺了赶紧补。第二个要验证的是数据一致性，比如某个集合的文档总数跟故障前的监控数据对不对得上，有偏差就得查oplog重放是不是有遗漏。还有个细节，恢复完记得把应用连接串切到新节点之前，先跑一遍只读查询，确认没问题再切，别让业务方当你的小白鼠。
说点实在的，恢复流程再完善，也不如别出事。MongoDB有个好习惯，定期做 + 文件系统快照，能保证数据文件的一致性，但操作前记得先锁库，不然快照可能是不完整的。另外，权限管理一定要做好，误删操作十有八九是权限太松，开发手里拿着root账号，一个手滑就没了。给开发只读账号，给运维管理账号，给DBA才给root，这是底线。还有，监控告警得配齐，磁盘空间低于20%就告警，主从延迟超过30秒就告警，别等磁盘满了才发现备份文件写不进去。备份这事儿，平时多花十分钟配置，关键时刻能救你一条命。
说回开头那句，MongoDB恢复这事儿，真不是靠运气。备份策略、恢复演练、故障分级、验证流程，环环相扣，缺一环都可能翻车。我见过太多人备份文件躺在那里，真出事的时候要么版本不兼容，要么oplog没带上，要么恢复顺序搞反了，白白浪费时间。把这些步骤刻在脑子里，写成脚本，定期演练，真到那天你就能像呼吸一样自然地完成恢复操作。记住，数据库恢复不是技术活，是流程活，流程对了，技术只是执行细节而已。
