RTO（Recovery Time Object)恢復時間目標
恢復時間目標，指在故障或災難發生之后，一台電腦、系統、網絡或應用停止工作的最高可承受時間。該參數定義了最大可容忍時限，必須在此時限內恢復數據。如果說系統需要在災難發生的12個小時內恢復，那么RTO數值就是12小時。RTO具體時間長短只是從故障發生后，從系統宕機導致業務中斷的那一刻開始，到系統恢復至可以支持各業務正常運作之時，這兩個節點之間的時間段。RTO是反映系統業務恢復的及時性指標，表示業務從中斷到恢復正常所需的時間，RTO數值越小，代表容災系統的數據恢復能力越強。RTO=0就意味着在任何情況下都不允許目標業務有任何運營停頓。
RPO（Recovery Point Object)恢復點目標
恢復點目標，指一個過去的時間點，當災難或緊急事件發生時，數據可以恢復到的時間點，是業務系統所能容忍的數據丟失量。例如每天00：00進行數據備份，那么如果今天發生了宕機事件，數據可以恢復到的時間點（RPO）就是今天的00：00，如果凌晨3點發生災難或宕機事件，損失的數據就是三個小時，如果23：59發生災難，那么損失的數據就是約24小時，所以該用戶的RPO就是24小時，即用戶最大的數據損失量是24小時。所以RPO指的是用戶允許損失的最大數據量。這和數據備份的頻率有關，為了改進RPO，必然要增加數據備份的頻率才行。RPO指標主要反映了業務連續性管理體系下備用數據的有效性，即RPO取值越小，表示系統對數據完整性的保證能力越強。
RTO和RPO指標並不是孤立的，而是從不同角度來反映數據中心的容災能力。
RTO和RPO
概述：恢復時間目標(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數據庫停機，該站點將立即接管處理。
以上內容來自網絡，如有侵權，請留言以便刪除。