近年來天災人禍不斷, 資訊人面臨備援問題的機會越來越多, 同時牽動的層面也越來越廣, 以往只要注重軟硬體備援技術既可, 基本上, 還是應用在伺服器, 所以一般資訊人還可以掌握. 但是到了雲端和資料中心的備援規畫, 這就需要其他專業人士的介入, 複雜許多.

和這些專業人士訪談, 有兩個專業術語一定會被提到的 : RTO (Recovery Time Objective) 和 RPO (Recovery Point Objective). 所謂 RTO 就是可以多快的恢復系統運作, 而 RPO 就是可以容許多少資料量遺失, 所以兩者之間是有關聯的, 同時需要取得一定的平衡, 避免投資過大.

在設計一個容災系統時，不能過分追求 RPO 和 RTO，因為 RPO 和 RTO 越小，投資將越大。而總體投入成本越高，投資回報率將越低。從經濟角度考慮，最佳的容災解決方案不一定是效益最好的容災解決方案，因為容災系統的總體投入 TCO和投資回報ROI，對於企業來說是十分重要的設計指標.

通常資料庫的備援方式會左右 RPO 和 RTO 的數值. 每天夜晚的資料備份工作已經成為企業備援的最低水平, 許多企業的 ERP 和生產系統對於 RPO 值為 1 天是無法接受的. 為了降低 RPO 值, 快照或連續複製(例如鏡像方式)等技術多會被使用上.

當然像 Google, Amarzon, Yahoo 等雲端公司就更高端了, 散落在全球各地的資料中心是併行運作的, 可以作動態切換, 相對地, 對於網路頻寬的需求大增, 因為使用同步複製技術, 所以 RPO 和 RTO 的數值幾乎為 0. 當然這也是在理想狀態, Gmail 還是會發生停機和郵件遺失的狀況, 所以跨地域的備援計畫最為複雜, 還需要上知天文, 下知地理,