[研究]MTOD, RTO, RPO 分析與處理

[研究]MTOD, RTO, RPO 分析與處理

2025-11-05 

某系統使用 VMare vSphere 的 VM，做 VM 備份 

• Day2 AM 11:00 Completed 
• Day2 AM 05:00 Failed 
• Day2 AM 03:00 Fauled 
• Day1 PM 11:00 Completed 

• 資通系統從中斷後至重新恢復服務之可容忍時間(MTPD) 8小時 
• 回復基礎服務或內部運作時間(RTO) 4小時 
• 系統可容忍資料損失時間(RPO) 4小時 

管理員有分析失敗原因，當月也只有這2次 Failed， 符合 MTPD, RTO, RPO 嗎 ?

ChatGPT

項目	結果	說明
RPO	⚠️ 部分時段不符合	若災難於 Day2 05:00 發生，資料損失超過 4 小時
RTO	✅ 符合	備份錯誤不等於服務中斷，恢復時間未超 4 小時
MTPD	✅ 符合	備份系統恢復在 8 小時內完成

********************************************************************************

• 資通系統從中斷後至重新恢復服務之可容忍時間(MTPD) 24小時 
• 回復基礎服務或內部運作時間(RTO) 8小時 
• 系統可容忍資料損失時間(RPO) 24小時 

每天都只 PM 7:00, PM 11:00 做一次備份，都成功，符合 MTPD, RTO, RPO 嗎 ?

ChatGPT

都符合。

********************************************************************************

真實世界每次 VM 備份不可能一定成功，要100%符合 MTPD, RTO, RPO 是做不到的，該如何處理 ?

ChatGPT

你說得很對——在真實世界中，VM（虛擬機器）備份不可能每次都 100% 成功，尤其是大規模環境或高變動系統中。因此，光靠單純備份策略，很難保證完全符合 MTPD、RTO、RPO 的要求。處理方式通常會採取 風險容忍 + 多層策略，我整理如下：

1️⃣ 分析現實風險，設定可接受範圍

• MTPD（最大可容忍停機時間）：確認業務可承受的最長停機時間，例如 8 小時。
• RTO（恢復時間目標）：確定從事件發生到服務恢復所需的最大時間。
• RPO（資料可容忍損失量）：確認可接受的最大資料損失量（通常以時間來表示，例如 24 小時內的資料）。

關鍵：不要假設備份一定成功，要設計策略讓即便某次備份失敗，也能在容忍範圍內恢復。

2️⃣ 多層備份策略

• 頻繁備份 + 差異/增量備份：每日完整備份可能風險高，搭配差異或增量備份降低資料損失量。
• 跨位置備份：同時備份到不同存儲（本地 + 雲端 / 异地機房），避免單點故障。
• 多時間點保留：保留過去數天/週的多版本，某次失敗也可回滾到上一個成功備份。

3️⃣ 自動監控與告警

• 備份成功率監控：自動檢查備份結果，失敗立即告警。
• 自動重試：部分系統支持自動重試失敗的 VM 備份。
• 報表分析：定期統計成功率，評估整體備份可靠性。

4️⃣ 災難恢復與備援設計

• HA / 容錯：重要 VM 可搭配 HA（High Availability）或 VM 快速遷移，降低單點故障影響。
• 熱備/冷備：對關鍵系統，設計可快速啟動的熱備或冷備 VM。
• 演練：定期做恢復演練，確保在 RTO 內可恢復服務。

5️⃣ 文檔化風險策略

• SLA 明確化：對業務方說明：即便備份失敗，最大可容忍損失和停機時間。
• 優先級分級：關鍵 VM、業務系統設定不同 MTPD/RTO/RPO，資源有限時先保障高優先級系統。

💡 總結

• 不要期望 100% 備份成功。
• 透過多層備份、監控、異地備援與演練，將風險控制在可容忍範圍內。
• MTPD、RTO、RPO 不是保證，而是「設計容忍度」，配合風險管理策略才可落地。

(完)

[研究]BCP 可以強制 使用 線上備份 or 離線備份 達成 RPO, RTO, MTPD 嗎 ?

[研究]BCP 可以強制 使用 線上備份 or 離線備份 達成 RPO, RTO, MTPD 嗎 ?

2025-10-13

敝人聽到某 BCP 演練要求一定要離線備份 達成 RPO, RTO, MTPD，有些傻眼。

