备份与灾难恢复

灾难恢复是一个谱系，而非单一的方案。影响范围决定了应对手段：丢失一个 follower，集群会自动消化、毫不受影响；丢失全部节点，则需要从外部备份冷启动。本页将每种故障模式映射到对应的补救措施，再对比两种备份策略——OSS Cluster Backup 与 Premium Cluster Standby——以便你根据自己的 RTO 和 RPO 选择合适的方案。

关于 recording、snapshot 和 recording log 在底层的实际工作原理，请参阅 The Aeron Files。本页聚焦于运维恢复。

灾难恢复场景，按严重程度排序

四种场景覆盖了现实中的故障空间，按严重程度排列：

场景	严重程度
Follower 节点丢失	低——集群继续运行，自动恢复
Leader 节点丢失	中——短暂选举，自动恢复
最新快照丢失	中——回退到更早的快照 + 更长的回放
全部节点丢失（仅数据库存活）	严重——需要完整重建

各场景的恢复方法

根据严重程度匹配补救手段。越往下，你越需要依赖工具和外部备份，而不是 Aeron 的内建机制。

1. Follower 丢失 → 重启该节点。它会通过 snapshot + log 回放自动从 leader 追平。
2. Leader 丢失 → 自动选举产生新的 leader。旧 leader 以 follower 身份重启并追平。
3. 快照丢失 → 使用 ClusterTool 检查 recording log，使损坏的快照失效，并回退到更早的快照，配合更长的 log 回放。
4. 全部节点丢失 → 从外部备份冷启动（来自 Archive 或 Cluster Backup/Standby 的 snapshot + log recording）。

关键洞察：严重程度直接映射到备份策略

从「follower 丢失」到「全部节点丢失」的递进，直接映射到你所需要的备份策略。对于 follower 和 leader 丢失，Aeron 的内建机制会自动完成恢复。对于快照丢失，你需要运维工具（ClusterTool）。对于全部节点丢失，你需要一套外部备份策略——OSS 用 Cluster Backup，Premium 用 Cluster Standby。每种具体故障模式的补救措施，都在相关的运维页面中详细说明。

Cluster Backup (OSS) 对比 Cluster Standby (Premium)

针对关键的「全部节点丢失」场景，你需要用外部备份来保护自己。有两个选择。最终的取舍可归结为一个词：热（warm）还是冷（cold）。

特性	Cluster Backup (OSS)	Cluster Standby (Premium)
可用性	开源（Apache 2.0）	Premium（商业）
用途	将 log 复制到远端位置以用于 DR	用实时 standby 节点扩展部署
节点状态	被动——不处理消息	主动——实时处理每一条消息
恢复速度	较慢——取决于快照新旧程度 + log 回放时长	较快——近乎即时切换，无需回放
故障切换时的数据丢失	较高——取决于最后一次备份同步点	极小——仅丢失传输中的未提交消息
恢复机制	通过 log 回放重建集群状态	翻转一个标志，将 standby 切换为 active
带宽灵活性	不可配置	可配置——单节点或全节点路由
对 Leader 的背压	若将远端节点加入集群，可能造成背压	对 leader 无背压
使用场景	在恢复时间可接受的前提下，防范整个 DC 丢失	以最小停机和数据丢失实现快速故障切换

决策框架

根据你的恢复目标和预算来选择：

需要快速故障切换（<60s）+ 最小数据丢失？  → Cluster Standby (Premium)
需要基础 DR 且恢复时间可接受？            → Cluster Backup (OSS)
预算受限但仍需要一定的 DR？               → Cluster Backup (OSS)
跨区域运行且 RPO/RTO 要求严格？           → Cluster Standby (Premium)

关键洞察：热与冷决定你的 RTO

根本区别在于热与冷。Cluster Standby 处理每一条消息（热），因此可以即时接管。Cluster Backup 只复制 recording（冷），因此必须回放 log 才能重建状态。对于撮合引擎而言，Cluster Backup 的回放时间可能是数分钟到数小时，取决于 log 大小——这对生产环境是无法接受的。Cluster Standby 的亚分钟级 RTO 才是生产级的选择。

详细对比

进一步深入，热与冷的区别体现在 license、复制、恢复和运维四个方面。ClusterStandby 随 premium jar 一同发布；ClusterBackup / ClusterBackupMediaDriver 则是 OSS。

License 与 API

	Cluster Standby (Premium)	ClusterBackup (OSS)
License	Aeron Premium（商业）	OSS（Apache 2.0）
API	ClusterStandby（premium jar）	ClusterBackup / ClusterBackupMediaDriver
Standby 类型	热——主动处理每一条消息	冷——复制 recording，在恢复时回放

复制与状态

	Cluster Standby	ClusterBackup
复制 snapshot recording	是（作为消息处理的一部分）	是（自动）
复制 log recording	是（作为消息处理的一部分）	是（自动）
在 standby 上运行 ClusteredService	是——处理每一条消息	否——仅 archive 级别的复制
Standby 状态与主集群一致	是——近乎实时	否——状态仅在 archive 中，不在内存中
持续同步（实时 log tailing）	是	是——保持在 BACKING_UP 状态
感知 Leader	是——跟随 leader 变更	是——查询集群共识

恢复特性

延迟的故事就在这里。Cluster Standby 的 RTO 近乎为零，因为状态已经在内存中——无需加载 snapshot，也无需回放 log。ClusterBackup 则要付出数分钟的代价，因为它必须复制数据并启动一个全新的集群。

	Cluster Standby	ClusterBackup
RTO	近乎为零——「设置一个标志」即可激活	数分钟——复制数据 + 启动集群
故障切换机制	运维人员设置标志 → standby 变为 active	复制 recording.log + archive → 启动新集群
状态重建	已在内存中——无需回放	集群加载 snapshot + 回放 log
数据丢失窗口	仅传输中的未提交消息	直到最后一次备份同步点
对 Leader 的背压	无	极小

运维

	Cluster Standby	ClusterBackup
是否需要自定义代码	否（仅需配置）	极少——ClusterBackupMediaDriver.launch()
Snapshot + log 回放	不需要——状态已实时存活	恢复时自动进行

关键洞察：冷备份会把回放风险隐藏到灾难发生之时

热与冷的区别会带来连锁影响。由于 Cluster Standby 运行真正的 ClusteredService，它会验证你的服务代码在 standby 上能否正确运行——反序列化 bug 或状态损坏会在你需要它进行故障切换之前就在 standby 上暴露出来。ClusterBackup 只存储字节。在你真正尝试之前——也就是灾难当中——你无从知道这些字节能否被成功回放。