RPO: Recovery Point Objective, 可容許的最大資料損失量
RTO: Recovery Time Objective, 讓系統重新上線的時間
WRT: Work Recovery Time, 讓所有業務和作業, 回到事故發生前的水平 (恢復SLA), 所需的時間
MTD: Max Tolerable Downtime, 可容許的最長系統 Down Time
用自己的理解, 重畫了一張圖, 再搭配上面的翻譯說明, 感覺比較清楚一點
例: 假設每天早上固定6:00備份, 10:00時忽然發生事故, 系統無法繼續服務.
這裡的 "事故" 是相對比較嚴重的規模, 至少除了系統離線/當機之外, 連硬碟上的資料都消失了.
RPO = 10 - 6 = 4
6:00 ~ 10:00 之間的資料, 依照這裡的定義, 是救不回來的, 因為這裡的資料是在2次備份中間的時間所輸入的, 所以RPO的意義 = 可容許的最大資料損失量
如果10:00立即起動DR, 12:00時系統總算恢復運作
RTO = 12 - 10 = 2
這裡指的 "恢復運作", 是指系統又活了起來, 可以讓同仁開始工作了. 但是資料是空的
在實務上也許會認為, 一個資料空空的系統, 怎麼可能運作?
我個人以為, RTO是比較理論的定義; 如果這種理論和實務上的差異, 讓你很難接受的話, 或許也可以解釋成, 系統恢復上線, 而且一些基本資料也已就緒, 但是過去的歷史資料還沒有還原.
12:00系統恢復上線後, 一面載入最近的備份 (前述早上6:00那次), 同仁一面恢復工作, 另一方面還要在系統補做 10:00 ~12:00之間, 因為系統當機而沒有做的工作, 直到下午15:00才全部完成
WRT = 15 - 12 = 3
這裡也許會有個疑問: 既然上一次只備份到6:00, 那麼為什麼不是在系統上補做 6:00 ~ 12:00 的工作, 那麼所有資料不就都回復了嗎?
我個人還是以為, WRT也是一個比較理論且通用的一般 (General) 定義. 世界上各種系統的功能和特性不同, 不見得所有系統都能這麼理想, 可以人工把 6:00 ~ 的資料重 Key 一遍.
另外一點可能的疑問是, WRT的這段時間, 同仁真的可以恢復工作嗎?
理論上, 這段時間仍算做系統的 Down time, 如果狀況允許的話, 或許可以讓同仁恢復 "部份" 的工作, 但仍要視系統及工作的性質而定.
這裡用一個診所的病歷系統當做例子; 假設這家診所早上6:00系統備份完成後, 就馬上開門看診, 在6:00 ~ 10:00之間, 醫生看診的診斷處方, 都直接輸入到電腦系統裡.
(...這裡所提到的時間, 都是配合上述 RPO/RTO/WRT 的說明內容...就不要去追究 "哪有這麼勤奮的診所在早上6:00就開門"....這樣的問題了.)
10:00之後系統發生意外全毀, 但是診所仍需持續看診. 在沒有系統可用的情形下, 醫生只好把接下來的病人的診斷處方, 先用手寫在紙本上.
然而6:00 ~ 10:00 之間的資料, 因為當初是直接輸入在已損毀的系統裡, 沒有備份, 又沒有紙本記錄, 所以是救不回來的.
12:00之後系統恢復了, 這可能是一個新建立的系統, 也許常用處方或藥品名稱等基本資料, 已一併先灌回去了, 但沒有以前的所有病歷資料
醫生又可以把 12:00之後的病人的診斷處方, 直接輸入到電腦系統裡, 但得要同時開始做2件事: (1) 把6:00 的備份資料還原 (2) 把10:00開始手寫在紙本上的診斷處方資料, 補登到系統裡.
把這2件事都做完, 最後檢查有沒有問題, 所花的全部時間, 就是WRT.
WRT這段時間中, 雖然系統已可使用, 但是因為病人的病歷資料還沒完全復原, 因此還不能視為已恢復正常運作. 例如這時若醫生要查看某某病人上次開了什麼藥, 先前的病史, 有可能查不到.
以上是我的小心得整理. 如有疏漏也請不吝指點.
留言列表
