NoSQL 备份与恢复体系：复制不是备份，快照不是演练

数据库事故里最残酷的一句话是：“我们有备份，但恢复不了。”NoSQL 系统常带复制、副本、分片和多节点高可用，很多团队因此误以为不需要备份。复制解决节点故障，备份解决误删、逻辑错误、勒索、批量更新失败和区域级灾难。

备份的价值不在于文件存在，而在于能在规定时间内恢复到业务可接受的数据点。

RPO 与 RTO

设计备份前先定义两个指标：

• RPO：最多允许丢失多久数据。
• RTO：最多允许多久恢复服务。

不同数据的要求不同。支付状态可能要求分钟级 RPO 和很短 RTO；日志分析数据可能允许小时级甚至天级恢复。

如果没有 RPO/RTO，备份策略就无法评估是否合格。

复制不是备份

MongoDB Replica Set、Redis 主从、Cassandra 多副本、Elasticsearch replica 都能提高可用性。但如果应用执行了错误删除，删除会被复制到副本。副本只是在复制错误。

复制适合应对：

• 单节点宕机。
• 磁盘损坏。
• 读扩展。
• 故障切换。

备份适合应对：

• 误删数据。
• 代码 bug 批量写错。
• 勒索或恶意操作。
• 跨区域灾难。
• 需要回溯历史版本。

备份一致性

NoSQL 系统常有分片和副本。备份时要考虑一致性点。单节点文件拷贝可能得到不可用或不一致的数据。生产中应使用数据库原生工具、云快照、oplog/binlog/commitlog 或支持一致性快照的备份系统。

对分片集群，必须确保各分片快照在逻辑时间上可协调。否则恢复后可能出现跨分片数据不一致。

时间点恢复

只做每日全量备份通常不够。若上午 10 点误删数据，而最近备份是凌晨 2 点，全量恢复会丢失 8 小时数据。时间点恢复需要日志：

• MongoDB oplog。
• Redis AOF。
• Cassandra commit log 或增量备份。
• Elasticsearch snapshot 增量快照。

并不是所有系统都适合精确时间点恢复，要结合数据库能力和业务成本设计。

恢复演练

备份必须演练。演练流程包括：

1. 从备份创建隔离恢复环境。
2. 校验数据完整性和数量。
3. 验证应用能否连接。
4. 测试关键查询和写入。
5. 记录实际恢复耗时。
6. 更新 runbook。

演练频率取决于业务重要性。核心数据库至少应定期演练，且每次架构变更后重新验证。

跨区域备份

备份不能只放在同一区域同一账号。区域故障、账号被攻击或权限误操作都可能让备份不可用。建议：

• 跨区域保存。
• 使用独立权限账号。
• 设置保留策略。
• 对关键备份启用不可变存储。
• 定期校验备份可读。

安全上，要限制删除备份的权限。很多勒索攻击会优先删除备份。

数据分级

不是所有数据都需要同样备份策略。可以分级：

• P0：交易、账户、权限，强备份和频繁演练。
• P1：核心业务状态，较短 RPO/RTO。
• P2：搜索索引、缓存、可重建读模型，关注重建速度。
• P3：临时数据，可低成本保留或不备份。

Elasticsearch 搜索索引如果能从主数据库重建，备份策略可以更轻，但要评估重建时间是否影响业务。

恢复后的切换

恢复数据只是第一步。还要考虑应用如何切换到恢复实例：

• DNS 或连接串切换。
• 应用配置更新。
• 写入暂停和恢复。
• 双写冲突处理。
• 缓存清理。
• 搜索索引重建。

恢复演练必须覆盖应用层，否则数据库恢复成功但业务仍不可用。

总结

NoSQL 备份恢复的核心原则是：复制不是备份，快照不是演练，备份文件不是恢复能力。真正可靠的体系要明确 RPO/RTO，使用一致性备份，支持必要的时间点恢复，跨区域保存，并定期从应用视角演练。数据系统的韧性，不在平时的副本数量，而在事故发生时能否可信地回到正确状态。