如果目標是抓到老鼠，不管黑貓、白貓、花貓，只要能抓到就好；

要達成 RPO, RTO, MTPD，還強制要求某種方法，已經有點本末倒置了；當有數種備援 or 備份方法同時採用時，事情發生時，一定是採用最合適、最快的方法來達成  RPO, RTO, MTPD 要求時間，而不是強制某種 or 所有的備援 or 備份方法都可以達到 RPO, RTO, MTPD 的要求，因為某些備援 or 備份方法的目標是多備一份、成本考量、其他考量，而不是  RPO, RTO, MTPD 考量，達不到本就正常。

********************************************************************************

把問題丟給 ChatGPT 聽聽它的看法

ChatGPT

🔹BCP 的角色

BCP（Business Continuity Plan，營運持續計畫） 是組織層級的管理框架，用來確保在中斷事件（災難、系統故障、人為錯誤等）後，能在「可接受時間內」恢復關鍵業務功能。

它的目標是達成：

• RTO（Recovery Time Objective）
• RPO（Recovery Point Objective）
• MTPD（Maximum Tolerable Period of Disruption）

但 BCP 本身並不直接「強制」採用特定備份技術（線上或離線）。

它定義「要達到的目標值」，至於「如何達成」，是由技術計畫（例如 IT DRP）來支撐。

🔹回答重點

➡️ 不能直接「強制」，但 可以「要求」或「規範」達成特定 RPO / RTO / MTPD 指標。

接著由：

• IT DR 計畫（Disaster Recovery Plan）
• 備份策略（Backup Strategy）

來選擇適合的技術（線上、離線、混合等）去滿足這些目標。

********************************************************************************

(完)

[研究]ISO 27001 系列 有提到 RPO, RTO, MTPD 嗎 ?

[研究]ISO 27001 系列 有提到 RPO, RTO, MTPD 嗎 ?

2025-10-13

聊聊

• RPO（Recovery Point Objective，復原點目標）
• RTO（Recovery Time Objective，復原時間目標）
• MTPD（Maximum Tolerable Period of Disruption，可容忍中斷最長時間）

續

[研究]【資安法】的「資通安全責任等級分級辦法」有提到 RPO, RTO, MTPD 嗎？
https://shaurong.blogspot.com/2025/10/rpo-rto-mtpd.html

ISO 文件是要賣錢的，沒有公開免費下載，ChatGPT 的回答僅供參考，敝人沒去驗證。

********************************************************************************

ISO 27001 系列 有提到 RPO, RTO, MTPD 嗎 ? 資料來源網址 ?

ChatGPT

短答案是：在 ISO 27001 / 27002 正式條文內，並沒有以正式名詞方式（即 “RPO”、“MTPD”）出現；但在其控制建議 / 指導 /輔助文件中，「RTO」與「RPO」有被提及，尤其在 Annex A 的 ICT 持續性控制（A.5.30）中。下面是我找到的證據與說明：

🔍 證據與說明

✅ 提到 RTO / RPO 的例子

• 在 ISO/IEC 27001:2022 Annex A, 控制 5.30 “ICT Readiness for Business Continuity” 的解釋 / 實作輔導中，有說明應為每個 ICT 服務定義一個 RTO。 https://www.isms.online/iso-27001/annex-a-2022/5-30-readiness-for-business-continuity-2022/
• 同樣地，那些解釋資料也指出對於每個 ICT 資源（resource），應定義 Recovery Point Objective (RPO)，並建立程序以確保資訊能被還原。 
• 如 ISMS.online 在其“Control 5.30 – ICT Readiness for Business Continuity”一文中，就是以“Recovery Time Objectives (RTO)”這個名詞來描述控制目標。 

❌ 沒有看到 MTPD

• 在我查到的 ISO 27001 / ISO 27002 控制與輔導資料中，沒有可靠資料明示其控制中包含 MTPD（Maximum Tolerable Period of Disruption） 這個專用名詞。
• 控制 5.30 的輔導資料多半聚焦於 RTO / RPO / BIA / ICT 備援策略，而不是談及中斷容忍時間極限（MTPD）這樣的 BCM 概念。 

********************************************************************************

ISO 那一份文件專門定義名詞 ?

ChatGPT 

