背景介紹
在實際使用中,使用者經常遇到需要對資料做備份的情境,例如:
幻獸帕魯遊戲的私服,因遊戲本身原因經常會出現掉檔情況,為解決這個問題,需要按時備份。
某資料庫服務,為保證資料安全,需要進行備份,降低可能發生的故障損失。
某服務,需要做升級,但是升級過程中可能導致資料丟失。因此在升級操作前做資料備份。
在過去,計算巢使用者遇到需要備份服務執行個體資料的情境,需要自行在各雲產品的控制台做備份。例如,如果服務執行個體部署於ecs,則使用者需要登入ecs控制台,篩選找到服務執行個體部署的ECS,手動給該ECS的雲端硬碟打快照;而恢複則需要使用者自行尋找自己做備份用的雲端硬碟快照,並在ECS控制台做資料復原。很顯然,當需要備份的雲端硬碟或RDS執行個體較多時,會因操作非常繁瑣而不便於使用者使用。而且,恢複時,使用者需要自行記錄哪個名稱的雲端硬碟快照或RDS執行個體的備份是自己需要的,比較容易出現錯誤。為解決這個問題,計算巢上線了備份管理功能,以實現在計算巢控制台,一鍵為服務執行個體的雲資源資料做備份或恢複。
實現原理
計算巢的備份與恢複功能,主要依賴底層雲資源的備份與恢複能力。因此,計算巢是否支援某個雲產品的備份與恢複,一方面取決於計算巢是否針對該雲產品開發了相關功能,另一方面也取決於該雲產品是否支援對自己的資料最備份與恢複。當前計算巢支援備份和恢複的雲產品有:
備份
在資料備份前,計算巢會產生一個空的備份記錄。該記錄會儲存備份開始時間、備份結束時間、備份狀態以及本次備份涉及到的各雲產品的執行個體ID及其備份狀態。
在做資料備份時,計算巢會根據服務執行個體ID,利用雲資源上的tag標籤篩選出隸屬於該服務執行個體的所有雲資源,並篩選出其中的Block Storage(雲端硬碟)與前文所述類型引擎的RDS執行個體。而後會逐個調用各雲產品的api以實現資料的備份。調用api成功後,計算巢會迴圈掃描各雲產品的備份結果。當備份狀態為終態時(成功or失敗)會記錄下結果並展示給使用者。一般情況下,一次計算巢的備份會涉及到多個雲產品的多個執行個體。只要還有一個執行個體處於“備份中”,計算巢的備份記錄就會處於“備份中”。當所有雲產品的所有執行個體都完成備份後,只要有任意雲產品的任意執行個體備份失敗,計算巢的備份記錄會被標記為“備份失敗”;只有所有雲產品的所有執行個體都備份成功,計算巢的備份記錄才會被標記為“備份成功”。
恢複
與備份類似,在恢複前,計算巢會產生一個空的恢複記錄。該記錄會儲存恢複開始時間、恢複結束時間、恢複基於的備份的ID、整體恢複狀態以及本次恢複涉及到的各雲產品資源id及其恢複狀態。
由於雲端硬碟在做資料恢複時,必須保證其掛載的ECS執行個體是停機狀態。因此,在恢複前,計算巢會將服務執行個體整體關機。關機完成後,會查詢恢複基於的備份資料ID,逐個調用各雲產品的api做資料恢複。api調用成功後,計算巢會迴圈掃描各雲產品的恢複結果。當恢複狀態為終態時(成功or失敗)會在恢複記錄中記錄下結果並展示給使用者。一般情況下,一次計算巢的恢複會涉及到多個雲產品的多個執行個體。只要還有一個執行個體處於“恢複中”,計算巢的恢複記錄就會處於“恢複中”。當所有雲產品的所有執行個體都完成恢複後,只要有任意雲產品的任意執行個體恢複失敗,計算巢的恢複記錄會被標記為“恢複失敗”;只有所有雲產品的所有執行個體都恢複成功,計算巢的恢複記錄才會被標記為“恢複成功”。當恢複完成後,計算巢會再次將服務執行個體開機。需要特別指出的是,由於恢複機制原因,MySQL引擎或PostgreSQL引擎的RDS執行個體在恢複過程中庫表會被重新命名,進而引起原庫或原表找不到。為瞭解決這個問題,在遇到上述兩個引擎的RDS執行個體恢複時,計算巢會利用FC函數向RDS執行個體執行庫表重新命名的SQL,將庫名或表名重新命名為原值。因此,如果您的服務執行個體中包含MySQL引擎或PostgreSQL引擎的RDS執行個體,在恢複過程中可能產生FC的費用。
費用
計算巢備份功能本身不會產生費用。由於計算巢備份功能是依賴各雲產品的備份能力,因此費用的產生主要是各雲產品備份所產生的。主要有以下三部分:
使用方式
如果您的服務需要開啟備份與恢複功能,您需要做兩步操作:
在服務營運(選填)欄目下,添加營運操作,基礎營運項。

開啟備份與恢複按鈕。
至此,備份與恢複已經開啟,該服務的服務執行個體可進行備份與恢複。