恢復時間目標（ RTO ）定義了恢復服務所允許的最長時間。例如、人力資源資料庫的 RTO 可能為 24 小時、因為雖然在工作天內無法存取這些資料、但企業仍可繼續營運。相反地、支援銀行總分類帳的資料庫、其 RTO 會以分鐘甚至秒為單位來衡量。RTO 為零是不可能的、因為必須有辦法區分實際服務中斷和例行事件、例如遺失的網路封包。然而、典型的要求是接近零的 RTO 。

恢復點目標（ RPO ）定義了最大可容忍的資料遺失量。在許多情況下、 RPO 完全取決於快照或 SnapMirror 更新的頻率。

在某些情況下、 RPO 可能會變得更具侵略性、因此可選擇性地更頻繁地保護某些資料。在資料庫內容中、 RPO 通常是在特定情況下可能遺失多少記錄資料的問題。在資料庫因產品錯誤或使用者錯誤而受損的典型還原案例中、 RPO 應為零、表示不應有資料遺失。恢復程序包括還原較早的資料庫檔案複本、然後重新播放記錄檔、將資料庫狀態提升至所需的時間點。此作業所需的記錄檔應已在原始位置中。

在不尋常的情況下、記錄資料可能會遺失。例如、意外或惡意 rm -rf * 資料庫檔案可能會導致刪除所有資料。唯一的選擇是從備份還原、包括記錄檔、有些資料必然會遺失。在傳統備份環境中改善 RPO 的唯一選項是執行記錄資料的重複備份。然而、由於資料持續移動、而且難以將備份系統維持為持續運作的服務、因此這項功能也有其侷限性。進階儲存系統的優點之一、就是能夠保護資料、避免意外或惡意損壞檔案、進而在不移動資料的情況下提供更好的 RPO 。

災難恢復包括在發生實體災難時恢復服務所需的 IT 架構、原則和程序。這可能包括洪水、火災或惡意或疏忽意圖的人。

災難恢復不只是一套恢復程序。這是識別各種風險、定義資料恢復和服務持續性需求、以及提供適當架構及相關程序的完整程序。

在建立資料保護需求時、必須區分典型的 RPO 和 RTO 需求、以及災難恢復所需的 RPO 和 RTO 需求。有些應用程式環境需要零 RPO 和近乎零的 RTO 、才能因應資料遺失的情況、從相對正常的使用者錯誤到破壞資料中心的火災。然而、這些高層級的保護措施會產生成本和管理上的後果。

一般而言、非災難性資料恢復需求應嚴格、原因有兩個。首先、應用程式錯誤和使用者錯誤會導致資料受損、幾乎是不可避免的。其次、只要儲存系統未遭銷毀、就不難設計出可提供零 RPO 和低 RTO 的備份策略。沒有理由不解決容易補救的重大風險、這就是為何用於本機恢復的 RPO 和 RTO 目標應該積極主動的原因。

災難恢復 RTO 和 RPO 需求因災難可能性及相關資料遺失或業務中斷所造成的後果而異。RPO 和 RTO 需求應以實際業務需求為基礎、而非一般原則。他們必須考慮多種邏輯和實體災難案例。

資料保護策略的最後一個層面是資料保留時間、這可能會大幅改變。