📘 ISO/IEC 27000:2024 — Information security, cybersecurity and privacy protection — Vocabulary

（先前版本為 ISO/IEC 27000:2018）提供了所有標準中一致使用的術語與定義，適用於：

• ISO/IEC 27001（ISMS 要求）
• ISO/IEC 27002（控制措施）
• 以及延伸標準，如 ISO/IEC 27005（風險管理）、27017、27701 等。

📗 文件中內容重點

ISO/IEC 27000 定義了：

• ISMS（Information Security Management System）
• Asset, Risk, Control, Event, Incident
• Confidentiality / Integrity / Availability
• Threat / Vulnerability / Impact
• 但並未定義 RTO、RPO、MTPD 等術語。

因為這些屬於 業務連續性管理（BCM） 領域的術語，主要來自：

📘 ISO 22301:2019 — Security and resilience — Business continuity management systems — Requirements

📘 ISO 22313:2020 — Security and resilience — Business continuity management systems — Guidance

📚 對照關係：

概念	所屬標準	是否定義
RTO (Recovery Time Objective)	ISO 22301 §3.28	✅ 有定義
RPO (Recovery Point Objective)	ISO 22301 §3.27	✅ 有定義
MTPD (Maximum Tolerable Period of Disruption)	ISO 22301 §3.11	✅ 有定義
ISMS / Risk / Control 等資訊安全名詞	ISO/IEC 27000	✅ 有定義

📎 官方資訊來源：

ISO 官方頁面（最新版本）

🔗 https://www.iso.org/standard/88530.html

 — ISO/IEC 27000:2024 Vocabulary

🔗 https://www.iso.org/standard/75106.html

 — ISO 22301:2019 Business continuity management systems

********************************************************************************

📘 ISO/IEC 27001:2022 與 ISO 22301:2019 🔍 RTO、RPO、MTPD 條文與定義對照表

概念	標準	條文／章節	中文說明
RTO(Recovery Time Objective)	ISO 22301:2019 §3.28	“Recovery time objective (RTO)” — Period of time following an incident within which a product or service must be resumed, or resources must be recovered.	發生事故後，業務或服務必須恢復的最長可容許時間（可接受的停擺時間）。
	ISO/IEC 27001:2022 (Annex A 5.30)	無正式定義，但在指導文件（ISO/IEC 27002:2022 A.5.30）中提及：“The BIA should specify an agreed RTO for those resources.”	雖未在條文中定義，但要求組織針對資訊資源進行 BIA，並設定 RTO。
RPO(Recovery Point Objective)	ISO 22301:2019 §3.27	“Recovery point objective (RPO)” — Point to which information used by an activity must be restored to enable the activity to operate on resumption.	在恢復時，資料可接受的最新可回復點（資料遺失容忍量）。
	ISO/IEC 27001:2022 (Annex A 5.30 note / guidance)	非正式用語，但在 ISO/IEC 27002 A.5.30 的範例說明中出現：“For each ICT resource, a recovery point objective (RPO) is defined.”	未於正式條文，但在實務上被建議列入 ICT 持續性規劃的一部分。
MTPD(Maximum Tolerable Period of Disruption)	ISO 22301:2019 §3.11	“Maximum tolerable period of disruption (MTPD)” — Time it would take for adverse impacts, which might arise as a result of not providing a product/service, to become unacceptable.	企業無法運作時，造成不可接受影響的最長時間。若超過此時間，組織可能無法生存。
	ISO/IEC 27001:2022	❌ 未出現	ISO 27001 未直接使用 MTPD 概念；若需評估，應參考 ISO 22301。

********************************************************************************

RTO、RPO、MTPD 差異與關聯圖表 （依據 ISO 22301:2019 與 ISO/IEC 27001:2022 A.5.30 實務對照）

名稱	全名	所屬標準	定義重點	衡量對象	常見單位	決定方式	實務意義
RTO	Recovery Time Objective	ISO 22301 §3.28 / ISO 27002 A.5.30	發生中斷後，業務或系統必須在多少時間內恢復運作	系統服務／流程	時間（小時／天）	由 BIA 分析與管理層決定	指導備援與恢復時程規劃
RPO	Recovery Point Objective	ISO 22301 §3.27 / ISO 27002 A.5.30	在恢復後，資料可接受回復到的時間點（可容忍的資料遺失量）	資料／交易	時間（分／小時）	依業務資料重要性決定	指導備份頻率與資料同步策略
MTPD	Maximum Tolerable Period of Disruption	ISO 22301 §3.11	業務無法持續提供至造成不可接受損害的最長時間	組織／流程	時間（小時／天）	由風險與影響評估決定	超過此時間＝企業存續受威脅

