备份不是把数据复制一份那么简单，而是要让数据在多个节点各自安家，并通过共识算法保证每个“家”里的数据版本一致，这样任何一台机器宕机，整个系统都能面不改色地继续服务。
这几年业务系统越做越大，单机数据库再努力也有扛不住的时候，大家开始把目光投向分布式数据系统，但分布式带来的第一个难题，恰恰就是备份，很多人以为分布式天然就安全，毕竟数据分散在多台机器上，丢一台还有别的，这个想法方向对，但细节远没那么简单，今天咱们就把它聊透,说点实在的。
数据库备份的三种方式分别适合什么业务场景
聊分布式备份之前，得先把基础概念对齐，传统单机数据库备份的三种方式，在分布式架构里依然适用，只是执行方式从“一个人干活”变成了“一群人分工”。
全量备份：老实但不省心
全量备份就是把整个数据集完整复制一份，简单粗暴，恢复的时候也最省事，但问题在于，数据量一大，全量备份的时间窗口就成了噩梦，一个几TB的分布式集群，全量跑一次可能得好几个小时,期间对业务的影响很难忽略。
适用场景：数据量可控、业务允许低峰期长时间备份的系统，比如内部管理系统、报表仓库这类对实时性要求不高的场景,全量备份反而最稳。
增量备份：省时间但恢复链条长
增量备份只记录从上一次备份之后变化的数据，在分布式系统里，增量备份通常通过日志或者版本号来实现，好处是快，坏处是恢复的时候要把全量加一串增量按顺序拼起来，链条越长,出问题的概率越大。
适用场景：数据变更频繁、备份窗口紧张的业务，比如电商订单系统、用户行为日志系统，这类场景每天的数据变化量很大,天天做全量不现实。
差异备份：两头兼顾的折中方案
差异备份备份的是自上次全量备份以来所有变化的数据，和增量的区别在于，增量是“上次备份之后”，差异是“上次全量之后”。恢复时只需要全量加最近一个差异包，比增量省事,备份时间又比全量短。
适用场景：数据量中等、业务对恢复时间有明确要求的系统，比如金融交易系统的结算数据，既要备份快,又要恢复快。
这三种方式在分布式系统里的执行逻辑，和单机最大的区别在于：备份任务要分发到各个节点并行执行，然后统一汇总校验，这就要靠分布式调度框架来协调,确保所有节点的备份在时间点上是一致的。
分布式备份系统数据的一致性怎么保证
备份最怕什么？怕的是不同节点备份出来的数据不在同一个时间点，比如A节点备份的是10点整的数据，B节点备份的是10点零5分的数据，那这个备份集就是“错乱”的,恢复的时候整个系统根本起不来。
共识算法是分布式备份的定海神针
行业共识认为，分布式系统里要保证一致性，逃不开共识算法，Raft和Paxos是主流选择，它们解决的核心问题是：多个节点之间如何就某个状态达成一致。
放到备份场景里，就是当一个写入请求到达系统时，需要多数派节点（比如三副本里的两个）都确认写入成功，这个操作才算完成，这样一来，无论哪个节点宕机,剩余节点里总能找到一个包含最新数据的副本。
备份文件的时间标签必须全局统一
分布式备份系统在生成备份文件时，会给每个文件打上一个全局逻辑时钟戳，而不是各自用本机物理时间，物理时间最大的坑在于节点间时钟可能不同步，A节点觉得是10点，B节点觉得是10点零3分,两边都说自己是对的。
用全局逻辑时钟的好处是，不管底层物理时间差多少，备份文件之间的先后顺序是确定的，恢复时按这个顺序重放,就能保证数据回到一个一致的时间点。
多数派写机制让“丢数据”变成小概率事件
三副本写入时，只要两个节点确认写成功，系统就向客户端返回成功，这意味着即使一个节点宕机，数据依然完整，如果想更稳，可以五副本要求三个确认，代价是写入性能下降,但数据安全系数大幅提升。
这个权衡没有标准答案，要看业务对数据丢失的容忍度，金融核心系统、医疗健康数据这类场景，多数会选更高副本数；而日志分析、推荐系统这类容忍度高的,三副本已经足够。
异地容灾备份策略该怎么规划
备份系统的数据如果全部放在同一个机房，万一机房遭遇火灾、水灾或者光缆被挖断，整个备份体系就全完了，异地容灾不是大厂的专利,小团队也应该有基本的跨机房意识。
双活数据中心是性价比较高的方案
双活意味着两个机房同时对外提供服务，数据实时双向同步，任何一个机房挂了，另一个机房无缝接管，用户几乎无感知，成本比三地三中心低不少,是很多中型企业的首选。
两地三中心适合对数据安全要求极高的场景
两地三中心是经典方案：本地两个机房做双活，异地再放一个灾备中心，数据通过异步复制同步过去，这个方案能扛住机房级故障，也能扛住地域级灾难，代价是异步复制可能丢失最后几秒的数据，但对于绝大多数业务来说,这个风险可以接受。
冷备和温备要分清
冷备是定期把备份数据导到磁带或者冷存储上，平时不启动，只有灾难发生时才拉起来，成本极低，但恢复时间以天计。温备是备份系统保持待机状态，数据周期性同步，恢复时间以小时计，热备则是实时同步,恢复时间以分钟甚至秒计。
现在很多团队把冷备这个“压箱底”的手段给省了，只靠在线副本，这种做法风险不小，因为在线副本可能被勒索软件一锅端,冷备离线存储反而能躲过一劫。
备份系统数据恢复演练不能只停留在文档里
备份做得再好，恢复不了等于零，很多团队的做法是：备份脚本跑得欢，恢复演练从来没做过，等到真出事了，才发现备份文件损坏、恢复步骤写得不清不楚、关键人员还联系不上。
恢复演练应该按季度严格执行
流程不复杂：挑一个业务低峰期，在隔离环境里把最近一次备份完整恢复一遍，然后跑一些核心查询，验证数据完整性，如果恢复时间超过预期,就要排查瓶颈在哪个环节。
备份文件的完整性校验不能省
备份文件在传输和存储过程中可能因为磁盘坏道、网络丢包等原因静默损坏。每次备份完成后，应该对备份文件做校验和比对，确保文件和源数据一致，这个步骤很多人图省事跳过了，等恢复时才发现问题,代价就大了。
恢复时间目标（RTO）和数据恢复点目标（RPO）要提前定好
RTO指的是从故障发生到系统恢复可用需要多长时间，RPO指的是数据最多能丢多少，这两个指标决定了备份频率和恢复策略的选择，比如RPO要求15分钟，那备份频率至少得5到10分钟一次；RTO要求1小时,那恢复流程就不能过于繁琐。
混合云架构下的备份系统怎么做
现在不少企业把一部分业务放在公有云上，一部分留在自建机房，形成了混合云架构，备份系统在这种架构下的难点在于：两边的数据格式、网络延迟、安全策略都不一样。
云上备份和本地备份要分开管理
公有云厂商都有自己的备份服务，比如快照、对象存储版本控制等，本地机房则可以用传统备份软件，两边各自备份之后，还要做一次跨云的数据同步,防止单一云服务商出问题。
备份数据出云要提前规划成本
云厂商对数据流出是收费的，而且是按量计费，如果业务需要把云上的备份数据拉回本地，这笔费用要提前算清楚，很多团队做到一半才发现成本失控,很被动。
多副本加离线归档是混合云备份的常见组合
实时数据在云上做多副本，定期把不再频繁访问的冷数据归档到本地离线存储，这样既控制了云上存储成本，又有了本地的一份物理隔离备份，数据安全性上，比起单靠云厂商的多副本,多了物理隔离的一层保障。
分布式备份系统选型时容易踩的坑
选型这东西，没有最好的方案，只有最合适的，但有几个坑是普遍存在的,提出来给大家避避雷。
盲目追求强一致性
强一致性意味着写入要等多数派确认，延迟肯定比单节点高，如果业务对实时性极其敏感，比如高频交易系统，强一致性带来的延迟可能无法接受,这时候就要考虑最终一致性加上异步补偿机制。
忽略小文件备份的性能问题
分布式系统对海量小文件的备份一直是个头疼的问题，文件数量一多，元数据操作的开销会拖垮整个备份效率，业内专家指出，小文件场景下,打包归档再传输往往比逐个文件备份高效得多。
备份系统本身的安全性被忽视
备份系统存储着全量数据，是攻击者的重点目标，很多团队对备份系统的访问控制做得比生产系统还松，这等于把家底亮给了别人，备份系统的网络隔离、访问审计、加密存储,一样都不能少。
备份系统数据常见问题解答
数据库备份的三种方式可以混合使用吗？
可以，很多团队的实际做法是：周末做一次全量备份，每天做一次差异备份，每几个小时做一次增量备份，这样既控制了备份时间，又保证了恢复时不会丢太多数据,具体节奏根据数据变更频率和恢复目标来定。
分布式备份系统数据恢复时，如何确认备份文件没问题？
恢复前先检查备份文件的校验和，再在隔离环境里做一次试恢复，跑几个核心查询验证数据完整性，确认没问题后再切正式环境，不要直接拿备份文件覆盖生产环境,万一备份本身有问题就麻烦了。
跨地域容灾的成本太高，小团队有必要做吗？
如果预算有限，至少要做到同城双机房，或者云上多可用区部署，成本可控，又能避免单机房故障导致全盘皆输，跨地域的级别,可以等业务规模上来之后再加。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/567606.html
