本次課程分享了 AWS DR Use case、WHAT and WHY DR、HOW to build DR、Actional next steps, how we can cooperate for the business、QA and Open Discussion

4天當機，用戶掉了800萬用戶，所要有一個好的DR策略，AWS 提供相對簡單好用的工具可以使用。

學習到了之後，可以主動當成業務，觸及客戶，節省了80%的成本
AWS 要用才啟動它

RTO(Recovery Time Objective，復原時間目標)

是數據中心可容許服務中斷的時間長度。比如說服務發生後半天內便需要恢復，RTO數值就是十二小時。RTO具體時間長 短只是從故障發生後，從數據中心系統宕機導致應用停頓之刻開始，到數據中心系統恢復至可以支持各部門運作之時，此兩點之間的時間段。RTO是反映數據中心 業務恢復的及時性指標，表示業務從中斷到恢復正常所需的時間，RTO數值越小，代表容災系統的數據恢復能力越強，數據中心可以部署很多容災系統，來獲取最 小的RTO，但這意味著投入大量資金。

RPO（Recovery Point Objective，復原點目標）

是指數據中心能容忍的最大數據丟失量，是指當業務恢復後，恢復得來的數據所對應時間點，RPO取決於數據中心數據恢復到 怎樣的更新程度，這種更新程度可以是上一周的備份數據，也可以是昨天的數據，這和數據備份的頻率有關，為了改進RPO，必然要增加數據備份的頻率才行。 RPO是反映數據中心恢複數據完整性的指標。在同步數據複製方式下，RPO等於數據傳輸時延的時間，在異步數據複製方式下，RPO基本為異步傳輸數據排隊 的時間。

備份是非常重要的，以及遇到災難的時候如何復原。

DR的第一的步驟是管理失敗

系統可以用的時間，去除以總共的時間。

每個AZ 間隔 100公里，確保AZ 有狀況時可以繼續使用。

S3/ DB 自動做備援服務

國際關係緊張，大規模的災難等，會需要做DR的規劃。

這兩個指標將會影響DR的選擇。

舉玩麻將的線上遊戲做舉例：

Backup & Restore：重啟後剛剛的資料會不見，要重新來過。

Pilot Light：遊戲恢復很快以外，剛剛的資料都會在。

Warm Standby：VIP玩家還能在線上玩遊戲，但一般玩家可能要等幾分鐘，遊戲恢復。

Active/Active：零容忍，玩家不會發現有災害發生。

依照適合的遊戲屬性做選擇適合自己需求的DR服務。

有什麼服務可以直接協助去做DR。

雲端本身就已經符合規範，可以快速增加Server、不用先買機器、沒有折舊問題。

恢復時不只有資料本身，還包含相關服務。

資料備份就不怕被別人加密。

因為是差異化的備份，所以可以回到最新的那份，可以完全回到被攻擊前的狀態。

可以透過此機制，建構測試環境，新服務進來DR 發生時也能演練流程正不正確。

需要先定義要花多少錢，以及軟體架構。

安裝完之後就可以開始使用。

比較繁瑣的是一開始安裝Agent的過程。

#總結：

QuickStart 如何設定的相關教學

Q: 蠻多遊戲沒辦法裝Agent，這樣的狀態下如何幫客戶做DR?

A: 不是不能做，只是需要人工自己要做的部分比較多，怎麼做會需要更多的討論。

根據RTO / RPO 去看他的架構評估可以怎麼做，多久備份一次，可以怎麼做？

Q: 地端要備的資源大小，去評估說哪種方式做傳輸要花多少的時間？

A: 通常是看DB的大小，但是通常會很久，因為通常也是幾T的資料傳輸。

先提供RTO/RPO，資料備份量多大？

通常不要求走專線都會蠻快的。