Categories
Disaster Recovery

**

對於 DevOps 工程師、資料庫管理員 (DBA) 和 IT 系統架構師而言，復原時間目標 (RTO) 和復原點目標 (RPO) 不僅僅是業務連續性的流行語，它們更是嚴格的工程限制。在管理關鍵任務資料庫時，若未能準確計算、規劃架構並驗證這些指標，可能會導致災難性的資料遺失和長時間的停機。

在現代企業環境中，計算 RTO 和 RPO 需要對資料庫內部機制、儲存 I/O、網路吞吐量和交易日誌機制有深入的了解。本指南探討了用於計算、測試和優化生產資料庫系統 RTO 和 RPO 的技術方法。

解構資料庫系統中的 RPO (復原點目標)

RPO 定義了以時間衡量的最大可接受資料遺失量。如果您的 RPO 為 15 分鐘，這意味著若在中午 12:00 發生災難，您必須能夠復原至少到上午 11:45 為止的所有已提交交易。

對於資料庫而言，RPO 取決於您的交易日誌管理策略（PostgreSQL 中的 WAL、Oracle 中的重做日誌 (Redo Logs)、SQL Server 中的交易日誌）。

資料遺失與日誌生成的機制

要計算可實現的 RPO，您必須先了解資料庫的交易日誌生成速率。如果您每 15 分鐘將日誌傳輸到備份儲存庫，但您的網路無法在該時間窗口內傳輸 15 分鐘的日誌量，那麼您的實際 RPO 將會持續惡化。

您可以使用原生 SQL 指令來建立日誌生成速率的基準。例如，在 PostgreSQL (10 版以上) 中，您可以測量特定間隔內的預寫式日誌 (WAL) 生成速率：

-- 在 T=0 時執行此指令
SELECT pg_current_wal_lsn() AS start_lsn;

-- 精確等待 5 分鐘 (300 秒)，然後執行：
SELECT pg_current_wal_lsn() AS end_lsn,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), 'START_LSN_VALUE')) AS wal_generated_size,
       pg_wal_lsn_diff(pg_current_wal_lsn(), 'START_LSN_VALUE') / 300 AS bytes_per_second;

如果此查詢顯示您在尖峰負載期間產生了 50 MB/s 的 WAL 資料，那麼 15 分鐘的 RPO 需要將 45 GB 的日誌資料傳輸到您的備份儲存空間。您的網路和儲存目標必須支援超過 50 MB/s 的持續寫入速度，才能維持此 RPO。

同步與非同步複製的影響

許多 DBA 依賴高可用性 (HA) 複製來滿足 RPO。然而，複製並非備份。刪除資料表 (DROP TABLE users;) 的動作會立即被複製。

當使用複製進行災難復原 (DR) 時，複製模式會直接影響 RPO：
* 同步複製： 保證 RPO 為零 (RPO=0)。主資料庫在備用資料庫確認接收之前，不會提交交易。其代價是主資料庫寫入操作的延遲增加。
* 非同步複製： 會引入複製延遲。您的 RPO 實際上等於您目前的複製延遲時間。

若要監控 PostgreSQL 中的非同步複製延遲，請使用：

SELECT application_name,
       client_addr,
       state,
       sync_state,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replication_lag_bytes
FROM pg_stat_replication;

解構大型資料庫的 RTO (復原時間目標)

RTO 是可容忍的最大停機持續時間。計算資料庫 RTO 之所以極其複雜，是因為它不僅僅是將檔案複製回伺服器所需的時間。

RTO 計算的數學模型

一個實際的資料庫 RTO 計算必須考慮四個不同的階段：

RTO = T(基礎設施) + T(傳輸) + T(還原) + T(復原)

  1. T(基礎設施) – 基礎設施配置： 啟動替換運算和儲存資源的時間。（若有預先配置的 DR 站點或基礎設施即程式碼 (IaC) 管線，此時間可趨近於零）。
  2. T(傳輸) – 資料傳輸： 將備份負載從儲存庫移動到資料庫伺服器的時間。
  3. T(還原) – 實體還原： 將資料檔案寫入目標磁碟的時間。
  4. T(復原) – 資料庫崩潰復原： 資料庫引擎重播交易日誌、向前滾動已提交交易並回滾未提交交易的時間。

計算傳輸與還原時間

要計算 T(傳輸) 和 T(還原)，您必須建立網路頻寬和磁碟 IOPS/吞吐量的基準。不要依賴理論上的最大值；請測試您的實際基礎設施。

使用 iperf3 測試備份儲存庫與資料庫伺服器之間的網路吞吐量：

# 在備份儲存庫 (伺服器端)
iperf3 -s

# 在資料庫伺服器 (客戶端)
iperf3 -c <backup_repo_ip> -t 60 -P 4

使用 fio 測試資料庫儲存磁碟區的順序寫入效能，模擬資料庫還原操作：

fio --name=restore_sim --ioengine=libaio --rw=write --bs=1M --size=10G --numjobs=4 --iodepth=32 --direct=1 --filename=/var/lib/postgresql/data/testfile

