RTO：恢復時間目標
RTO是指應用程序可以關閉多少時間而不會對業務造成重大損害。某些應用程序可能會停機幾天，而不會造成嚴重後果。某些高優先級的應用程序只能停機幾秒鐘，而不會引起員工的不滿，客戶的憤怒和業務的損失。
RTO不僅僅是損失和恢復之間的持續時間。該目標還說明了IT部門必須採取的還原應用程序及其數據的步驟。如果IT投資了用於高優先級應用程序的故障轉移服務，那麼他們可以在幾秒鐘內安全地表示RTO。 （IT部門仍必須還原本地環境。但是，由於應用程序是在雲中處理的，因此IT部門可能會花一些時間。）
您的RTO任務是按優先級和潛在業務損失對應用程序進行分類，並相應地匹配您的資源。例如，接近零RTO的典型計劃將需要故障轉移服務。 4小時的RTO允許從裸機還原開始到本地還原，並從完整的應用程序和數據可用性結束。對於8小時以上的RTO，IT可以與本地系統集成商簽訂維護合同。
RPO：恢復點目標
恢復點目標是指公司的損失容忍度：在對業務造成重大損害之前可以丟失的數據量。該目標表示爲從丟失事件到最近的先前備份的時間度量。
如果您以預定的24小時增量備份全部或大部分數據，那麼在最壞的情況下，您將丟失價值24小時的數據。對於某些應用程序，這是可以接受的。對於其他人來說絕對不是。
例如，如果您的應用程序有一個4小時的RPO，則備份和數據丟失之間的最大間隔爲4小時。擁有4小時的RPO並不一定意味着您會損失4小時的數據量。如果文字處理應用程序在午夜關閉並在上午1:15之前啓動，則可能沒有太多（或任何）數據丟失。但是，如果繁忙的應用程序在上午10點關閉，並且直到2:00 pm才恢復，那麼您可能會丟失4個小時的有價值的，可能是不可替代的數據。在這種情況下，安排更頻繁的備份，使您可以達到應用程序特定的RPO。
根據應用程序的優先級，各個RPO的範圍通常爲24小時至12小時，8至4小時；下降到接近零（以秒爲單位）。只要對生產系統的影響降到最低，超過8小時的RPO便可以利用您現有的備份解決方案。 4小時的RPO將需要計劃的快照複製，而接近零的RPO將需要連續複製。如果RPO和RTO都接近於零，則將連續複製與故障轉移服務結合使用，以實現近100％的應用程序和數據可用性。
