分布式数据库把数据打散在多个节点上，靠副本和分片换取高可用与扩展性，但备份这件事反而比单机数据库复杂得多。很多人以为“反正有多个副本，数据不会丢”，这是最危险的误解。副本解决的是单点故障，解决不了误删、逻辑错误、批量更新出错、勒索加密、软件缺陷导致的数据污染。一旦某个错误事务被同步到所有副本，所有节点会一致地“错下去”，这时候唯一能救你的就是一份独立、可恢复、时间点一致的备份。分布式数据库的备份策略，核心不是“要不要备”，而是“怎么在不停服务、不影响一致性的前提下，拿到一份真正能用于恢复的数据”。
先搞清楚分布式数据库备份的三种基本形态
分布式数据库的备份通常分为物理备份、逻辑备份和基于存储快照的备份。物理备份直接复制数据文件和日志，恢复速度快，但跨版本兼容性差，而且分布式环境下很难保证所有节点在同一瞬间完成文件复制。逻辑备份导出的是SQL语句或结构化数据，兼容性好、可读性强，但备份和恢复都慢，适合小规模或跨平台迁移。存储快照备份依赖底层存储系统的快照能力，比如LVM、Ceph、云盘快照，速度快、对业务影响小，但要求所有分片所在存储支持协调一致的快照，否则恢复出来的数据可能处于中间状态。
很多人选备份方案时只看备份速度，忽略了恢复速度和一致性保证。实际上，分布式数据库备份策略的第一原则是：恢复目标决定备份方式。如果你需要RPO等于零，那备份根本不够，必须配合binlog、WAL或redo日志做持续归档。如果你能接受RPO五分钟，那增量备份加日志归档就够。如果你只能接受RTO十分钟，那存储快照加日志回放几乎是唯一选择。先定RPO和RTO，再倒推备份架构，而不是先选一个备份工具再套需求。
一致性备份是分布式数据库最大的技术难点
单机数据库做一致性备份相对简单，因为有全局锁或事务日志可以对齐。分布式数据库的数据分散在多个节点，每个节点有自己的时钟和事务状态，如果各节点各自备份，恢复出来的数据很可能出现“A分片的数据更新了，B分片还没更新”的跨分片不一致。比如一个跨分片转账事务，A分片扣款成功，B分片加款成功，但备份时A分片备份在事务提交后，B分片备份在事务提交前，恢复后钱就凭空消失了。
解决这个问题的常见方案有三种。第一种是全局一致性快照，利用分布式事务协议（如Percolator、TiDB的MVCC、Google Spanner的TrueTime）获取一个全局时间戳，让所有分片在同一个逻辑时间点输出数据。第二种是停止写入或冻结写入，做短暂的全局静默，然后对所有分片同时做快照，适合写入压力小、可接受秒级停写的场景。第三种是基于日志的一致性恢复，不做全局快照，而是持续收集所有分片的变更日志，恢复时先恢复到某个粗粒度快照，再按日志顺序回放到目标时间点。第三种方案最灵活，但对日志的完整性、顺序性和跨分片关联性要求极高。
实际生产环境中，最稳妥的做法是组合使用：定期做全局一致性快照作为基线，持续归档增量日志作为增量，恢复时基线加日志回放。这样既控制了备份窗口，又能把RPO压缩到分钟级甚至秒级。
备份频率、保留周期和恢复演练必须成体系
备份策略不是“每天全备一次”这么简单。分布式数据库的备份策略至少要包含四个维度：全量备份频率、增量备份频率、日志归档频率、保留周期。全量备份建议每天一次，放在业务低峰期，但如果数据量超过几个TB，每天全备的存储成本和备份时间都会成为负担，这时候可以改为每周全备加每日增量。增量备份可以每四到六小时一次，日志归档则应该实时或每分钟一次，取决于RPO要求。
保留周期不能拍脑袋定。至少要保留最近七天的每日全备或等效恢复链，以及最近三十天的增量或日志，以满足大部分合规和误操作恢复需求。如果涉及金融、医疗等行业，保留周期可能要延长到半年甚至更久。更重要的是，保留策略要和恢复演练绑定。很多团队备份做了半年，从来没做过恢复演练，等到真出事才发现备份文件损坏、日志链断裂、恢复脚本过期。建议每季度至少做一次全量恢复演练，每月做一次单分片或单表恢复演练，并记录实际RTO，和预设目标对比。
备份存储的位置和隔离性决定备份是否有效
备份文件如果和生产数据放在同一个机房、同一个存储集群、甚至同一个云账号下，那备份的意义就大打折扣。机房断电、存储故障、账号被入侵、勒索软件加密，都会同时毁掉生产数据和备份。分布式数据库的备份必须遵循“异地、异账号、异介质”的原则。至少要把备份复制到另一个可用区或另一个机房，最好跨云或跨地域。对于关键业务，建议采用3-2-1-1-0规则：至少三份数据副本，两种不同介质，一份异地，一份离线或不可变存储，零未验证的备份错误。
离线或不可变存储特别重要。现在很多备份系统支持对象存储的版本控制和合规锁定，比如开启WORM（一次写入多次读取）功能后，备份文件在保留期内无法被删除或修改，即使数据库账号被攻破，攻击者也删不掉备份。如果条件不允许，至少要把备份复制到一个独立的、权限隔离的存储桶，并开启访问审计。
增量备份和日志归档的链式依赖要严格管理
分布式数据库的增量备份通常依赖上一次全量或增量备份，日志归档又依赖增量备份的起始位点。如果中间任何一个备份文件丢失、损坏或过期被清理，整条恢复链就断了。这是备份策略里最容易出问题的地方。很多团队设置了自动清理策略，比如“保留最近七天的备份”，结果全量备份是上周日的，增量备份只保留了最近三天，周日到周三之间的增量被清理了，恢复链直接断裂。
正确的做法是：清理策略必须基于恢复链的完整性，而不是简单的日期。每次清理前检查该备份是否被后续增量或日志引用，只有确认不再需要才能删除。可以用备份管理工具自动维护依赖关系，或者在清理脚本里加入依赖检查逻辑。另外，日志归档的位点要和增量备份的位点严格对齐，建议在每次增量备份完成后记录一个检查点，日志归档从该检查点开始，恢复时先恢复增量备份，再从检查点回放日志。
针对不同分布式数据库架构的备份侧重点
不同的分布式数据库架构，备份的侧重点完全不同。对于基于共享存储的分布式数据库，比如Aurora、PolarDB，数据文件在共享存储层，备份相对简单，存储层快照加日志归档就能实现秒级恢复。但要注意存储层快照的一致性，以及跨区域复制时日志的延迟。对于基于分片加副本的架构，比如MongoDB分片集群、TiDB、CockroachDB，备份必须覆盖所有分片，并且要处理分片间的逻辑一致性。对于基于中间件分库分表的架构，比如ShardingSphere加MySQL，备份本质上是多个独立MySQL实例的备份，但恢复时必须保证所有分片恢复到同一个时间点，否则跨分片查询会出错。
还有一种容易被忽略的情况：元数据备份。分布式数据库的元数据包括分片路由、表结构、用户权限、集群拓扑等，这些信息如果丢失，即使数据文件都在，集群也可能无法恢复。很多备份方案只备份业务数据，不备份元数据，结果恢复时发现分片规则丢了，或者表结构版本对不上。备份策略里必须包含元数据的定期导出和版本管理，最好每次结构变更后立即备份元数据。
备份过程中的性能影响和限速控制
分布式数据库做全量备份时，会消耗大量的CPU、内存、磁盘IO和网络带宽。如果不做限速，备份任务可能把生产集群拖垮，导致业务延迟飙升。尤其是物理备份和存储快照，虽然速度快，但瞬间的IO冲击很大。建议在备份策略里明确限速参数，比如备份并发度、每秒最大IO、网络带宽上限。同时，备份任务要避开业务高峰，或者使用备份专用的只读副本，从副本上做备份，减少对主节点的压力。
很多分布式数据库支持从从节点或learner节点做备份，这是一个很好的实践。但要注意从节点的数据延迟，如果从节点落后主节点太多，备份出来的数据可能不够新，恢复时RPO会变大。备份前先检查从节点的延迟，如果延迟超过阈值，就切换到主节点备份或者等待延迟追平。
恢复流程的自动化和文档化同样重要
备份做得再好，恢复时手忙脚乱也会出大问题。分布式数据库的恢复流程比单机复杂得多，涉及多个分片、多个备份文件、日志回放、元数据重建、集群重新注册等步骤。如果靠人工操作，出错概率极高。建议把恢复流程脚本化，至少做到一键恢复全量数据，半自动恢复单分片或单表。恢复脚本要定期测试，和备份文件放在一起管理，不能只存在于某个DBA的脑子里。
恢复文档要写清楚每一步的操作命令、预期输出、常见错误和回滚方案。文档不是给新人看的，是给紧急情况下大脑一片空白的人看的。文档里要明确恢复的优先级：先恢复元数据和路由信息，再恢复数据，最后恢复权限和索引。很多团队恢复时先恢复数据，结果发现分片路由没恢复，数据恢复完也没法访问。
监控和告警是备份策略的最后一道防线
备份任务失败、备份文件缺失、日志归档中断、备份存储空间不足，这些问题如果没人发现，备份策略就等于形同虚设。必须对备份全链路做监控，包括备份任务的成功率、耗时、备份文件大小、日志归档延迟、存储空间使用率、恢复演练结果。告警阈值要设置合理，比如备份失败立即告警，备份耗时超过历史均值两倍告警，日志归档延迟超过五分钟告警。
监控不能只看备份任务本身，还要看备份文件的可用性。定期做备份文件的可恢复性检查，比如每月随机抽取一个备份文件做恢复测试，验证文件没有损坏。很多备份系统有校验和功能，可以在备份完成后自动校验文件完整性，但校验和通过不代表一定能恢复成功，最终还是靠恢复演练来验证。
分布式数据库的备份策略，本质上是一套完整的风险管理体系，而不是一个备份工具的配置。它涉及一致性保证、恢复链管理、存储隔离、性能控制、自动化恢复和持续验证。只有把这些环节都纳入策略，并且定期演练和优化，才能真正做到防止数据丢失。备份不是成本，是最后一道保险，而保险的价值只有在出事的时候才会体现出来。
