1. 课程导入与灾备认知

在开始学习 Elastic 灾备恢复之前，先要建立一个基本判断：灾备不是“备份集群”这么简单，它是一套围绕业务连续性目标设计的工程体系。Elasticsearch 承载搜索、日志分析、指标监控、安全分析等关键业务时，一旦集群不可用或数据丢失，影响的不只是技术系统，还包括订单查询、故障定位、审计追溯等业务动作。因此，本章先厘清定义、目标、范围与关键术语，为后续章节的架构设计、快照恢复、跨集群复制、故障切换和演练打下共同语言。

一、什么是 Elastic 灾备恢复与业务连续性

Elastic 灾备恢复，是指在 Elasticsearch 及其周边组件（Kibana、Logstash、Beats、Elastic Agent 等）发生故障、数据损坏、误删除、区域中断或人为错误时，通过预先设计的技术手段和管理流程，使数据与服务恢复到可接受状态的过程。它关注的是“出事后如何恢复”。

业务连续性则更进一步，关注“业务在灾难期间和之后能否持续提供可接受的服务”。它既包含技术恢复，也包含人员职责、切换决策、对外沟通、降级策略和恢复验证。换句话说，灾备恢复是业务连续性的技术核心，业务连续性是灾备恢复的业务目标。

两者关系可以用一句话概括：灾备恢复解决“能不能恢复”，业务连续性解决“业务能不能继续”。如果只做了快照，却没有定义恢复优先级、切换条件和验证标准，那么技术动作可能成功，业务目标却未必达成。

二、灾备的目标：RTO 与 RPO 是核心约束

灾备设计不能凭感觉，必须用可度量的目标来约束。最核心的两个指标是 RTO 和 RPO。

• RTO（Recovery Time Objective，恢复时间目标）：灾难发生后，业务从中断到恢复可接受服务所允许的最长时间。例如“订单搜索必须在 30 分钟内恢复”。RTO 决定你需要多快的切换、多热的备用集群、多自动化的恢复流程。
• RPO（Recovery Point Objective，恢复点目标）：灾难发生时，允许丢失的数据时间窗口。例如“最多允许丢失最近 5 分钟的数据”。RPO 决定你需要多频繁的快照、是否使用跨集群复制、是否启用同步写入。

RTO 和 RPO 不是技术指标，而是业务指标。它们应由业务方与运维、架构团队共同确认，并写入灾备方案。一个常见误区是：所有业务都要求 RTO=0、RPO=0。这会导致成本急剧上升，也不现实。正确做法是按业务重要性分级，例如核心交易搜索 RTO≤15 分钟、RPO≤1 分钟；日志分析 RTO≤4 小时、RPO≤15 分钟；归档检索 RTO≤24 小时、RPO≤1 小时。

三、MTTR 与 MTBF：衡量恢复能力与稳定性的两个视角

除了 RTO/RPO，还有两个常被混淆的术语：MTTR 和 MTBF。

• MTTR（Mean Time To Repair，平均修复时间）：系统发生故障后，从故障发生到恢复正常的平均耗时。它衡量的是“修得快不快”。MTTR 越低，说明恢复流程越成熟、自动化程度越高。
• MTBF（Mean Time Between Failures，平均故障间隔时间）：系统两次故障之间的平均运行时间。它衡量的是“坏得频不频繁”。MTBF 越长，说明系统越稳定。

RTO 是“目标”，MTTR 是“实际表现”。如果 RTO 是 30 分钟，而实际 MTTR 是 90 分钟，说明灾备能力不达标。MTBF 则帮助判断是否需要从架构上减少故障源，例如增加副本、隔离故障域、优化分片分配。灾备演练的价值，正是把 MTTR 压到 RTO 以内，并验证 RPO 是否真实可达。

四、灾备的范围：不只是数据，还包括服务与依赖

Elastic 灾备的范围通常包括以下层次：

• 数据层：索引数据、映射、别名、模板、ILM 策略、快照仓库中的快照。
• 服务层：Elasticsearch 集群、Kibana、Ingest 管道、机器学习任务、告警规则。
• 接入层：客户端连接地址、负载均衡、DNS、证书与认证配置。
• 依赖层：快照存储（S3、OSS、NFS）、跨集群复制通道、密钥管理、监控系统。
• 流程层：切换决策人、恢复步骤、验证清单、回切条件、沟通机制。

很多团队只备份了索引，却忘了备份索引模板和 ILM 策略，恢复后新数据写入行为与原来不一致；或者只恢复了集群，却忘了 Kibana 的保存对象和告警规则。这些都属于灾备范围不完整。

五、整体课程框架

本课程围绕“认知—设计—实现—验证—运营”展开。先建立灾备认知与指标语言，再深入快照与恢复、跨集群复制、高可用架构、故障切换、数据一致性、演练与复盘，最后落到业务连续性管理和成本权衡。每一章都会尽量给出可操作的参数、配置片段、判断依据和示例结果，帮助你把知识转化为可执行的灾备能力。

六、一个可用的指标定义示例

为了让 RTO/RPO 真正落地，建议在灾备方案中直接写明业务等级、指标和验证方式。下面是一份示例表，参数为教学假设，实际项目需按业务确认。

七、常见认知误区

• “有副本就不需要灾备”：副本只能应对节点级故障，无法应对误删除、索引损坏、区域级中断和逻辑错误。
• “快照成功就等于能恢复”：快照成功只代表写入仓库成功，恢复还依赖仓库可用、权限正确、版本兼容和恢复流程熟练。
• “灾备是运维的事”：业务连续性需要业务方定义优先级和可接受损失，架构团队设计切换路径，运维执行演练，三方缺一不可。
• “演练会影响生产，所以不做”：不演练的灾备方案只是纸面方案。可以通过隔离恢复、只读验证、影子集群等方式降低演练风险。

八、本章小结与后续衔接