RTO和RPO的區別：含義、算例與目標設定

先說結論： RTO（恢復時間目標）是故障之後你最多能停多久；RPO（恢復點目標）是你最多能丟多久的數據，用時間來表示。RTO 管的是服務多快恢復，RPO 管的是恢復回來的數據有多新。備份頻率決定 RPO，恢復方式決定 RTO。

很多中小企業都有備份，卻從沒寫下過「備份要多快恢復回來」「最多允許丟多少數據」。直到真出了事，這兩個數字才在停機的當口第一次被認真討論。這篇文章用平實的話解釋 RTO 和 RPO，說明如何定出現實可行的目標，以及這兩個目標怎樣決定你在備份與恢復上要花多少錢。

正式定義參考了 NIST 術語表中的兩個詞條，均出自 NIST SP 800-34 Rev. 1（聯邦資訊系統應急計劃指南）：恢復時間目標和恢復點目標。我們於 2026 年 10 月 28 日閱讀這兩個詞條（查證日期：2026-10-28）。下文的算例均為虛構數字，僅作說明，並非博迅的實際數據。

RTO 和 RPO 有什麼區別？

任何故障發生之後，都有兩個問題：多久能重新開工？丟了多少工作成果？

RTO 回答「最多能停多久」。 NIST 的描述是：系統組件處於恢復階段的總時長，超過這個時長就會對機構的任務或業務流程造成負面影響。
RPO 回答「最多能丟多少數據」。 NIST 的描述是：中斷之後數據必須恢復到的那個時間點。

RPO 放在時間線上最容易理解。假如系統 15:00 出故障，最後一份可用數據是 12:00 的，那麼你會丟失三小時的變更。如果你的 RPO 是一小時，這個缺口就超標了兩小時。

RTO 則是從故障發生到用戶能重新工作的那段長度。故障在 15:00，RTO 是四小時，目標就是 19:00 前用戶能重新使用。

兩者相互獨立。有的業務要求幾乎不丟數據，但可以容忍停一天（比如帳務系統，晚上停一晚沒關係，但已經記帳的交易絕不能丟）；有的業務要求幾分鐘內恢復，卻可以接受丟掉最近一小時（比如每小時從源頭重建一次的報表站點）。

備份頻率怎樣決定 RPO？

RPO 不可能好於兩份可用副本之間的間隔。如果每晚備份一次，最壞情況就是丟掉將近一整天的工作。

算例：財務團隊的帳務伺服器每晚 22:00 備份。次日下午 17:00，伺服器的存儲壞了。

最後一份可用備份是前一晚 22:00 的。
從那份備份到故障發生，隔了 19 小時。
即使備份任務每晚都成功運行，團隊仍然丟失了 19 小時的錄入內容。

所以每晚一次備份的實際 RPO 可達 24 小時，而不是「有備份就等於零」。如果業務方判斷最多只能丟一小時，備份間隔就必須小於等於一小時，這意味著更頻繁的快照、持續複製或應用層日誌，每一步都要在存儲、許可和帶寬上多花錢。

一個實用規則：備份間隔 ≤ RPO，再給備份失敗或延遲留出餘量。計劃每小時一次的備份，如果悄悄失敗了六小時，實際 RPO 就是七小時。這就是為什麼監控備份任務和設定備份計劃同樣重要。

什麼決定了 RTO？

RTO 不是一個動作，而是若干步驟的總和，其中最慢的那一步往往出乎意料。

發現： 有人或監控系統察覺到故障。
決策： 有權限的人決定切換或恢復，並正式宣佈。
恢復： 從備份重建數據與系統，或切換到備用環境。
驗證： 在放用戶進來之前，先測試恢復後的服務。
切換： 把用戶和接口指向恢復後的服務。

恢復這一步通常最耗時，取決於數據量和傳輸速度。

算例：需要從雲備份恢復 2 TB 數據。2 TB 約等於 16,000 吉比特。先忽略所有額外開銷：

有效帶寬 1 Gbps 時，傳輸約需 16,000 秒，大約 4.4 小時。
有效帶寬 200 Mbps 時，約需 80,000 秒，大約 22 小時。

實際恢復會比這個慢，因為有壓縮、大量小文件、校驗，以及和其他流量爭用帶寬。重點在於：用 200 Mbps 的線路、純雲端恢復這麼大的數據，四小時的 RTO 根本做不到。要達到它，就得換更快的線路、保留一份本地副本用於快速恢復、縮小首批恢復範圍（先恢復最關鍵的數據），或者準備一套已經在運行的備用環境。

怎樣為每個系統設定 RTO 和 RPO？

不要給整個公司定一個數字。不同系統的重要程度不同，把所有系統都當成關鍵系統，計劃就會貴到做不起。對每個系統按下面的清單走一遍。

列出系統以及依賴它們的業務流程：工資、郵件、ERP、文件共享、CRM、網站。
對每個流程問：停多久會造成真正的損害（丟訂單、錯過法律期限、員工閒置）？這就是候選 RTO。
再問：最近多長時間的工作量可以人工補錄或重做？這就是候選 RPO。
把系統分成幾檔，例如「幾小時內必須恢復」「一天內恢復」「幾天內恢復」，只在真正需要的地方為快速恢復付費。
核對技術現實：備份間隔能否做到 RPO，恢復方式能否做到 RTO，要把上面的傳輸速度也算進去。
估算成本。目標越緊，需要的副本越頻繁，存儲越多，往往還要備用環境。價格太高就放寬目標，或者明確承擔這個風險。
把商定的目標寫下來，請業務負責人簽字確認，至少每年複核一次，系統變化時也要複核。

第 6 步是很多計劃失敗的地方。沒有算過成本的目標只是願望，不是目標。

一家 40 人的公司，分檔可能是什麼樣？

下面的數字是為了演示方法而虛構的，你自己的答案會不同。

第一檔：帳務系統和訂單系統。 RTO 4 小時，RPO 1 小時。丟失的交易很難重建，系統停著銷售就停。這一檔需要每小時一份副本、一份本地恢復副本（讓傳輸不依賴互聯網線路），以及經過測試的恢復步驟。
第二檔：文件共享和 CRM。 RTO 1 個工作日，RPO 4 小時。員工可以暫時用本地文件工作，最近的修改也能重做。工作時間內每 4 小時做一次快照，再加每晚一次備份就夠，從雲端恢復。
第三檔：內部網站、歸檔和測試系統。 RTO 3 個工作日，RPO 24 小時。每晚備份，有空時再恢復。

可以看到，分檔是先由業務問題驅動，再由技術來落實。公司只為兩個系統支付每小時副本和本地恢復點的費用，而不是為所有系統。

RTO、RPO 與災難恢復、業務連續性計劃、MTTR 是什麼關係？

業務連續性計劃（BCP）： 讓業務在中斷期間繼續運轉的整體計劃。RTO 和 RPO 是其中的技術恢復目標。
災難恢復（DR）： 計劃中的技術部分，即系統和數據如何恢復。RTO 和 RPO 能否達成，要看 DR。
最大可容忍停機時間： NIST 體系裡的相關概念，指業務最長能承受的中斷時長。RTO 必須短於它，還要給驗證和切換留出時間。
MTTR： 過去恢復實際花了多久的平均值。RTO 是你定下的目標，MTTR 是測量結果。如果實測恢復時間一直比 RTO 長，說明這個目標並不真實。如何測量請見MTTR、MTBF 和 MTTA 的含義。