二、三者時間軸關係圖

災難發生點 ───────────────────────────────────────────────► 時間

       ▼            ▼                     ▼

      RPO          RTO                  MTPD

  (可容忍資料損失點)   (必須恢復時間點)      (無法承受中斷極限)

   ←── 資料可回復區 ──→

   ←───────── 可容忍停擺區間 ─────────→

說明：

• RPO 決定「你可以損失多少資料」
• RTO 決定「你可以停擺多久」
• MTPD 是「超過這時間公司會嚴重受損或倒閉」

三者關係通常是：RPO < RTO < MTPD

********************************************************************************

********************************************************************************

(完)

相關

法規名稱：資通安全責任等級分級辦法
https://law.moj.gov.tw/LawClass/LawAll.aspx?pcode=A0030304

附表一 資通安全責任等級A級之公務機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298107&lan=C

附表二 資通安全責任等級A級之特定非公務機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298108&lan=C

附表三 資通安全責任等級B級之公務機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298109&lan=C

附表四 資通安全責任等級B級之特定非公務機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298110&lan=C

附表五 資通安全責任等級C級之公務機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298111&lan=C

附表六 資通安全責任等級C級之特定非公務機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298112&lan=C

附表七 資通安全責任等級D級之各機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298113&lan=C

附表八 資通安全責任等級E級之各機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298114&lan=C

附表九 資通系統防護需求分級原則.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000254363&lan=C

附表十 資通系統防護基準.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298115&lan=C

法規名稱：資通安全事件通報及應變辦法
https://law.moj.gov.tw/LawClass/LawAll.aspx?pcode=A0030305

資安演練與稽核
https://moda.gov.tw/ACS/operations/drill-and-audit/652

[研究]【資安法】的「資通安全責任等級分級辦法」有提到 RPO, RTO, MTPD 嗎？

[研究]【資安法】的「資通安全責任等級分級辦法」有提到 RPO, RTO, MTPD 嗎？

2025-10-13

法規名稱：資通安全責任等級分級辦法

https://law.moj.gov.tw/LawClass/LawAll.aspx?pcode=A0030304

附表一 資通安全責任等級A級之公務機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298107&lan=C

附表二 資通安全責任等級A級之特定非公務機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298108&lan=C

附表三 資通安全責任等級B級之公務機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298109&lan=C

附表四 資通安全責任等級B級之特定非公務機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298110&lan=C

附表五 資通安全責任等級C級之公務機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298111&lan=C

附表六 資通安全責任等級C級之特定非公務機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298112&lan=C

附表七 資通安全責任等級D級之各機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298113&lan=C

附表八 資通安全責任等級E級之各機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298114&lan=C

附表九 資通系統防護需求分級原則.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000254363&lan=C

附表十 資通系統防護基準.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298115&lan=C

ChatGPT

「資通安全責任等級分級辦法」及其附表一至附表十 並 沒有出現 以下名詞：

• RPO（Recovery Point Objective，復原點目標）
• RTO（Recovery Time Objective，復原時間目標）
• MTPD（Maximum Tolerable Period of Disruption，可容忍中斷最長時間）

這些名詞屬於 業界標準資訊安全管理與營運持續管理（例如 ISO 22301、ISO/IEC 27031、ISO/IEC 27001 附錄 A.17） 的術語，

但在台灣的「資通安全責任等級分級辦法」及其附表中，通常會以「備援方案」、「災難復原演練」、「業務持續計畫（BCP）」等中文描述方式呈現，

並不直接使用 RPO / RTO / MTPD 的縮寫或定義。

********************************************************************************

