SQL Academy · 课时

灾难恢复规划

Q: 「灾难恢复规划」这节课中我会学到什么？

RPO、RTO 和运行手册。 你通过在浏览器中直接运行的动手代码来练习 SQL Academy，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

RPO、RTO 和运行手册。

灾难恢复规划 是 CoddyKit 上的免费 SQL Academy 课时。这是第 4 节课，共 4 节。你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。这是 SQL Academy 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 SQL Academy 课程共包含 4 节课。

什么是灾难恢复

灾难恢复（DR）是为在自然灾害或人为灾害发生后恢复关键技术基础设施和系统而设计的一套策略、工具和流程。

在数据库语境中，灾难恢复规划可确保您的数据保持安全，并且在硬件故障、意外数据删除、勒索软件攻击或数据中心中断等事件发生后，系统能在可接受的时间限制内恢复上线。

恢复点目标（RPO）

RPO 定义了按时间衡量的最大可接受数据丢失量。如果您的 RPO 是 1 小时，您必须能够恢复到至少灾难发生前 1 小时的数据。

较短的 RPO 要求更频繁的备份或持续复制。您可以查询备份历史记录，验证是否达到了 RPO 目标。

-- Check the last backup time and calculate data loss window
SELECT
  backup_id,
  backup_type,
  started_at,
  finished_at,
  EXTRACT(EPOCH FROM (NOW() - finished_at)) / 3600 AS hours_since_backup
FROM backup_log
WHERE status = 'SUCCESS'
ORDER BY finished_at DESC
LIMIT 5;

恢复时间目标（RTO）

RTO 定义了系统在灾难后可离线的最长可接受时间。如果您的 RTO 是 4 小时，数据库必须在故障发生后的 4 小时内完全恢复运行。

RTO 会推动备用服务器、故障切换自动化和恢复流程方面的决策。跟踪一段时间内的恢复时长，有助于预测您是否能够满足 RTO。

-- Track restore durations to validate RTO compliance
SELECT
  restore_id,
  triggered_at,
  completed_at,
  EXTRACT(EPOCH FROM (completed_at - triggered_at)) / 60 AS restore_minutes,
  CASE
    WHEN EXTRACT(EPOCH FROM (completed_at - triggered_at)) / 3600 <= 4
    THEN 'WITHIN RTO'
    ELSE 'RTO BREACHED'
  END AS rto_status
FROM restore_log
ORDER BY triggered_at DESC;

RPO 与 RTO——关键区别

这两个指标经常被混淆。以下是记住它们最简单的方法：

RPO = 您可以承受丢失多少数据？（回顾性指标，以灾难前的时间衡量）
RTO = 您可以承受停机多久？（前瞻性指标，以灾难后的时间衡量）

它们共同定义恢复窗口，并直接影响备份频率、复制策略和基础设施预算。

-- Store RPO and RTO targets per database in a DR configuration table
CREATE TABLE dr_config (
  db_name       VARCHAR(100) PRIMARY KEY,
  rpo_minutes   INT NOT NULL,
  rto_minutes   INT NOT NULL,
  tier          VARCHAR(20) CHECK (tier IN ('CRITICAL', 'HIGH', 'MEDIUM', 'LOW')),
  updated_at    TIMESTAMP DEFAULT NOW()
);

INSERT INTO dr_config (db_name, rpo_minutes, rto_minutes, tier) VALUES
  ('orders_db',    15,   60, 'CRITICAL'),
  ('analytics_db', 120, 240, 'MEDIUM'),
  ('archive_db',   480, 480, 'LOW');

备份类型

主要有三种备份策略，每种策略都需要在速度和存储空间之间进行权衡：

完整备份：整个数据库的完整快照。创建速度最慢，恢复速度最快。
差异备份：仅包含上次完整备份之后的更改。创建和恢复速度都适中。
增量备份：仅包含任意类型的上次备份之后的更改。创建速度最快，恢复速度最慢（需要多个文件）。

大多数灾难恢复策略将每周完整备份与每日增量备份结合，以平衡 RPO 和存储成本。

-- Log each backup with its type for audit and recovery planning
CREATE TABLE backup_log (
  backup_id   SERIAL PRIMARY KEY,
  db_name     VARCHAR(100) NOT NULL,
  backup_type VARCHAR(20) CHECK (backup_type IN ('FULL', 'DIFFERENTIAL', 'INCREMENTAL')),
  started_at  TIMESTAMP NOT NULL,
  finished_at TIMESTAMP,
  size_mb     NUMERIC(12, 2),
  status      VARCHAR(20) DEFAULT 'IN_PROGRESS'
);

