如今，災難以多種形式出現。破壞、盜竊、遺失或自然災害都會使企業的應用程式崩潰並破壞其資料。在理想的情況下，企業的資料保護基礎設施可以立即在故障點時間恢復所有的應用程式和資料。
企業可以立即切換故障應用程式，並連續複製其資料以實現接近零的損失。但是這些操作耗費資源並且很昂貴。實際上，it部門需要根據預算、資源和應用優先順序來設定不同的恢復時間和恢復點目標。
人們將這兩個目標稱為恢復時間目標(rto)和恢復點目標(rpo)。它們是相關的，並且這兩者都是應用程式和資料恢復所必需的。它們也是不同用途的度量指標。
以下討論一下它們是什麼，它們的相似之處和不同之處，以及為什麼需要分析應用程式的優先順序來平衡資源和應用程式的可用性。
定義rto和rpo
(1)rto：恢復時間目標
rto指的是應用程式可以中斷或關閉多少時間而不會對業務造成重大損害。有些應用程式可能會停機數天而不會產生嚴重的後果。而一些高優先順序的應用程式只能停下來幾秒鐘，否則將會讓企業和客戶難以應對，並導致業務丟失。
rto不僅僅是業務損失和恢復之間的持續時間。這個目標還包括it部門必須採取的步驟來恢復應用程式及其資料。如果it已經投入高優先順序應用程式的故障轉移服務，那麼它們可以在幾秒鐘內安全地表達rto(it部門必須恢復本地環境，但由於應用程式正在雲中進行處理，因此it部門可能需要一些時間)。
企業的rto任務是根據優先順序和潛在業務損失對應用程式進行分類，並相應地匹配企業的資源。例如，接近零的rto的典型計畫將需要故障轉移服務。4小時rto允許從裸機恢復開始進行本地恢復，並以完整的應用程式和資料可用性結束。對於8小時以上的rto，it團隊可以與本地系統整合商簽署維護合同。
(2)rpo：恢復點目標
恢復點目標是指企業的損失容限：在對業務造成重大損害之前可能丟失的資料量。該目標表示為從丟失事件到最近一次在前備份的時間度量。
如果以定期計畫的24小時增量備份全部或大部分資料，那麼在最壞的情況下，企業將丟失24小時的資料。對於某些應用來說，這是可以接受的，對於其他人來說並不是這樣。
例如，如果企業的應用程式具有4小時rpo，那麼備份和資料丟失之間的最大間隔時間將為4小時。擁有4小時的rpo並不一定意味著企業將失去4小時的資料。例如乙個文書處理應用程式在午夜停止執行並在凌晨出現故障，那麼可能沒有丟失太多(或任何)資料。但是如果乙個任務繁忙的應用程式在上午10點關閉並且直到下午2點才恢復，那麼企業可能會失去4個小時的**值並且可能無法替代的資料。在這種情況下，需要進行更加頻繁的備份，以便訪問特定於應用程式的rpo。
這取決於應用優先順序，單個rpo的範圍通常為24小時、12小時、8小時、4小時。以秒為單位測量到接近零。只要對生產系統的影響最小，8小時以上的rpo就可以利用現有的備份解決方案。4小時的rpo將需要計畫的快照複製，而接近零的rpo將需要連續複製。在rpo和rto都接近於零的情況下，將連續複製與故障轉移服務結合使用，以實現接近100%的應用程式和資料可用性。
rto和rpo如何相似以及不同的原因
(1)rto和rpo的幾個特徵
*恢復時間和恢復點目標因應用程式和資料優先順序而異。即使是規模和實力最強的公司也不能為所有應用程式提供接近零的rto或rpo，也不應該這樣做。
*確保100%正常執行時間(rto)和沒有丟失資料(rpo)的唯一方法是投資連續資料複製功能的故障轉移虛擬環境。
*it優先處理應用程式和資料以匹配所實現的rto和rpo的費用。請注意，優先事項不僅取決於收入，還取決於風險。企業可能不經常使用應用程式，但如果其資料受到管制，那麼資料丟失可能會導致鉅額罰款。
* rto和rpo均以時間為單位進行測量。對於rto來說，其度量標準是應用程式失敗和包括資料恢復在內的完整可用性之間的時間量。rpo也以時間單位來衡量。度量標準是資料丟失和前一次備份之間的時間間隔。對於rto和rpo來說，其應用程式/資料優先順序可直接轉換為更短的時間單位。
(2)rto和rpo的目標存在巨大的差異
儘管它們有相似之處，但rpo和rto服務於不同的目標。rto涉及應用程式和系統，但主要描述應用程式停機時間的限制。
rpo主要與失敗事件後丟失的資料量有關。但是，損失數十萬美元的客戶交易將是災難性的後果。
rto和rpo在行動中的例項
?單一檔案恢復：例如一家公司員工意外刪除乙個時間敏感的電子郵件，然後清空**站和資料夾的內容。由於microsoft exchange是這家公司的業務關鍵型應用程式，因此it部門不斷支援exchange中的增量更改。而且由於他們的備份應用程式能夠進行精細的備份和恢復，他們可以在5分鐘的rto內恢復單個檔案，而不用為單個檔案恢復整個虛擬機器。
?電子商務**：例如，一家零售商店的自營電子商務**使用三種不同的資料庫：儲存產品目錄的關聯式資料庫，報告歷史訂單資料的文件資料庫，以及連線到其支付處理器閘道器的api資料庫。檔案資料庫可以重建來自其他資料庫的資料，因此其rto和rpo是在24小時內。該業務每週只向關聯式資料庫新增一次產品，因此rpo並不重要。 其rto是如果資料庫關閉，則客戶交易停止。
為了保持高可用性，這家商店採用了故障轉移服務，因此資料庫立即在虛擬伺服器上執行。該公司將其在一周內進行的少量更改複製到其提供商的災難恢復平台。api資料庫包含訂購資訊，並且需要幾秒鐘才能完成rpo和rto。 it部門不斷地將資料複製到故障轉移站點，如果api資料庫停機，該站點將立即接管處理。
成本考慮
調查表明，年收入1億美元的公司在24小時宕機期間將損失約275,000美元。而將在4小時快照複製計畫中損失約45,000美元，使用接近於零的連續複製的損失約為7600美元。
實際上，這個數量可能會更小或更大，具體取決於企業一天中的時間和應用程式活動。繁忙的任務或業務關鍵應用程式會比不太頻繁的應用程式丟失更多的資料和更高優先順序的資料。
企業需要相應地規劃rpo和rto，並在需要之前購買所需的資源。就像購買保險一樣，企業可能永遠不必使用它們，但可能會挽救其業務。
基於時間點恢復 mysql binlog
data mysq mysqlbin.000026 mysqlbinlog檔案，恢復如下內容 注意 按照時間點恢復時，可能同乙個時間點有其他的操作，要結合上下文的時間選取 at 523 181113 17 15 44server id 161 end log pos 554 crc32 0x2ad4...
資料庫PostrageSQL 恢復目標設定
預設情況下，恢復將會一直恢復到 wal 日誌的末尾。下面的引數可以被用來指定乙個更早的停止點。在recovery target recovery target lsn recovery target name recovery target time recovery target xid中，最多只...
RMAN表空間時間點恢復
img 一直想做個基於時間點的表空間恢復，今天測試了一下，做個筆記，方面以後查閱！環境 linux 5.2 10.2.0.1 rman tspitr 使用rman進行表空間基於時間點的恢復 例項說明 1 先建立2個表空間。create tablespace user01 datafile dg1 s...