图数据库备份恢复怎么做？RPO 与 RTO 该怎么定

灾备方案评审表送到会上，RPO 那一格填的是 0，RTO 那一格填的是「分钟级」。两格填完，方案就过了。没有人问这两个数是怎么来的，因为它们看起来不像需要论证的东西——0 已经很保守了，还能更保守吗？换成图数据库的备份恢复方案，这格填法一模一样，问题也一模一样。

这类讨论经常停在这一层，原因是它看起来像一道运维题，实际先是一道业务题——备份恢复要回答的从来不是「多久备一次」，而是「丢多少、停多久，业务才不至于出局」。运维能算出恢复要多久，算不出「停两个小时值多少钱」；业务能算出停两个小时值多少钱，不知道自己最多能接受丢多长的数据。两个数都定不下来，方案就只能在「全量备份每天一次」这个默认值上打转。

一、RPO 与 RTO 不是技术指标，是两份要签字的承诺

RPO 问的是最多能接受丢多长时间的数据，落点在数据；RTO 问的是最多能接受停多长时间，落点在服务。两个指标的签字人应该是业务方，运维只负责把它们翻译成架构。

「0」是最常见也最危险的答案。它把方案直接锁死在同步复制上：每次写入都要等到对端确认才返回，写延迟从此由一个网络往返决定，同城机房之间几毫秒，跨城部署就是十几毫秒起步。延迟还只是账面上一半的代价，另一半在吞吐——批量写入时每一批都在等最慢的那次确认，导入作业的时长会被拉长到另一个量级。

图数据库在这件事上比单表写入更敏感。写一个点往往要连带它的边，一次导入动的是大量邻接关系，同步复制的开销按边数放大，而不是按记录数放大。所以在关系型数据库上跑得动的同步方案，搬到图上常常要重新算一遍。

「分钟级」的问题正好相反：它太空。空到无法验收。分钟级是 1 分钟还是 59 分钟？这个区间里差了整整一个数量级，对应的架构一个用异步复制就够了，另一个得上同步加多副本。

指标的意义不在数字大小，在它能不能被验收。 一个没法验收的 RPO，等于没有 RPO。

二、四个数要一起定，只定两个必然留缺口

RPO 和 RTO 单独拿出来定，几乎一定会定错，因为缺了约束它们的那两个数。

指标	回答什么问题	该由谁定	怎么验收
RPO	最多丢多长时间的数据	业务方	按数据分级逐类核对备份间隔
RTO	最多停多长时间的服务	业务方，运维给成本	真实演练逐段计时后加总
MTPD	中断超过多久业务就无法维持	业务方	与 RTO 比较，RTO 必须明显小于它
恢复一致性口径	恢复后允许不一致到什么程度	业务加审计	点数、边数、n 跳邻居分布三项比对

MTPD 是四个数里最少被写进方案的那个。它指的是业务能撑住的最长中断——超过这个时长，损失就不再是收入减少，而是客户流失、监管上报、合同违约这类不可逆的事。RTO 必须留出余量小于 MTPD，两者贴得太近，等于把方案放在悬崖边上：只要演练比你预估的慢二十分钟，就已经越过线了。

第四个数的必要性在图数据库上比在关系型上更明显。关系型的恢复校验有个默认答案——行数对得上、主键不重复，基本就敢接流量。图上不行，后面第六节会细说。容灾与备份这类能力的评估口径本身也值得单独拉一张表来对，企业级图数据库容灾能力怎么评估给过一套按场景覆盖度打分的做法，可以拿来当本节的补充。

这里有一句判断值得单独记住：RPO 由备份方式决定，RTO 由恢复演练决定。 备份做得好，只证明前者。

三、RPO 怎么定：看这份数据能不能重算、重算要多久

全库一个 RPO 是最省事也最贵的做法。属性图里的数据天然分三层，三层的可恢复性完全不同。

数据类别	丢了会怎样	能否重算	建议口径
核心实体与主数据（点类型、关键点、标识关系）	关系网要从零重建，重建成本不可估	不能	间隔最短，优先保障
业务事实边（交易、持股、通话、工单）	可回源系统重建，但回源窗口通常有限	有条件，取决于源系统留多久	覆盖源系统保留期的最长间隔
派生结果（向量索引、全文索引、社区划分、中心性分数）	查询变慢或标签失效，数据本身没消失	能，耗时取决于规模	可不备，但要能重算
图算法中间态与临时结果	无实际影响	能	不需要备份