INSERT INTO backup_log (db_name, backup_type, started_at, finished_at, size_mb, status) VALUES
  ('orders_db', 'FULL',        '2024-06-01 01:00:00', '2024-06-01 02:15:00', 45200, 'SUCCESS'),
  ('orders_db', 'INCREMENTAL', '2024-06-02 01:00:00', '2024-06-02 01:08:00',   320, 'SUCCESS'),
  ('orders_db', 'INCREMENTAL', '2024-06-03 01:00:00', '2024-06-03 01:07:00',   290, 'SUCCESS');

时间点恢复（PITR）

时间点恢复允许您将数据库恢复到任意特定时刻，而不仅仅是上次备份的时间。此过程通过在基础备份之上重放事务日志（PostgreSQL 中的 WAL）来实现。

PITR 在需要从已知时间发生的意外数据损坏或删除中恢复时至关重要。您可以恢复到造成损害的事件发生之前的时刻。

-- Record WAL archive events for PITR tracking
CREATE TABLE wal_archive_log (
  segment_name  VARCHAR(200) PRIMARY KEY,
  archived_at   TIMESTAMP DEFAULT NOW(),
  size_bytes    BIGINT,
  storage_path  TEXT
);

-- Find all WAL segments archived within a recovery window
SELECT
  segment_name,
  archived_at,
  ROUND(size_bytes / 1024.0 / 1024.0, 2) AS size_mb
FROM wal_archive_log
WHERE archived_at BETWEEN '2024-06-03 09:00:00' AND '2024-06-03 11:00:00'
ORDER BY archived_at;

备用数据库与复制

备用（副本）数据库是在独立硬件上运行的主数据库的持续更新副本。它有两个灾难恢复用途：

热备用：可以接受读查询，并在几秒内完成故障切换（RTO 接近零）。
温备用：保持同步但不提供流量；故障切换需要几分钟。

监控复制延迟至关重要——延迟的副本意味着实际 RPO 比预期更差。

-- Monitor replication lag on a PostgreSQL primary
SELECT
  client_addr,
  application_name,
  state,
  sent_lsn,
  replay_lsn,
  (sent_lsn - replay_lsn) AS lag_bytes,
  EXTRACT(EPOCH FROM (NOW() - reply_time)) AS seconds_since_reply
FROM pg_stat_replication
ORDER BY lag_bytes DESC;

运行手册：记录恢复流程

运行手册是一套有文档记录的分步说明，操作人员会在灾难恢复事件期间遵循这些说明。没有运行手册，即使经验丰富的数据库管理员也会在压力下犯下代价高昂的错误。

优秀的灾难恢复运行手册应包括：联系谁、哪些系统受到影响、要运行的确切命令、每一步的预期输出，以及恢复失败时的回滚流程。将运行手册元数据存储在数据库中，有助于跟踪版本并审计使用情况。

-- Store runbook metadata in the database for audit tracking
CREATE TABLE runbook (
  runbook_id   SERIAL PRIMARY KEY,
  title        VARCHAR(200) NOT NULL,
  scenario     VARCHAR(100),
  version      VARCHAR(20) DEFAULT '1.0',
  last_tested  DATE,
  owner        VARCHAR(100),
  doc_url      TEXT
);

INSERT INTO runbook (title, scenario, version, last_tested, owner, doc_url) VALUES
  ('Full Database Restore from S3', 'total_loss',     '2.1', '2024-05-15', 'dba_team', 'https://wiki.internal/dr/full-restore'),
  ('Failover to Hot Standby',       'primary_down',   '1.4', '2024-04-20', 'dba_team', 'https://wiki.internal/dr/failover'),
  ('PITR to Specific Timestamp',    'data_corruption','1.2', '2024-03-10', 'dba_team', 'https://wiki.internal/dr/pitr');

运行手册执行日志记录

每次执行运行手册时——无论是在实际灾难中还是演练期间——都应记录日志。执行日志可以让您衡量恢复实际耗时（验证 RTO）、识别缓慢或容易出错的步骤，并向审计人员证明合规性。

-- Log each runbook execution for RTO validation and audit
CREATE TABLE runbook_execution (
  execution_id  SERIAL PRIMARY KEY,
  runbook_id    INT REFERENCES runbook(runbook_id),
  triggered_by  VARCHAR(100),
  is_drill      BOOLEAN DEFAULT FALSE,
  started_at    TIMESTAMP NOT NULL,
  completed_at  TIMESTAMP,
  outcome       VARCHAR(20) CHECK (outcome IN ('SUCCESS', 'PARTIAL', 'FAILED'))
);

