引言
图数据库的备份比关系库更难做对，原因有三个：一是图数据「节点与关系」耦合紧密，单独备份节点表或关系表都不可用；二是图库通常要求全量数据常驻内存，恢复时的加载时间远超关系库；三是集群形态下存在多个副本，备份哪个、怎么保证一致，都直接影响能不能恢复。更现实的问题是——很多团队的备份「存在但没验证过」，直到真出事才发现备份文件损坏、恢复流程缺步骤、恢复耗时远超预期。本文把备份与容灾拆成一条完整链路：先讲备份的语义与目标（RTO 与 RPO 怎么定）、在线备份与一致性快照、增量备份与事务日志、store copy 与离线备份、集群备份与快照协调、恢复流程与数据校验、跨区域容灾架构、恢复演练与故障切换、备份监控与保留合规，最后是策略权衡与常见坑。目标：你不仅能备份，还能证明「备份真的能恢复」。
目录
- 1. 备份的语义与目标：RTO 与 RPO
- 2. 在线备份与一致性快照
- 3. 增量备份与事务日志
- 4. store copy 与离线备份
- 5. 集群备份与快照协调
- 6. 恢复流程与数据校验
- 7. 跨区域容灾架构
- 8. 恢复演练与故障切换
- 9. 备份监控、保留与合规
- 10. 策略权衡与常见坑
- 速查表
- 延伸阅读
1. 备份的语义与目标：RTO 与 RPO
两个必须量化的指标：
RPO（Recovery Point Objective）：能容忍丢多少数据（时间维度）
例：RPO = 5 分钟 → 最坏丢最近 5 分钟写入
RTO（Recovery Time Objective）：能容忍停多久
例：RTO = 30 分钟 → 从故障到恢复服务不超过 30 分钟
→ 不谈 RTO/RPO 的备份方案 = 没有方案
RTO/RPO 与成本的对应关系：
| RPO 目标 | 需要的手段 | RTO 目标 | 需要的手段 |
|---|---|---|---|
| 小时级 | 定期全量备份 | 小时级 | 单机恢复 |
| 分钟级 | 增量 + 日志回放 | 分钟级 | 热备 + 快速切换 |
| 秒级 | 同步复制 | 秒级 | 双活 + 自动故障转移 |
| 接近零 | 同步多副本 | 接近零 | 多活 + 全局路由 |
为什么图库的 RTO 往往被低估：
- 图数据恢复后要「全量加载进内存」才达到可用性能
- 大图的加载时间可能是小时级（不是分钟级）
- 索引重建（全文/向量）额外耗时
- 恢复后还需预热 page cache 才有正常性能
→ RTO 要按「恢复到可用性能」算，不是「进程起来」算
备份的三个层次：
1. 数据备份：能恢复到某个时间点（正确性）
2. 流程备份：有文档化的恢复步骤（可执行性）
3. 演练备份：定期验证恢复成功（可信性）
→ 只有第 3 层才叫「真的能恢复」
心智：备份方案必须先量化 RTO（停多久）与 RPO（丢多少），两者直接决定技术选型与成本——RPO 小时级用定期全量、分钟级用增量加日志、秒级用同步复制；图库的 RTO 要按「恢复到可用性能」计算（全量加载进内存 + 索引重建 + 缓存预热往往小时级），别只算「进程起来」；备份分三层（数据、流程、演练），只有演练过的才叫能恢复。
2. 在线备份与一致性快照
在线备份的核心要求：一致性：
- 备份过程中仍有写入 → 备份出来可能是「半个事务」
- 图数据尤其敏感：节点写了但关系没写 → 图结构破损
- 一致性快照：备份的是「某一瞬间的完整状态」
→ 在线备份 = 不停机 + 保证一致性
一致性快照的实现机制：
机制 1：事务一致性快照（记录事务边界，备份边界前的已提交数据）
机制 2：写时复制（被修改的页写新位置，备份读旧位置）
机制 3：文件系统快照（LVM / 云盘原子快照 + 数据库 flush）
→ 数据库层 + 存储层配合，才能既不停机又一致
Neo4j 在线备份命令：
# 全量在线备份（5.x 使用 neo4j-admin database backup）
neo4j-admin database backup neo4j \
--to-path=/backup/neo4j \
--pagecache=4G \
--verbose
# 备份到指定位置并保留最近 N 份
neo4j-admin database backup neo4j \
--to-path=/backup/neo4j \
--keep-old-backups=3
备份过程中的写入影响：
- 在线备份会占用 IO 与 page cache，需限制资源
- 建议：在只读副本上备份（不干扰主库写入）
- 备份窗口避开业务高峰；大图备份可能持续数小时
→ 生产首选「只读副本 + 在线备份」，准热备兼顾一致性与低干扰
心智：在线备份的核心是一致性快照，机制有事务一致性快照、写时复制、文件系统快照三类，通常数据库层与存储层配合；生产首选「在只读副本上做在线备份」，既不停主库写入又保证一致；备份会占 IO 与 page cache，要限资源、避高峰、监控进度；恢复后必须做图结构完整性校验。
3. 增量备份与事务日志
为什么需要增量：
- 全量备份：窗口长、存储大（大图可能几百 GB 到 TB）
- 日增量通常远小于全量（几 GB）
- 全量 + 增量 + 日志 = 兼顾窗口与 RPO
→ 备份策略 = 全量打底 + 增量补充 + 日志兜底
三层备份体系：
周级全量：每周一次完整备份（打底，恢复起点）
日级增量：每天备份「自上次以来的变化」（缩小窗口）
连续日志：持续归档事务日志（把 RPO 压到分钟级）
→ 恢复 = 最近全量 + 增量链 + 日志回放到目标时间点
增量备份的两种实现：
实现 A：差异备份（自上次全量的变化）
- 恢复快（全量 + 一份差异）
- 但差异会随时间变大
实现 B：增量链（自上次任意备份的变化）
- 每份都小、窗口短
- 但恢复要重放整条链，链断则不可恢复
→ 折中：全量 + 若干增量 + 定期新全量「打断链」
事务日志与时间点恢复（PITR）：
- 事务日志记录每一次提交
- 恢复时先还原全量，再回放日志到指定时间点
- 支持「恢复到误操作之前」（如误删前的 1 分钟）
- 前提：日志连续、未损坏、归档及时
→ PITR 是应对「逻辑错误」的唯一手段
日志归档的监控要点：
- 归档延迟（日志生成到落盘的时延）
- 归档缺口（是否有未归档的日志段）
- 归档存储空间（避免写满导致归档停止）
→ 日志归档中断 = RPO 立刻劣化
心智：三层备份体系：周级全量打底、日级增量缩窗口、连续日志归档把 RPO 压到分钟级，恢复等于「最近全量 + 增量链 + 日志回放到目标时间点」；增量有两种实现（差异备份恢复快但会变大、增量链每份小但恢复要重放整链），折中是全量加若干增量加定期新全量打断链；PITR 是对付逻辑错误（误删/误更新）的唯一手段，前提是日志连续未损坏；日志归档延迟与缺口必须监控，归档中断等于 RPO 立即劣化。
4. store copy 与离线备份
store copy 的定位：
- store copy 是「一致性数据目录的复制」，常用于：
1) 从副本复制数据到新节点（扩缩容）
2) 快速搭建测试/分析环境
3) 作为全量备份的另一种形式
- 特点是「快」（不经过导出导入），但要求源端一致
→ store copy 是运维工具，也是备份的底层能力
Neo4j store copy 命令：
# 从运行中的实例复制一致性 store（在线）
neo4j-admin database copy neo4j \
--from-path=/data/neo4j \
--to-path=/backup/neo4j-copy
# 从备份集复制为数据库
neo4j-admin database copy neo4j \
--from-path=/backup/neo4j/neo4j-2026-10-01 \
--to-path=/data/neo4j-new
离线备份的适用场景：
- 允许停机的维护窗口
- 数据库处于异常状态，在线备份不可靠时
- 需要「绝对一致」的归档副本
- 迁移到新版本前的保险副本
→ 离线备份简单可靠，但不满足低 RTO
离线备份的正确姿势：
1. 优雅停止数据库（避免半写状态）
2. 复制整个数据目录（含 store 与事务日志）
3. 记录版本号、配置、备份时间
4. 校验文件完整性（校验和）
5. 启动数据库验证可用
→ 「停机 + 完整目录复制 + 校验 + 验证启动」
备份集的组织与元数据：
/backup/neo4j/
neo4j-2026-10-01T02-00/ # 全量
metadata.json # 版本、时间、校验和
store/ # 数据文件
neo4j-2026-10-02T02-00-inc/ # 增量
logs/ # 归档日志
→ 元数据是恢复的「说明书」，必须有
校验和的生成与验证：
find /backup/neo4j/neo4j-2026-10-01T02-00 -type f -exec sha256sum {} \; \
> /backup/neo4j/neo4j-2026-10-01T02-00.sha256
sha256sum -c /backup/neo4j/neo4j-2026-10-01T02-00.sha256 # 验证
心智：store copy 是「一致性数据目录复制」，用于扩缩容、搭测试环境、作为全量备份的另一种形式，特点是快但要求源端一致；离线备份适合停机窗口与异常状态，姿势是「优雅停机 + 完整目录复制（含事务日志）+ 校验和 + 验证启动」；只备份图存储不备份日志就无法 PITR；备份集必须有元数据（版本/时间/校验和）作为恢复说明书。
5. 集群备份与快照协调
集群备份的特殊问题：
- 多副本：备份哪个？备份主还是备？
- 一致性：主备之间可能有复制延迟
- 快照协调：多个节点同一时刻的快照才对得上
- 恢复语义：恢复到集群还是单机？
→ 集群备份比单机备份多一层「协调」问题
集群备份的三种策略：
策略 A：只备主节点
- 简单，但主节点压力大
策略 B：备一个只读副本（推荐）
- 不影响主库，一致性由副本的复制状态决定
- 需确认副本已追平（无复制延迟）
策略 C：全集群一致性快照
- 各节点同刻快照，用于「整集群恢复到某时刻」
- 协调成本高，需要集群级快照工具
→ 常规备份用 B，灾难恢复到特定时刻用 C
复制延迟对备份的影响：
// 备份前确认副本已追平（示例：检查最后事务 ID）
CALL dbms.listTransactions() YIELD currentQuery, status
RETURN currentQuery, status
// 或用监控指标确认复制延迟为 0
SHOW DATABASES YIELD name, currentStatus, lastCommittedTxn
- 若副本滞后 10 分钟，从副本备份 = RPO 至少 10 分钟
- 备份前必须确认「复制延迟已归零」
- 记录备份时的最后事务 ID，便于恢复对齐
→ 备份点 = 副本的当前状态，不是主库的
集群快照协调的实现：
1. 冻结写入（只读维护模式）→ 2. 各节点触发存储层原子快照
3. 记录各节点最后事务 ID → 4. 解冻写入 → 5. 校验事务 ID 是否一致
→ 一致性快照的代价是「短暂只读窗口」
云托管服务的备份差异与恢复目标：
托管服务：提供「自动备份 + 时间点恢复」，但可能不覆盖插件与自定义配置
→ 配置与脚本仍需自己版本化备份
恢复目标：优先「新集群」（安全），单机实例用于演练与取数
→ 避免「直接覆盖现有节点」，失败会把生产一起搞坏
心智：集群备份的核心是「备份哪个 + 怎么一致」——常规用「备一个已追平的只读副本」（备份前必须确认复制延迟归零，备份点等于副本当前状态而非主库），灾难恢复到特定时刻用「全集群一致性快照」（需短暂只读窗口 + 各节点事务 ID 对齐）；托管服务的自动备份不覆盖插件与自定义配置，配置与脚本仍需自己版本化；恢复目标优先「新集群」而非「改现有节点」。
6. 恢复流程与数据校验
恢复的三种场景：
场景 1：单点故障 → 用副本接管（不涉及备份恢复）
场景 2：数据损坏/误删 → 用备份 + 日志恢复到时间点
场景 3：区域故障 → 用跨区域备份在新区域重建
→ 不同场景的恢复流程不同，都要有文档
恢复流程的标准步骤：
1. 确定恢复目标（恢复到哪个时间点）
2. 准备目标实例（新集群 / 新节点，版本匹配）
3. 还原最近全量备份
4. 依次重放增量备份（按链顺序）
5. 回放事务日志到目标时间点（PITR）
6. 启动数据库，做完整性校验
7. 预热缓存，验证性能
8. 切换流量（DNS / 连接串 / 路由）
9. 记录恢复耗时（用于校准 RTO）
→ 步骤要写成可执行的 runbook，不是「凭记忆」
恢复命令示例：
neo4j-admin database restore neo4j \
--from-path=/backup/neo4j/neo4j-2026-10-01T02-00 --to-path=/data/neo4j
neo4j-admin database restore neo4j \
--from-path=/backup/neo4j/neo4j-2026-10-02T02-00-inc \
--to-path=/data/neo4j --additional # 追加增量（按顺序）
neo4j-admin database restore neo4j \
--from-path=/backup/neo4j/logs --to-path=/data/neo4j --recovery # 回放日志
恢复后的校验清单：
MATCH (n) RETURN count(n) AS 节点总数
MATCH ()-[r]->() RETURN count(r) AS 关系总数
SHOW CONSTRAINTS YIELD name, type
SHOW INDEXES YIELD name, state, type
MATCH (a:Account {id:'A001'})-[:TRANSFER]->(b) RETURN count(b) AS 转出笔数
校验的三个层次：
1. 文件级：备份文件校验和一致
2. 结构级：节点/关系/索引数量与约束齐全
3. 业务级：关键查询结果与源库一致
→ 只有第 3 层能证明「业务可用」
恢复失败的常见原因：
版本不匹配 / 增量链断裂 / 日志归档缺口 / 磁盘空间不足 / 插件配置缺失
→ 每次失败都要回写 runbook
心智：恢复要区分三种场景（单点故障用副本接管、数据损坏用备份加日志 PITR、区域故障用跨区域重建），每种都有文档化 runbook 而非凭记忆；标准步骤是「定目标时间点 → 准备实例 → 还原全量 → 重放增量 → 回放日志 → 启动校验 → 预热 → 切流量 → 记录耗时」；校验分文件级、结构级、业务级三层，只有业务级能证明可用；失败常见原因是版本不匹配、增量链断裂、日志缺口、空间不足、插件缺失。
7. 跨区域容灾架构
三种容灾拓扑：
主备（Active-Standby）：
- 主区域服务，备区域接收复制数据
- 故障时切到备区域（RTO 分钟到小时）
- 成本中等，实现简单
双活（Active-Active）：
- 两区域同时服务（读多写少场景）
- 写入需要跨区域一致性协调
- 成本高，复杂度高
多活（Multi-Active）：
- 多区域同时读写，靠分区或冲突解决
- 图数据跨区域多写冲突解决极难
- 通常只用于「按用户分区」的场景
→ 图库多数用主备，读扩展用只读副本
跨区域复制的两种模式：
同步复制：
- 写入需等远端确认 → RPO 接近 0
- 跨区域延迟（几十 ms）直接加到写入延迟上
- 通常限制在「同城双活」范围
异步复制：
- 写入本地确认后异步复制 → 延迟低
- RPO = 复制延迟（可能秒级到分钟级）
- 适合「跨区域」的远距离场景
→ 同城同步、异地异步是常见组合
跨区域容灾的关键设计点：
- 数据同步：异步复制 + 定期校验一致性
- 切换决策：自动还是手动（自动需防「脑裂」）
- 流量路由：DNS 切换 / 全局负载均衡 / 连接串切换
- 数据回切：故障恢复后如何把数据同步回去
- 成本：备用区域长期空转的成本
→ 切换容易，回切难，回切方案要提前设计
脑裂（Split-Brain）的防范：
- 跨区域网络分区时，两边都以为对方挂了
- 防范：仲裁节点（Witness）、多数派投票、租约（Lease）
- 原则：宁可「一边停止服务」，也不要「两边都写」
→ 图数据多写冲突几乎无法自动合并，必须防脑裂
RTO/RPO 与拓扑的对应：
| 拓扑 | 典型 RPO | 典型 RTO | 成本 |
|---|---|---|---|
| 单区域多副本 | 0（同步） | 秒级（自动切换） | 低 |
| 同城双活 | 接近 0 | 分钟级 | 中 |
| 异地主备（异步） | 秒到分钟 | 十分钟到小时 | 中高 |
| 异地双活 | 接近 0 | 分钟级 | 高 |
心智：跨区域容灾有三类拓扑（主备、双活、多活），图库多数用主备、读扩展用只读副本；复制模式上「同城同步、异地异步」是常见组合，同步复制把跨区域延迟加进写入路径；关键设计点是数据同步、切换决策、流量路由、回切方案（切易回难）、成本；必须防脑裂（仲裁/多数派/租约，宁停一边不双写）；副本解决物理故障、备份解决逻辑错误，两者不可互相替代。
8. 恢复演练与故障切换
为什么演练是必须的：
- 未演练的备份 = 未知状态（可能根本恢复不了）
- 演练能暴露：文档缺步骤、版本不匹配、空间不足、权限缺失
- 演练能校准 RTO（实际耗时 vs 目标）
→ 演练是「备份可信」的唯一证据
演练的三个层次：
L1 恢复演练（恢复数据可用）→ L2 切换演练（流量切到备区域）
→ L3 全链路演练（含告警、决策、回切）；频率递减（月/季/半年）
演练脚本化的示例：
#!/usr/bin/env bash
set -euo pipefail
RESTORE_DIR="/drill/neo4j-$(date +%Y%m%dT%H%M%S)"
neo4j-admin database restore neo4j --from-path=/backup/neo4j/latest --to-path="$RESTORE_DIR"
neo4j start --home-dir="$RESTORE_DIR"
until cypher-shell -a bolt://localhost:7687 "RETURN 1" >/dev/null 2>&1; do sleep 5; done
cypher-shell -a bolt://localhost:7687 -f /drill/verify.cypher
echo "drill done at $(date -Iseconds)"
演练要记录与产出的东西：
- 实际 RTO（从决策到服务可用）
- 实际 RPO（恢复点与故障点的时间差）
- 遇到的阻塞点与解决办法
- runbook 的修正项
- 参与人、时间、结论
→ 演练的产出是「改进后的 runbook」，不是「一次成功记录」
故障切换的决策流程：
1. 检测：监控告警（可用性、复制延迟、错误率）
2. 确认：人工或自动确认故障范围（防误切）
3. 决策：是否切换（成本 vs 影响）
4. 执行：按 runbook 切换（预演过的步骤）
5. 验证：服务可用 + 数据正确
6. 复盘：根因分析 + runbook 更新
→ 「自动切换」只在演练充分后才启用
回切方案的设计：
- 原区域恢复后，数据已「落后」于备区域
- 回切前需把备区域的新数据同步回原区域
- 双向同步期间要防止写入冲突（先停一边写）
- 回切同样是一次「切换」，需要演练
→ 回切比切换更复杂，必须提前设计
心智：未演练的备份等于未知状态，演练分三层（恢复演练 L1、切换演练 L2、全链路演练 L3），频率递减但都要做；演练必须脚本化并产出「修正后的 runbook + 实际 RTO/RPO 数据」；故障切换流程是「检测 → 确认 → 决策 → 执行 → 验证 → 复盘」，自动切换只在演练充分后启用；回切比切换更复杂（需把备区新数据同步回去、防写入冲突），必须提前设计并演练。
9. 备份监控、保留与合规
备份的监控指标：
- 备份成功率（最近 N 次是否都成功）
- 备份耗时（是否超出窗口）
- 备份大小变化（突变可能意味着异常）
- 备份年龄（最新备份距今多久，超期告警）
- 恢复演练结果（最近一次演练是否通过）
→ 「备份失败」与「备份过期」都要告警
监控告警示例：
规则 1：最近一次成功全量备份距今 > 26 小时 → 告警
规则 2：备份任务失败连续 2 次 → 告警
规则 3：备份文件大小环比变化 > 30% → 告警
规则 4：日志归档延迟 > 5 分钟 → 紧急告警（RPO 劣化）
规则 5：最近一次恢复演练距今 > 90 天 → 提醒
保留策略的设计：
GFS 策略（Grandfather-Father-Son）：
- 保留最近 7 份日备、4 份周备、12 份月备
- 合规要求更长的按需延长
→ 保留策略由「RPO 需求 + 合规要求 + 成本」共同决定
GFS 策略（Grandfather-Father-Son）：
- 保留最近 7 份日备
- 保留最近 4 份周备
- 保留最近 12 份月备
- 合规要求更长的按需延长
→ 保留策略由「RPO 需求 + 合规要求 + 成本」共同决定
保留策略与恢复能力的关系：
- 保留期决定「能恢复到多久之前」；保留太短则发现数据错误时已无备份可用
- 折中：日备短保留、周月备长保留、关键节点额外保留
→ 「数据错误发现得越晚，需要的保留期越长」
合规与安全要求：
- 加密：备份文件静态加密（至少 AES-256）
- 访问控制：备份目录权限隔离（不是所有人可读）
- 异地：至少一份备份在异地（防区域灾难）
- 不可变：防勒索软件（WORM / 对象锁）
- 审计：备份与恢复操作的完整审计日志
→ 备份本身是高价值目标，必须保护
成本优化：
- 分层存储：近期备份用高性能存储，远期用归档存储
- 压缩与去重：备份文件压缩可省 50% 以上
- 生命周期策略：自动转冷/删除
- 定期清理：孤儿备份、失败的临时文件
→ 成本优化不能牺牲「可恢复性」
心智：备份监控要覆盖成功率、耗时、大小突变、备份年龄、演练结果，其中「日志归档延迟」是 RPO 劣化的最紧急告警；保留策略用 GFS（日/周/月），保留期由 RPO 需求、合规要求、成本共同决定，核心原则是「数据错误发现得越晚，需要的保留期越长」；备份是高价值攻击目标，必须加密、隔离权限、异地存放、不可变（防勒索）、全操作审计；成本优化靠分层存储、压缩去重、生命周期策略，但不能牺牲可恢复性。
10. 策略权衡与常见坑
备份策略的设计模板：
目标：RPO ≤ 5 分钟，RTO ≤ 30 分钟
手段：每日全量（保留 7 天 + 异地 1 份）+ 每小时增量
+ 事务日志连续归档（压缩加密）+ 只读副本实时复制
+ 每季度恢复演练 + 每半年切换演练
验证：备份成功率 100% 才算当日有备份；演练通过才算「可恢复」
常见坑清单：
坑 1：备份了但从没恢复过 → 真出事才发现恢复不了
坑 2：只备份数据目录，不备份事务日志 → 无法 PITR
坑 3：从有复制延迟的副本备份 → RPO 实际比预期差很多
坑 4：增量链断裂（缺一份）→ 整条链不可恢复
坑 5：备份未加密/未隔离权限 → 备份成为泄露入口
坑 6：备份与生产在同一区域 → 区域故障时一起丢
坑 7：保留期太短 → 发现数据错误时已无备份可用
坑 8：RTO 只算「进程起来」不算「加载进内存」→ 实际超时数倍
坑 9：没有回切方案 → 切换后回不去，长期跑在备用区域
坑 10：备份任务静默失败无告警 → 数周无有效备份
坑 11：恢复用「现有集群覆盖」→ 恢复失败把生产也搞坏
坑 12：备份脚本与 runbook 未版本化 → 人员变动后无法执行
恢复能力的自查清单：
[ ] 有明确的 RTO/RPO 目标且被业务确认
[ ] 全量 + 增量 + 日志归档三层齐全
[ ] 备份加密、权限隔离、异地存放、不可变
[ ] 备份成功率与备份年龄有监控告警
[ ] 恢复 runbook 文档化且版本化
[ ] 每季度恢复演练、每半年切换演练
[ ] 回切方案已设计并演练
[ ] 演练产出「实际 RTO/RPO」并回写 runbook
「能恢复」的三个证明：
证明 1：备份文件完整（校验和通过）
证明 2：恢复流程可执行（演练跑通）
证明 3：恢复后业务可用（业务级校验通过）
→ 三者齐备，才敢说「我们的图数据能恢复」
心智：备份策略设计从「目标 RPO/RTO」出发，反推手段（全量 + 增量 + 日志 + 副本 + 演练）并逐条验证；十二个坑集中在四处——没演练过、依赖缺失（日志/增量链/副本延迟）、保护不足（未加密/同区域/保留短）、流程缺陷（RTO 口径错、无回切、静默失败、覆盖生产）；「能恢复」需要三个证明：文件完整、流程可执行、业务可用。
速查表
指标与手段对照：
| RPO | 手段 | RTO | 手段 |
|---|---|---|---|
| 小时级 | 定期全量 | 小时级 | 单机恢复 |
| 分钟级 | 增量 + 日志 | 分钟级 | 热备切换 |
| 秒级 | 同步复制 | 秒级 | 双活自动切换 |
| 接近零 | 同步多副本 | 接近零 | 多活路由 |
备份体系速记：
周级全量（打底）+ 日级增量（缩窗口）+ 日志归档（压 RPO）
恢复 = 最近全量 + 增量链 + 日志回放到目标时间点
演练 = L1 恢复 + L2 切换 + L3 全链路
常见坑速记：
没演练 / 缺日志 / 副本延迟 / 链断裂 / 未加密
同区域 / 保留短 / RTO 口径错 / 无回切 / 静默失败
覆盖生产 / 脚本未版本化
一句话记忆：图数据库备份容灾的第一原则是「先量化 RTO/RPO 再选技术」，且 RTO 要按「恢复到可用性能」计算——图数据全量加载进内存加索引重建加缓存预热往往是小时级，不是「进程起来」的秒级；备份体系是三层（周级全量打底、日级增量缩窗口、连续日志归档把 RPO 压到分钟级），恢复等于「最近全量 + 增量链 + 日志回放到目标时间点」，其中 PITR 是应对误删等逻辑错误的唯一手段，副本只能解决物理故障、两者不可互相替代；集群备份首选「已追平的只读副本」（备份前确认复制延迟归零，备份点等于副本当前状态），灾难恢复到特定时刻用全集群一致性快照；跨区域容灾按「同城同步、异地异步」组合，必须防脑裂（仲裁/多数派/租约，宁停一边不双写），切换容易回切难，回切方案要提前设计；备份必须加密、隔离权限、异地存放、不可变（防勒索）、全操作审计，因为备份本身是高价值攻击目标；最后，未演练的备份等于未知状态——用 L1 恢复、L2 切换、L3 全链路三层演练，产出「实际 RTO/RPO + 修正后的 runbook」，用「文件完整、流程可执行、业务可用」三个证明，才敢说图数据真的能恢复。
延伸阅读
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。