如果您的資料庫大小為 5 TB，且 fio 測試顯示最大持續寫入速度為 500 MB/s，則您的 T(還原) 絕對最小值約為 2.8 小時。如果您的業務 SLA 要求 1 小時的 RTO，傳統的串流還原將會失敗。您必須將架構轉向儲存層級快照或區塊層級複製。

隱藏的陷阱：T(復原)

最常被低估的變數是 T(復原)。如果您還原了每週一次的完整備份，並且需要應用 6 天的交易日誌才能達到您的 RPO，資料庫引擎必須依序重播每一筆交易。

重播 500 GB 的交易日誌可能需要數小時，且會受到單執行緒 CPU 效能和儲存 IOPS 的嚴重瓶頸限制。為了最小化 T(復原)，請增加完整備份或差異備份的頻率。

彌合差距：驗證 RTO 和 RPO 的實務步驟

計算理論上的 RTO 和 RPO 只是第一步。關鍵任務環境需要持續的驗證。

步驟 1：實施持續歸檔

為了在不犧牲同步複製效能的情況下實現分鐘級的 RPO，請實施持續日誌歸檔。不要等待日誌檔案填滿（在低流量期間可能需要數小時），而應強制在固定間隔進行日誌切換。

在 SQL Server 中，您可以自動化頻繁的交易日誌備份：

BACKUP LOG [MissionCriticalDB] 
TO DISK = N'\BackupRepoSQLMissionCriticalDB_Log.trn' 
WITH NOFORMAT, NOINIT, 
NAME = N'MissionCriticalDB-Transaction Log Backup', 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;

最佳實踐： 根據您的 RPO 要求，將此作業排程為每 1-5 分鐘執行一次。

步驟 2：自動化還原測試

未經測試的備份僅僅是一個理論概念。為了保證您計算出的 RTO，您必須執行自動化還原測試。

像 CloudSave 這樣的企業級備份平台透過提供自動化、隔離的復原測試來簡化此流程。CloudSave 可以自動啟動沙盒環境、掛載最新備份、執行完整的資料庫復原，並執行自訂驗證指令碼（例如 SQL Server 的 DBCC CHECKDB）來測量確切的 RTO 並確保資料完整性。這將 RTO 從一個計算出的猜測轉變為一個經過驗證、可報告的指標。

步驟 3：監控並針對 SLA 違規發出警報

您的監控堆疊（Prometheus、Datadog、Zabbix）應主動追蹤威脅您 RTO/RPO SLA 的指標。應針對以下情況設定警報規則：
* 備份作業失敗： 對 RPO 的直接威脅。
* 日誌傳輸延遲： 如果日誌傳輸時間超過了生成間隔。
* 儲存 IOPS 節流： 雲端供應商（如 AWS EBS）如果耗盡了突發額度 (burst credits) 會限制 IOPS，這會在實際緊急情況下悄無聲息地摧毀您的 RTO。

優化資料庫備份架構以滿足嚴格的 SLA

當數學計算顯示您目前的架構無法滿足業務 SLA 時，您必須優化備份策略。

1. 利用區塊層級增量備份

傳統的資料庫傾印（如 pg_dump 或 mysqldump 等邏輯備份）對於關鍵任務的 RTO 來說太慢了。請使用實體、區塊層級的備份。區塊層級增量備份僅複製自上次備份以來已變更的磁碟區塊，從而大幅減少 T(傳輸) 和網路開銷。

2. 利用儲存快照

對於需要小於 15 分鐘 RTO 的多 TB 資料庫，傳統的檔案複製在標準網路上在物理上是不可能的。與 SAN 或雲端原生儲存快照（例如 AWS EBS Snapshots、Pure Storage）整合，可以實現近乎即時的 T(還原)。資料庫引擎隨後僅需對快照執行崩潰復原即可。

3. 實施平行處理

確保您的備份和還原工具利用多執行緒。在使用 pgbackrest 還原 PostgreSQL 資料庫或還原 SQL Server 資料庫時，明確定義平行工作執行緒以充分利用您可用的網路和磁碟頻寬。

# pgBackRest 中的平行還原範例
pgbackrest --stanza=prod_db --process-max=8 restore

結論

為關鍵任務資料庫計算 RTO 和 RPO 是一項嚴謹的系統工程練習。它要求 DBA 超越預設的備份配置，並以數學方式對其儲存 I/O、網路容量和資料庫復原機制進行建模。

透過建立日誌生成速率基準、了解資料庫復原的不同階段，並透過 CloudSave 等強大平台實施自動化測試，IT 團隊可以自信地保證其災難復原 SLA。請記住：在資料庫管理領域，希望並非一種策略，而未經測試的備份則是一種負債。

了解 DevOps 工程師和 DBA 如何使用先進的復原機制、CLI 工具和自動化測試，為關鍵任務資料庫準確計算、測試並優化 RTO 和 RPO。

分類