第三行的判断是这套分级里最容易被做错的地方。向量索引、全文索引、社区划分结果、PageRank 分数都是算出来的，不是源数据；把千万级点的向量索引纳入每小时一次的备份，做了一件很贵但没什么用的事，还会把备份窗口撑爆。

但这里有个例外，而且很关键：一旦算法结果被下游直接消费，它就获得了业务语义，必须备。 社区标签进了规则引擎、中心性分数进了排序、图嵌入被推荐系统当特征读——这时候它就不再是「能重算的中间产物」，而是一份别人正在依赖的数据，丢了要等重算完才能恢复业务。

一条判据：这份数据能不能从别处重算出完全一样的结果，以及重算要多久。 重算要 4 小时，RPO 就不能定得比 4 小时更长——否则恢复完成之后只有两个选择：干等 4 小时，或者先拿一份过时的标签上线。前者把 RTO 拉长了 4 小时，后者把事故延长成了数据事故。

还有一个常见误解要澄清：多副本不能替代备份。副本是同一份数据的多个拷贝，误删会在秒级同步到所有副本上；副本解决的是节点和磁盘故障，不解决「数据被正确写入但是写错了」。这两件事的防御手段完全不同。

四、RTO 怎么定：拆成五段，逐段要数

RTO 不是「数据库起来了」的时间，是「业务能对外服务」的时间。中间隔着五段，每段都有各自的账。

阶段	包含什么	常被漏掉的部分
发现	从故障发生到有人确认	深夜无人值守，报警只发到群里
决策	判定要不要切换或恢复	谁有权决定？没有授权表就得开会
准备	找到介质、集群配置、版本信息	备份文件在，恢复脚本和凭据不在
恢复	装载数据、重建索引、校验	索引与向量索引重建，往往比装载慢
验证与接流	抽样校验、放流量、观察	一把全放还是灰度放

第四段是最容易系统性低估的一段。装载点边数据只是开始，索引重建是独立的一段耗时：全文索引要在全量点上重建分词结构，向量索引要在全量向量上重建邻接图，两者在千万级规模上花掉的时间经常超过数据装载本身。而绝大多数演练记录只写到「数据恢复完成」，索引重建被算在「系统起来之后慢慢建」里——上线后发现查询走的是全表扫描，这个阶段的表现比停机还难看。

第二段是另一个隐形部分，而且它不在任何技术指标里。判定故障、召集决策、拿到授权，这一串动作走完可能四十分钟，也可能四个小时，取决于有没有提前写好「哪种故障由谁在几分钟内决定切换」。这段耗时演练里通常不计，真出事时全额计入。

没做过真实演练的 RTO，都是猜的。 而且猜的方向几乎总是乐观，因为人估算自己没做过的操作时，会默认一切顺利。

五、备份方式和恢复方式要配对，配错了照样救不回来

三种常见组合，各自的适用条件和死角都不一样。

组合	实际 RPO	恢复粒度	主要代价	死在什么场景
周期性全量快照	等于周期长度	集群或库级	存储占用大、备份窗口长	RPO 要求小时以内
全量加快照加增量链	等于增量间隔	集群或库级、可到时间点	需保证增量链不断	增量链断了一环，链条之后全部失效
跨集群实时同步	秒级	集群级	常驻资源与写延迟	人为误删会在秒级同步过去

第三行是很多方案里唯一的防线，也是最容易被误当成万能的一行。实时同步防的是硬件故障和机房故障，它防不了逻辑错误：一条误删的语句在写进主集群的同时就写进了备集群，RPO 表现得完美——只丢了几秒——但你回不到删除之前，因为两份数据都是删完的状态。

同步复制管可用性，快照和增量链管可回退。 只有复制没有快照的系统，面对误删是零防御。反过来只有快照没有复制，面对机房故障就要停几个小时。这两件事必须同时具备，不能互相折算。

还有一层容易被混淆：同城双活、异地容灾这类部署形态解决的是前者，同城双活与异地容灾分别需要哪些能力把两类形态的门槛拆得比较细，这里只强调一点：容灾形态不改变备份策略的必要性，两者是并联关系，不是替代关系。

