86 lines
3.8 KiB
Markdown
86 lines
3.8 KiB
Markdown
---
|
||
title: "Disaster Recovery"
|
||
type: concept
|
||
tags: [Disaster-Recovery, DR, Business-Continuity, RTO, RPO, High-Availability, Cloud-DevOps]
|
||
sources:
|
||
- ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup
|
||
- ctp-topic-44-aws-backup-in-micro-focus
|
||
- rto-vs-rpo-key-differences-for-modern-disaster-recovery
|
||
- public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2
|
||
last_updated: 2026-04-29
|
||
---
|
||
|
||
## Disaster Recovery（灾难恢复）
|
||
|
||
灾难恢复（Disaster Recovery，DR）是指保护信息系统免受灾难性事件（地震、洪水、火灾、勒索软件、硬件故障、人为错误）影响的策略与实践体系，是 [[Business-Continuity-Plan]]（业务连续性计划）的 IT 技术层面核心组成部分。
|
||
|
||
## Core Metrics
|
||
|
||
DR 的两大核心量化指标：
|
||
|
||
| 指标 | 全称 | 含义 | 测量方向 |
|
||
|------|------|------|----------|
|
||
| **[[RTO]]** | Recovery Time Objective | 恢复时间目标：系统中断到恢复的最大可接受时长 | Forward（从故障向前） |
|
||
| **[[RPO]]** | Recovery Point Objective | 恢复点目标：可接受的最大数据丢失时间窗口 | Backward（从故障向后追溯） |
|
||
|
||
## DR Strategies
|
||
|
||
### Protection Scope
|
||
|
||
| 策略 | 说明 | RTO | RPO | 成本 |
|
||
|------|------|-----|-----|------|
|
||
| **Backup Only** | 定期备份，无备用设施 | 数小时至数天 | 数小时至数天 | $ |
|
||
| **Pilot Light** | 核心服务常驻，冷备设施待机 | 数十分钟 | 分钟级 | $$ |
|
||
| **Warm Standby** | 部分服务热备，按需扩展 | 数分钟 | 秒级 | $$$ |
|
||
| **Multi-Region Active-Active** | 多区域同时运行 | ~0 | ~0 | $$$$ |
|
||
|
||
### Cloud-Native DR on AWS
|
||
|
||
- **[[AWS-Backup]]**：集中化管理 EC2、RDS、DynamoDB、S3 等服务的备份
|
||
- **[[AWS-Backup-Audit-Manager]]**：自动化合规审计
|
||
- **Cross-Region Replication**：S3 跨区域复制 EBS 卷快照
|
||
- **AWS Elastic Disaster Recovery**：持续复制到 AWS，提供秒级 RPO
|
||
|
||
## DR vs. High Availability
|
||
|
||
| 维度 | 高可用（HA） | 灾难恢复（DR） |
|
||
|------|-------------|--------------|
|
||
| **目标故障** | 单组件故障（硬件、软件） | 区域性灾难（数据中心失效） |
|
||
| **覆盖范围** | 单站点内的冗余 | 跨地理位置的保护 |
|
||
| **触发方式** | 自动 failover | 人工决策触发 |
|
||
| **测试频率** | 持续运行（always-on） | 定期演练 |
|
||
|
||
## DR Testing Challenges
|
||
|
||
当前企业 DR 测试面临的普遍挑战（OpenText 案例）：
|
||
|
||
- **被动性**：测试按客户时间表安排，非主动设计
|
||
- **手动性**：大量人工协调，SME 全程参与
|
||
- **不一致**：缺乏跨组织的统一 DR 方法论
|
||
- **局限性**：超大规模云平台的测试主要覆盖区域故障，缺乏对账户级/服务级故障的验证
|
||
|
||
## DR to Recovery Assurance Evolution
|
||
|
||
[[OpenText]] 提出的演进框架——从被动 DR 转向主动 [[Recovery-Assurance]]：
|
||
|
||
1. **Design**：将可恢复性前置为架构设计原则
|
||
2. **Software**：软件内嵌遥测，支持持续健康监控
|
||
3. **Build**：Customer Zero 环境验证恢复路径
|
||
4. **Environments**：SRE + 可观测性工程支撑弹性
|
||
|
||
## Related Concepts
|
||
|
||
- [[RTO]] — 恢复时间目标，DR 核心指标
|
||
- [[RPO]] — 恢复点目标，DR 核心指标
|
||
- [[Business-Continuity-Plan]] — 业务连续性计划，DR 的上层框架
|
||
- [[Recovery-Assurance]] — 灾难恢复的演进方向，从被动响应到主动保证
|
||
- [[High-Availability]] — 高可用性，DR 的微观层面
|
||
- [[AWS-Backup]] — AWS 云原生 DR 实现工具
|
||
|
||
## Sources
|
||
|
||
- [[ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup]]
|
||
- [[ctp-topic-44-aws-backup-in-micro-focus]]
|
||
- [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]]
|
||
- [[public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2]]
|