補：附表一至附表六有提到 (「辦理內容」對不同等級機關可能略有不同

資訊安全管理系統之導入及通過公正第三方之驗證

初次受核定或等級變更後之二年內，全部核心資通系統導入CNS 27001 或ISO27001 等資訊安全管理系統標準、其他具有同等或以上效果之系統或標準，或其他公務機關自行發展並經主管機關認可之標準，於三年內完成公正第三方驗證，並持續維持其驗證有效性。

有錯或異動，以原文為準

管理面	A公務	A特定非公務	B公務	B特定非公務	C公務	C特定非公務	D公務、特定非公務	E公務、特定非公務
資訊安全管理系統之導入及通過公正第三方之驗證	初次受核定或等級變更後之二年內，全部核心資通系統導入 CNS 27001 或 ISO27001 等資訊安全管理系統標準、其他具有同等或以上效果之系統或標準，或其他公務機關自行發展並經主管機關認可之標準，於三年內完成公正第三方驗證，並持續維持其驗證有效性。	初次受核定或等級變更後之二年內，全部核心資通系統導入 CNS 27001 或ISO 27001 等資訊安全管理系統標準、其他具有同等或以上效果之系統或標準，或其他公務機關自行發展並經主管機關認可之標準，於三年內完成公正第三方驗證，並持續維持其驗證有效性。	初次受核定或等級變更後之二年內，全部核心資通系統導入 CNS 27001 或 ISO27001 等資訊安全管理系統標準、其他具有同等或以上效果之系統或標準，或其他公務機關自行發展並經主管機關認可之標準，於三年內完成公正第三方驗證，並持續維持其驗證有效性。	初次受核定或等級變更後之二年內，全部核心資通系統導入 CNS 27001 或 ISO27001 等資訊安全管理系統標準、其他具有同等或以上效果之系統或標準，或其他公務機關自行發展並經主管機關認可之標準，於三年內完成公正第三方驗證，並持續維持其驗證有效性。	初次受核定或等級變更後之二年內，全部核心資通系統導入 CNS 27001 或 ISO27001 等資訊安全管理系統標準、其他具有同等或以上效果之系統或標準，或其他公務機關自行發展並經主管機關認可之標準，並持續維持導入。	初次受核定或等級變更後之二年內，全部核心資通系統導入 CNS 27001 或 ISO27001 等資訊安全管理系統標準、其他具有同等或以上效果之系統或標準，或其他公務機關自行發展並經主管機關認可之標準，並持續維持導入。	無	無

(完)

相關

法規名稱：資通安全責任等級分級辦法
https://law.moj.gov.tw/LawClass/LawAll.aspx?pcode=A0030304

附表一 資通安全責任等級A級之公務機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298107&lan=C

附表二 資通安全責任等級A級之特定非公務機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298108&lan=C

附表三 資通安全責任等級B級之公務機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298109&lan=C

附表四 資通安全責任等級B級之特定非公務機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298110&lan=C

附表五 資通安全責任等級C級之公務機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298111&lan=C

附表六 資通安全責任等級C級之特定非公務機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298112&lan=C

附表七 資通安全責任等級D級之各機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298113&lan=C

附表八 資通安全責任等級E級之各機關應辦事項.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298114&lan=C

附表九 資通系統防護需求分級原則.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000254363&lan=C

附表十 資通系統防護基準.PDF
https://law.moj.gov.tw/LawClass/LawGetFile.ashx?FileId=0000298115&lan=C

法規名稱：資通安全事件通報及應變辦法
https://law.moj.gov.tw/LawClass/LawAll.aspx?pcode=A0030305

資安演練與稽核
https://moda.gov.tw/ACS/operations/drill-and-audit/652

[研究]高、中、普三種等級系統，ChatGPT 推薦的RPO / RTO / MTPD值

[研究]高、中、普三種等級系統，ChatGPT 推薦的RPO / RTO / MTPD值

2025-09-05

• RPO (Recovery Point Objective)：資料可容忍的最大丟失量（以時間計）。例如 RPO = 4 小時 → 最多可接受資料倒退到 4 小時前。
• RTO (Recovery Time Objective)：系統恢復到可用狀態所需的時間上限。例：RTO = 4 小時 → 服務中斷後，4 小時內必須恢復。
• MTPD (Maximum Tolerable Period of Disruption，又稱 MTD)：業務可容忍的最長停擺時間。超過這個時間，企業可能無法存活。

高、中、普三種等級系統，推薦的RPO / RTO / MTPD值 ?

ChatGPT 說：

好問題 👍

在實務上，系統會依 重要性（Criticality） 分成高、中、一般（或稱關鍵性 / 重要性 / 普通性），對應的 RPO / RTO / MTPD 設定差異很大。以下是常見的建議值範例（僅供參考，實際要看業務需求與成本）：

📊 推薦範例值

系統等級	RPO (資料丟失容忍度)	RTO (復原時間)	MTPD (可容忍中斷時間)	適用情境
高 (Critical)	幾分鐘 ~ 1 小時內	幾分鐘 ~ 1 小時內	2 ~ 4 小時	金融交易、醫療系統、電商支付、航空訂位
中 (Important)	4 ~ 12 小時	4 ~ 12 小時	1 ~ 2 天	ERP、CRM、進銷存、公司內部 OA 系統
普 (Normal / Supporting)	24 小時或更久	24 ~ 72 小時	3 ~ 7 天	行銷網站、知識庫、檔案分享、內部報表

📌 設定邏輯

• RPO 最短 → RTO 次之 → MTPD 最長
• 例如：高等級系統：RPO = 15 分鐘、RTO = 30 分鐘、MTPD = 4 小時。
• 等級越高，成本越高
• 高等級通常需要即時備援（雙活機房、同步複寫）。
• 中等級可用每日備份 + 異地備援。
• 一般等級只需定期備份（雲端或磁帶）。

• MTPD 保留緩衝
• 永遠要比 RTO 長，否則一旦超時就等於業務死亡，缺乏彈性。

(完)

相關

[研究]高、中、普三種等級系統，ChatGPT 推薦的RPO / RTO / MTPD值
https://shaurong.blogspot.com/2025/09/chatgpt-rpo-rto-mtpd.html

[研究]RPO, RTO, MTPD 三個值都相同，合理嗎？
https://shaurong.blogspot.com/2025/08/rpo-rto-mtpd.html

[研究]RPO, RTO, MTPD 三個值都相同，合理嗎？

[研究]RPO, RTO, MTPD 三個值都相同，合理嗎？

2025-08-28

RPO, RTO, MTPD 三個值都相同，例如 4,4,4 或 8,8,8，合理嗎？不合理？理由？

ChatGPT 說：

這個問題很有意思 👍

我們來逐一拆解 RPO、RTO、MTPD 三者的定義與邏輯關係：

1️⃣ 定義回顧

• RPO (Recovery Point Objective)：資料可容忍的最大丟失量（以時間計）。例如 RPO = 4 小時 → 最多可接受資料倒退到 4 小時前。
• RTO (Recovery Time Objective)：系統恢復到可用狀態所需的時間上限。例：RTO = 4 小時 → 服務中斷後，4 小時內必須恢復。
• MTPD (Maximum Tolerable Period of Disruption，又稱 MTD)：業務可容忍的最長停擺時間。超過這個時間，企業可能無法存活。

2️⃣ 邏輯關係

通常情況下三者應滿足：RPO ≤ RTO ≤ MTPD

理由：

• 資料丟失 (RPO) 容忍度通常比服務停擺 (RTO) 更嚴格，因為沒有資料就算服務起來也沒用。
• RTO 是 IT 層面能在多快時間內復原系統的目標。
• MTPD 是業務角度能容忍的最長停擺時間，理應 ≥ RTO。

3️⃣ 如果三個值都相同 (例如 4,4,4 或 8,8,8)

合理性：

• 在某些非常嚴格、對時間和資料都同等敏感的業務（例如即時交易平台、證券交易所），可能會設定 RPO、RTO、MTPD 幾乎相等，因為 資料不能丟，服務也不能停，超過就造成不可接受的影響。
• 若公司定義非常嚴謹，三者相等是可能的，但屬於 少見情況。

不合理性（更常見的解釋）：

• 一般業務情境下，MTPD 不會和 RTO 完全相等，因為通常會保留 緩衝時間。
• 例如：
• RPO = 4 小時（最多能接受丟 4 小時的資料）
• RTO = 6 小時（要在 6 小時內恢復服務）
• MTPD = 24 小時（業務最長能停一天）
• 如果 MTPD 與 RTO 一樣（例如 4=4），代表一旦超過 RTO 就直接等於業務死亡，沒有容錯空間 → 過於理想化/僵硬。

✅ 結論：

• 三個值相同 → 在極端嚴格的業務下是合理的，但通常不建議。
• 更合理的設定是：RPO 最短，RTO 次之，MTPD 最大，才能反映出 IT 能力與業務容忍度之間的階層關係。

(完)