RTO 和 RPO 都是企業(yè)災難恢復（Disaster Recovery, DR）需要考慮的關(guān)鍵指標，這兩個指標可以用來指導企業(yè)來制定合適的業(yè)務(wù)系統(tǒng)服務(wù)或數(shù)據(jù)的恢復方案。

RPO（Recovery Point Objective）：即數(shù)據(jù)恢復點目標，主要指的是業(yè)務(wù)系統(tǒng)所能容忍的數(shù)據(jù)丟失量。

如果以定期計劃的24小時增量備份全部或大部分數(shù)據(jù)，那么在最壞的情況下，企業(yè)將丟失24小時的數(shù)據(jù)。對于某些應用來說，這是可以接受的，對于其他應用來說并不是這樣。

例如：如果企業(yè)的應用程序具有4小時RPO，那么備份和數(shù)據(jù)丟失之間的間隔時間將為4小時。擁有4小時的RPO并不一定意味著企業(yè)將失去4小時的數(shù)據(jù)。
例如：一個文字處理應用程序在午夜停止運行并在凌晨出現(xiàn)故障，那么可能沒有丟失太多(或任何)數(shù)據(jù)。但是如果一個任務(wù)繁忙的應用程序在上午10點關(guān)閉并且直到下午2點才恢復，那么企業(yè)可能會失去4個小時的高價值并且可能無法替代的數(shù)據(jù)。
在這種情況下，需要進行更加頻繁的備份，以便訪問特定于應用程序的RPO。

取決于應用的優(yōu)先級，單個RPO的范圍通常為24小時、12小時、8小時、4小時。以秒為單位測量到接近零。
只要對生產(chǎn)系統(tǒng)的影響最小，8小時以上的RPO就可以利用現(xiàn)有的備份解決方案。
4小時的RPO將需要計劃的快照復制，而接近零的RPO將需要連續(xù)復制。
在RPO和RTO都接近于零的情況下，將連續(xù)復制與故障轉(zhuǎn)移服務(wù)結(jié)合使用，以實現(xiàn)接近100%的應用程序和數(shù)據(jù)可用性。

RTO（Recovery Time Objective）：即恢復時間目標，主要指的是所能容忍的業(yè)務(wù)停止服務(wù)的最長時間，也就是從災難發(fā)生到業(yè)務(wù)系統(tǒng)恢復服務(wù)功能所需要的最短時間周期，此兩點之間的時間段稱為RTO。

RTO不僅僅是業(yè)務(wù)損失和恢復之間的持續(xù)時間。這個目標還包括IT部門必須采取的步驟來恢復應用程序及其數(shù)據(jù)。如果IT已經(jīng)投入高優(yōu)先級應用程序的故障轉(zhuǎn)移服務(wù)，那么它們可以在幾秒鐘內(nèi)安全地表達RTO(IT部門必須恢復本地環(huán)境，但由于應用程序正在云中進行處理，因此IT部門可能需要一些時間)。

企業(yè)的RTO任務(wù)是根據(jù)優(yōu)先級和潛在業(yè)務(wù)損失對應用程序進行分類，并相應地匹配企業(yè)的資源。

例如，接近零的RTO的典型計劃將需要故障轉(zhuǎn)移服務(wù)。4小時RTO允許從裸機恢復開始進行本地恢復，并以完整的應用程序和數(shù)據(jù)可用性結(jié)束。對于8小時以上的RTO，IT團隊可以與本地系統(tǒng)集成商簽署維護合同。

1.相同點與不同點

RTO 和 RPO 都是使用時間來度量。

• 對于 RTO 時間，是指災難發(fā)生到服務(wù)恢復的時間，這個時間也包含了數(shù)據(jù)恢復的時間。
• 對于 RPO 時間，是指災難發(fā)生到數(shù)據(jù)上一次備份的時間。

雖然 RTO 和 RPO 都使用時間來度量，但是使用它們的目的卻不相同。

• RTO 關(guān)注于應用或系統(tǒng)的可用性，RTO 雖然包含數(shù)據(jù)恢復的時間，但更多地是描述應用停機的時間限制。
• RPO 關(guān)注于數(shù)據(jù)的完整性，描述所能容忍的最大數(shù)據(jù)丟失限制。業(yè)務(wù)系統(tǒng)服務(wù)不可用會帶來經(jīng)濟損失，但如果丟失的是客戶交易數(shù)據(jù)則導致的損失更是災難性的。

2.備份策略

在制定企業(yè)的容災計劃時，需要考慮 RTO 和 RPO 目標，然而 RTO 和 RPO 目標的成本存在差異。維護一個高要求的 RTO 目標的成本可能比 RPO 目標的成本要高，這是因為 RTO 涉及到整個業(yè)務(wù)基礎(chǔ)架構(gòu)，而不僅僅是數(shù)據(jù)。
要實現(xiàn) RPO 目標，只需要以正確的時間間隔執(zhí)行數(shù)據(jù)備份，數(shù)據(jù)備份可以很容易地自動化實現(xiàn)，因此自動化的 RPO 策略很容易實現(xiàn)。
另一方面，由于 RTO 涉及恢復所有 IT 操作，因此完全自動化的 RTO 策略實現(xiàn)更復雜。
RTO 和 RPO 對于制定容災計劃時都很重要，各個企業(yè)業(yè)務(wù)場景不同，這需要我們根據(jù)實際情況來選擇合適的 RTO 和 RPO 目標，以達到經(jīng)濟效益的最大化。

3.備份場景實例

1.單一文件恢復：
例如，一家公司員工意外刪除一個時間敏感的電子郵件，然后清空回收站和文件夾的內(nèi)容。
由于Microsoft Exchange是這家公司的業(yè)務(wù)關(guān)鍵型應用程序，因此IT部門不斷支持Exchange中的增量更改。而且由于他們的備份應用程序能夠進行精細的備份和恢復，他們可以在5分鐘的RTO內(nèi)恢復單個文件，而不用為單個文件恢復整個虛擬機。

2.電子商務(wù)網(wǎng)站：
例如，一家零售商店的自營電子商務(wù)網(wǎng)站使用三種不同的數(shù)據(jù)庫：

• 存儲產(chǎn)品目錄的關(guān)系數(shù)據(jù)庫
• 報告歷史訂單數(shù)據(jù)的文檔數(shù)據(jù)庫
• 以及連接到其支付處理器網(wǎng)關(guān)的API數(shù)據(jù)庫

文件數(shù)據(jù)庫可以重建來自其他數(shù)據(jù)庫的數(shù)據(jù)，因此其RTO和RPO是在24小時內(nèi)。
該業(yè)務(wù)每周只向關(guān)系數(shù)據(jù)庫添加一次產(chǎn)品，因此RPO并不重要。 其RTO是如果數(shù)據(jù)庫關(guān)閉，則客戶交易停止。
為了保持高可用性，這家商店采用了故障轉(zhuǎn)移服務(wù)，因此數(shù)據(jù)庫立即在虛擬服務(wù)器上運行。該公司將其在一周內(nèi)進行的少量更改復制到其提供商的災難恢復平臺。API數(shù)據(jù)庫包含訂購信息，并且需要幾秒鐘才能完成RPO和RTO。 IT部門不斷地將數(shù)據(jù)復制到故障轉(zhuǎn)移站點，如果API數(shù)據(jù)庫停機，該站點將立即接管處理。

總結(jié)

以上是生活随笔為你收集整理的一篇文章让你了解灾备指标：RPO与RTO的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。