-- Report average restore time per runbook
SELECT
  r.title,
  COUNT(*) AS executions,
  ROUND(AVG(EXTRACT(EPOCH FROM (e.completed_at - e.started_at)) / 60), 1) AS avg_minutes,
  MAX(EXTRACT(EPOCH FROM (e.completed_at - e.started_at)) / 60) AS max_minutes
FROM runbook_execution e
JOIN runbook r ON r.runbook_id = e.runbook_id
WHERE e.outcome = 'SUCCESS'
GROUP BY r.title;

灾难恢复测试：定期演练

从未测试过的灾难恢复计划不是计划——只是愿望。定期演练是强制性的，以确保您的团队确实能在规定的 RTO 内执行运行手册，并确保备份确实可恢复。

在数据库中安排和跟踪演练会创建审计轨迹，并帮助您发现逾期未测试的运行手册。

-- Find runbooks that have not been drilled in over 90 days
SELECT
  r.runbook_id,
  r.title,
  r.scenario,
  MAX(e.completed_at) AS last_drill,
  CURRENT_DATE - MAX(e.completed_at::DATE) AS days_since_drill
FROM runbook r
LEFT JOIN runbook_execution e
  ON e.runbook_id = r.runbook_id
  AND e.is_drill = TRUE
  AND e.outcome = 'SUCCESS'
GROUP BY r.runbook_id, r.title, r.scenario
HAVING MAX(e.completed_at) IS NULL
    OR CURRENT_DATE - MAX(e.completed_at::DATE) > 90
ORDER BY days_since_drill DESC NULLS FIRST;

备份保留策略

保留策略定义备份保存多长时间。永久保留每份备份会浪费存储空间；过快删除则会违反您的 RPO 和合规要求。

常见策略是：每日增量备份保留 7 天，每周完整备份保留 4 周，每月完整备份保留 12 个月。您可以使用针对备份日志的 SQL 查询来执行和审计保留策略。

-- Identify backups that are outside their retention window and ready to purge
SELECT
  backup_id,
  db_name,
  backup_type,
  finished_at,
  CURRENT_DATE - finished_at::DATE AS age_days,
  CASE backup_type
    WHEN 'INCREMENTAL' THEN 7
    WHEN 'DIFFERENTIAL' THEN 28
    WHEN 'FULL'         THEN 365
  END AS retention_days,
  CASE
    WHEN (CURRENT_DATE - finished_at::DATE) >
         CASE backup_type
           WHEN 'INCREMENTAL' THEN 7
           WHEN 'DIFFERENTIAL' THEN 28
           WHEN 'FULL'         THEN 365
         END
    THEN 'PURGE'
    ELSE 'KEEP'
  END AS action
FROM backup_log
WHERE status = 'SUCCESS'
ORDER BY finished_at;

快速测验

检验您对 RPO 和 RTO 定义的理解。

回顾：灾难恢复规划

在本课中，您探索了数据库灾难恢复规划的基础知识：

RPO 定义了最多可容忍的数据丢失时间跨度；更短的 RPO 需要更频繁的备份或持续复制。
RTO 定义了系统必须多快恢复；更短的 RTO 需要热备用和自动故障转移。
备份类型——完整备份、差异备份和增量备份——在存储空间、创建速度和恢复速度之间各有不同的取舍。
PITR（时间点恢复）使用事务日志将数据恢复到任意精确时刻，从而防范意外更改。
运行手册记录恢复过程的每个步骤；记录执行日志可以验证您的 RTO 在实践中是否能够实现。
定期进行 DR 演练是确认备份可恢复，以及确认您的团队能够在实际压力下达到 RPO 和 RTO 目标的唯一方法。
保留策略需要在存储成本与合规性和恢复要求之间取得平衡。

经过充分测试的 DR 计划，是数据库团队能够进行的最有价值的投资之一。

常见问题解答

「灾难恢复规划」课时是免费的吗？

是的 — 「灾难恢复规划」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 SQL Academy 课程的其余内容，请升级到 CoddyKit PRO。 SQL Academy 课程共包含 4 节课。

「灾难恢复规划」这节课中我会学到什么？

RPO、RTO 和运行手册。你通过在浏览器中直接运行的动手代码来练习 SQL Academy，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 SQL Academy 需要有经验吗？

无需任何先前经验。CoddyKit 上的 SQL Academy 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。这是第 4 节课，共 4 节。

「灾难恢复规划」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 SQL Academy 课中编写并运行代码吗？

能。每节 SQL Academy 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

← 返回 SQL Academy