图数据库还有一个特性会让误删的代价放大：删一个点，挂在它上面的边一起消失，而这些边分散在多个分片、多个存储节点上。「恢复一个点」这件事在图里基本不成立，恢复粒度最小是库级或者一个一致的子图。所以图上的备份策略要比关系型更早想清楚「恢复到哪个时间点」，而不是想「恢复哪张表」。

悦数图数据库在高可用这一层提供的能力包括快照、全量备份与增量备份，以及两地三中心、三地五中心的容灾部署形态；存储层采用分布式键值存储，数据分片加多副本，配合存算分离与 Shared-Nothing 架构，让副本与计算节点可以分别扩缩。这些是能力清单，怎么组合仍然取决于前面定下来的四个数——先有指标，再选形态，顺序反过来就会变成「厂商有什么我们就买什么」。

六、验收：三个动作，缺一个都等于没做

第一个动作：恢复到另一个集群，不要覆盖生产。 覆盖式恢复演练没人敢在生产上做，所以永远不做，也就永远不知道真实耗时。恢复到一套独立的验证集群，代价是一份存储和几小时人力，换来的是一个可写进值班手册的数字。

第二个动作：校验要校验边，不只校验点。 点数对得上、边少了几百万，系统照样能启动，查询也照样返回结果——只是结果是错的。这种状态比起不来更危险，因为它不会报警。可以照着三项做：按点类型统计点数；按边类型统计边数；抽样若干点，比对它们一到三跳的邻居数量分布与备份时刻的基线。第三项是图特有的，关系型没有对应物，它能抓出「点齐了但关系断了」这类最难发现的残缺。

第三个动作：记三个时间。 备份耗时决定备份窗口能不能压进业务低谷；恢复耗时决定 RTO 定的对不对；校验耗时最容易被忘，但它直接决定什么时候敢把流量放进来。

两个常见误区放在最后说。一是把备份任务的绿色勾当成备份有效——那个勾只证明文件写成功了，不证明文件能装回去。二是把 RPO、RTO 只写进方案不写进值班手册——真出事的时候，凌晨三点没人会去翻方案第十七页，值班的人只会照着手册做，手册里没有的步骤就等于不存在。

RPO 和 RTO 说到底不是一个数字，是两份承诺。定的时候从业务损失倒推，验的时候从恢复演练正推，中间那段差距就是必须补的工程量。想跳过这一步直接买方案，结果通常是方案很漂亮，演练永远排在下个季度。

相关阅读

常见问题（FAQ）

Q1：悦数图数据库是一款什么样的产品？

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式图数据库，100% 自主可控，原生支持 ISO-GQL 国际标准，采用存算分离与 Shared-Nothing 架构，面向千亿点万亿边的规模承担关系数据的存储与查询。产品在高可用层面提供快照、全量备份与增量备份，支持两地三中心、三地五中心的容灾部署形态，并在存储层以分片加多副本保证数据持久性，同时提供多租户与细粒度权限管理，满足核心业务系统的运行要求。

Q2：已经做了同城双活，还需要单独做备份吗？

A：需要，因为两者防的不是同一类事。双活解决的是机房、节点、磁盘这类基础设施故障，业务在另一侧继续跑；备份解决的是数据本身被写错或被删掉，需要一个能回到过去某个时刻的副本。双活环境下误删会在秒级同步到对端，两份数据都变成删完的状态，这时候能救你的只有快照加增量链构成的时间点恢复。判断标准很直接：如果明天有人执行了一条错误的删除语句，你能不能回到删除前十分钟——能，才叫有备份。

Q3：备份和恢复会占用在线查询的资源吗？存算分离架构对此有什么帮助？

A：会有影响，但影响可以隔离。备份是重 IO 的顺序读，恢复是重 IO 的写入加索引重建，两者都会和在线查询抢带宽与内存。存算分离的价值在于计算与存储可以分别扩缩：备份期间可以临时增加存储侧吞吐而不动计算节点，恢复校验可以起一套独立的计算资源挂到同一份存储上做，不必挤占生产集群。悦数图数据库在这一层的积累也得到了外部认可——IDC《中国图数据库市场概览 2024》中位列中国市场第二位，并连续两年入选中国信通院图数据库「领航者」。具体的备份窗口怎么排、恢复集群怎么配，仍然建议先用一次真实演练拿到耗时数据再定，不同规模下的差异很大。