一份可落地的分步指南，教你制定灾难恢复计划：如何设定切合实际的 RTO 与 RPO 目标、开展业务影响分析、设计分层备份策略，并在真正需要之前先行测试恢复流程。
SKYLINE Engineering @skyline
发布于 2026 年 6 月 9 日 | 阅读时长 6 分钟
灾难恢复计划究竟是什么
灾难恢复（DR）计划是一套经过文档化和测试的流程，供团队在发生故障后用于恢复 IT 系统和数据——无论是服务器宕机、勒索软件、数据库被删、数据中心被淹，还是云区域故障。它与备份并不相同。备份是数据的副本；而 DR 计划是把这份副本重新变回正常运行业务的操作手册。
每一份 DR 计划都围绕两个数字展开：RTO 和 RPO。把这两个数字定准了，计划的其余部分几乎就能水到渠成。
RTO 与 RPO：真正关键的两个数字
- 恢复时间目标（RTO） 是指系统在造成严重危害之前可以接受的最长停机时间。如果你的电商网站 RTO 为 2 小时，那么恢复必须在事故发生后 2 小时内完成。
- 恢复点目标（RPO） 是指你能够承受的最大数据丢失量，以时间衡量。RPO 为 15 分钟意味着你的备份（或复制）必须不早于 15 分钟，这样你最多只会损失 15 分钟的工作成果。
一个简单的记忆方法是：RTO 向前看（"我们还要多久才能恢复？"），而 RPO 向后看（"我们能丢失多少近期数据？"）。
| 概念 | 它回答的问题 | 取决于 | 目标越低，成本越高 |
|---|---|---|---|
| RTO | 我们必须多快恢复？ | 故障切换/恢复速度 | 更多自动化、热备 |
| RPO | 我们能丢失多少数据？ | 备份/复制频率 | 更频繁的备份、复制 |
目标越严格，成本越高，因此应针对每个工作负载分别设定，而不是一刀切。
第 1 步：开展业务影响分析（BIA）
列出每一个系统，并自问：这个系统每停机一小时，业务会受到什么影响？可以容忍多少数据丢失？ 然后将工作负载划分到不同层级。
| 层级 | 示例工作负载 | RTO | RPO |
|---|---|---|---|
| 1 — 关键 | 支付/ERP 数据库、面向客户的应用 | < 1 小时 | < 15 分钟 |
| 2 — 重要 | 内部应用、企业邮箱 | < 4 小时 | < 1 小时 |
| 3 — 标准 | 文件共享、报表、开发/测试 | < 24 小时 | < 24 小时 |
要实事求是。给营销博客设定 5 分钟的 RTO 是浪费钱；而给支付账本设定 24 小时的 RPO 则是足以让企业倒闭的致命错误。
第 2 步：为每个层级选择恢复策略
为每个层级匹配一种架构：
- 备份与恢复（最便宜、最慢）：按计划将备份存入对象存储，按需重建。适用于第 3 层以及许多第 2 层工作负载。
- 微光备份 / 温备（pilot light / warm standby）：在第二个位置保持一份运行中的最小化环境副本，在故障切换时扩容。适用于对 RTO 要求适中的第 1 层。
- 热备 / 双活（hot standby / active-active）：一份完全运行的副本，可近乎瞬时接管。成本最高；仅用于那些连几分钟停机都无法接受的第 1 层系统。
对于沙特的组织，还要确认每一份副本的物理存放位置。根据 PDPL 和 NCA 的指引，将主副本和 DR 副本都保存在沙特境内的云基础设施上，能让你在数据驻留要求方面保持合规，并避免跨境传输审查。
第 3 步：应用 3-2-1 备份规则
无论是哪个层级，备份都应围绕经过验证的 3-2-1 规则 来设计：
- 3 份数据副本（1 份主副本 + 2 份备份）
- 2 种不同的介质或存储类型
- 1 份异地副本（不同区域或不同提供商）
一个现代变体 3-2-1-1-0 增加了 1 份不可变/离线副本（防范勒索软件）以及 0 个错误，在恢复时经过验证。不可变性至关重要：勒索软件如今会率先攻击备份。
下面是一个可靠的示例：使用 restic 对数据库和应用目录进行去重、加密备份，并存入兼容 S3 的对象存储：
# Install restic (Debian/Ubuntu)
sudo apt-get update && sudo apt-get install -y restic
# Point restic at your object storage bucket
export RESTIC_REPOSITORY="s3:https://s3.example.com/dr-backups"
export AWS_ACCESS_KEY_ID="<access-key>"
export AWS_SECRET_ACCESS_KEY="<secret-key>"
export RESTIC_PASSWORD="<strong-repo-passphrase>" # keep this safe & off-server
# One-time: initialise the encrypted repository
restic init
# Dump the database, then back up the dump + app files
mysqldump --single-transaction --routines --triggers \
-u backup -p"$DB_PASS" appdb > /var/backups/appdb.sql
restic backup /var/backups/appdb.sql /srv/app --tag nightly
# Enforce retention (keeps storage and RPO sane)
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
你的备份频率必须满足 RPO 要求。如果 RPO 为 1 小时，就用 cron 把任务安排为每小时执行一次，并确认每次运行都能远在一小时之内完成：
# /etc/cron.d/dr-backup — hourly backup at minute 5
5 * * * * root /usr/local/bin/dr-backup.sh >> /var/log/dr-backup.log 2>&1
对于数据库需要更严格的 RPO，应使用持续性方法——MySQL/MariaDB 的 binlog 传输（binary-log shipping）或 PostgreSQL 的 WAL 归档 / 流复制——而不是仅仅依赖快照。
第 4 步：编写恢复操作手册（runbook）
一份无人能在压力下恢复的备份毫无价值。把确切的恢复步骤写成操作手册，让任何值班人员都能照着执行：
- 宣布事故，并通知 DR 协调员。
- 配置恢复基础设施（一台可以快速启动的备用云服务器或托管环境）。
- 从最新的、经过验证的备份中恢复数据。
- 校验完整性，然后重定向流量（DNS/负载均衡器）。
- 向相关方通报状态。
从上面的 restic 示例恢复其实非常简单：
# List recovery points, then restore the latest into a target path
restic snapshots
restic restore latest --target /srv/recovery
把操作手册连同人员姓名、电话号码以及凭据的存放位置——而不是凭据本身——一起保存在即使主系统宕机也能访问到的地方。
第 5 步：测试，再测试
DR 计划会逐渐失效。至少每季度为第 1 层系统安排一次恢复演练：
- 桌面推演（tabletop test）：在纸面上把操作手册过一遍。
- 恢复测试（restore test）：真正把一份备份恢复到隔离环境中，并确认数据正确无误（这就是 3-2-1-1-0 中的那个"0"）。
- 完整故障切换（full failover）：切换到 DR 站点并在其上运行。
每次演练之后，用你的 RTO 和 RPO 来衡量实际的恢复时间和数据丢失量。如果没达标，就补上差距——更频繁的备份、更多的自动化，或更"热"的备用环境——然后重新测试。
综合起来
一份可行的 DR 计划其实很简短：一页分层表格、各层级的 RTO/RPO 目标、一套 3-2-1-1-0 备份设计、一份经过测试的操作手册，以及一份演练计划。先从你最关键的工作负载入手，端到端地证明恢复确实可行，然后再逐层扩展。
如果你希望备份和备用基础设施都留在沙特境内，以满足 PDPL 和 NCA 合规要求，可以了解我们的云备份集群以查看相关指南，或注册一个 Skyline Cloud 账户，在几分钟内开通沙特境内的对象存储、云服务器和备份。
Comments
0 total · 0 threads