一、災備保護的什么？
對於各行各業而言，用戶數據、系統數據均是企業最核心、最重要的財富，但以下種種原因，都可能給數據帶來不可逆轉的損壞。只有完善的災備方案，才能最終保障數據安全、業務連續性。隨着互聯網市場的蓬勃發展，及用戶對數據重視程度的日益提高，據智研數據中心統計數據，災備行業的市場規模已達百億規模，且預計會逐年持續增長。
二、什么是災備？
災備是容災和備份的簡稱。災備方案=容災方案+備份方案。
- 容災的定義：指在相隔較遠的兩地（同城或者異地）建立兩套或多套功能相同的IT系統，互相之間可以進行健康狀態監視和功能切換。當一處系統因意外（天災、人禍）停止工作時，整個應用系統可以切換到另一處，使得該系統功能可以繼續正常工作。側重數據同步和系統持續可用。
- 備份的定義：指用戶為應用系統產生的重要數據（或者原有的重要數據信息）制作一份或者多份拷貝，以增強數據的安全。側重數據的備份和保存。
三、災備的兩個關鍵技術指標
RTO：RecoveryTime Object，恢復時間目標。指災難發生后，從IT系統宕機導致業務停頓之刻開始，到IT系統恢復至可以支持各部門運作，業務恢復運營之時，此兩點之間的時間段稱為RTO。
RTO是反映業務恢復及時性的指標，體現了企業能容忍的IT系統最長恢復時間。設目標RTO值設定的越小，代表對容災系統的恢復能力要求越強，但企業投資也越高。
RPO：Recovery Point Object，恢復點目標。指災難發生后，容災系統進行數據恢復，恢復得來的數據所對應的時間點稱為RPO。
RPO是反映數據丟失量的指標，體現了企業能容忍的最大數據丟失量的指標。目標RPO值設定的越小，代表企業允許的數據丟失越少，企業損失越小。
設計災備方案的核心是：幫助客戶平衡RTO/RPO的需求和客戶經濟能力，找到最佳的實現技術和手段，適合的才是最好的。
四、備份的分類
分類方式
分類
按照備份內容
操作系統備份、數據備份
按照備份數據量
全量備份、增量備份、差異備份
按照備份形式
（主要針對數據庫）
物理備份、邏輯備份
按照備份時數據庫是否啟動
（主要針對數據庫）
冷備份、熱備份
按照備份介質
磁帶備份、磁盤備份
為了大家更輕松的理解這些分類，下面我詳細解釋下冷備、熱備，增量備份和差異備份的差異：
分類
優點
缺點
冷備
將數據以隔離的方式來保存，
備份數據不受原數據的影響；
解決了硬件故障、人為誤操作。
數據恢復慢
熱備（又稱冗余)
搭建冗余的環境，數據完全一致;
恢復速度快，瞬間恢復。
只能解決硬件故障，
不能解決人為誤操作
分類
定義
全量備份
備份所有數據
增量備份
針對上一次備份所作的增量備份（上一次的備份可以是全備，可以是增備）
差異備份
針對上一次的全備份所做的增量備份
五、雲產品的災備特性
以下講解以阿里雲為例，其他雲平台會有些許不同，大家可自行查閱官方文檔。
ECS備份
備份類型
災備級別
雲磁盤三副本數據備份
解決底層硬件級別的故障，防范單點故障
快照/鏡像
解決誤操作，網絡攻擊等人為故障引起的數據損壞
SLB容災（高可用）
SLB負載均衡
災備分類
災備級別
單可用區+單可用區SLB
是集群級別的災備，防范了單點故障；
不具備機房級別的災備能力和跨地域（城市）級別的容災能力。
多可用區ECS+主備可用區SLB（是單個實例）
集群級別的災備+機房級別的災備,防范了單個機房斷電等意外災難；
不具備跨地域（城市）級別的災備能力
多區域+跨地域多SLB實例+智能解析
結合雲解析（全球負載均衡版），實現多線路智能解析和跨地域容災。
RDS容災（高可用）
RDS數據庫
災備分類
災備級別
高可用版+單可用區
集群級別的災備，防范了單點故障
高可用版+多可用區
集群級別的災備+機房級別的災備，防范了單個機房斷電、火災等意外災難
高可用版+災備實例
集群級別的容災+機房級別的容災+跨地域（城市）級別的容災
數據庫（含RDS)備份
數據庫備份分類
備份方式
優缺點
傳統冷備
本地備份：將備份集拷貝到本機其他盤、其他機器；
異地容災：用戶在其他地區自行搭建備份機房。
本地備份：無法抵御地震、台風等自然災害；
異地備份：前期投入很大
阿里雲DBS冷備
同城：DBS地域和備份源數據庫相同；
異地：DBS地域和備份源數據庫不同
可按量付費成本低；可將本地IDC數據庫、其他雲數據庫、ECS自建數據庫和RDS數據庫備份到OSS；異地備份更簡單
六、幾種常見的災備架構
1、用雲搭建異地容災中心
本地物理機房為主數據中心，僅將數據備份到雲端。
2、基於公共雲的同城災備
將全部系統遷移上雲，並部署在同一個地域的兩個不同可用區中，實現系統的同城災備。
3、基於公共雲的異地災備
將全部系統遷移上雲，並部署在兩個不同的地域中，實現跨地域災備。
4、結合公共雲同城災備和異地災備
如：兩地三中心，
七、分析幾起嚴重的數據丟失事故
爐石傳說故障
2017年1月18日，由網易代理的暴雪旗下卡牌類游戲《爐石傳說》遭遇了重大故障，從1月17日凌晨1點開始開始維護，直到1月18日下午18點才完成。
而更為可怕的是，《爐石傳說》的數據並沒有恢復，備份數據庫也出現了故障，因此這款游戲的玩家被迫回檔到1月14日15點20分。
案例分析：高可用沒做好，導致實際RTO很長；
數據備份方案設計不完善，應充分考慮同機房不同機器+異地備份等方式，避免備庫一起損壞。
Gitlab數據庫被刪除
2017年2月1日，GitLab 一位身處荷蘭的疲憊系統管理員在進行數據庫復制過程中不小心在一台錯誤的服務器上刪除了一個目錄，他刪除了一個包含 300GB 實時產品數據的文件夾，在取消 rm -rf 刪除命令后該文件夾只剩下 4.5GB 數據。並且最近的數據還是在6小時前備份的。
GitLab.com號稱有五重備份機制：常規備份（24小時做一次）、自動同步、LVM快照（24小時做一次）、Azure備份（只對 NFS 啟用，對數據庫無效）、S3備份。這次事故發生時，所有備份全部無效！
案例分析：備份方案設計多么重要！周期性的災難恢復演練（驗證備份的有效性）多么重要！
騰訊雲盤故障,致用戶數據完全丟失
騰訊稱該故障緣起於因磁盤靜默錯誤導致的單副本數據錯誤，再加上騰訊運維人員在數據遷移過程中的兩次不規范的操作，導致雲盤的三副本安全機制失效，並最終導致數據完整性受損。
案例分析：單一的數據備份方式可能造成不可逆轉的損失；多種備份方式結合使用，可最大概率的降低風險。