本文介紹了冷數據歸檔備份與恢復的技術原理、費用和設置方法。
數據是企業的核心資產。隨著業務發展，企業數據呈現出規模化、爆炸式的增長，業務應用要求實時、在線的快速處理。對于數據庫運維人員來說，保護企業核心數據的任務越來越具有挑戰性，例如數據誤刪除、相關系統漏洞和勒索病毒、硬件故障，甚至自然災害都可能造成數據的丟失。因此，備份和恢復是數據庫非常重要的功能。
PolarDB-X對InnoDB數據支持數據備份和日志備份，在備份方式上支持了自動備份和手動備份，恢復方式上支持按時間點恢復和按備份集恢復等恢復策略。而歸檔到OSS的冷數據和InnoDB熱數據，都是用戶的實例數據，所以無論數據以什么形式存在，整個數據庫實例都應該被視為一個整體來做備份恢復方案，為此我們對歸檔OSS的冷數據設計了一套完整的備份與恢復方案。
技術原理
針對于包含冷數據的實例，PolarDB-X同樣提供不同粒度的數據恢復能力，包括實例級的一致性備份恢復能力、表級的表回收站能力、SQL級的SQL閃回能力等。
冷數據的Flashback Query
每個存儲引擎指定為OSS的表分為元數據部分和數據文件部分。其中元數據存儲在PolarDB-X的GMS元數據節點中，數據文件存儲在OSS中，存儲于OSS的數據文件格式為開源ORC格式。每一個OSS數據文件在對應的GMS元數據記錄中都會包含兩個時間戳字段commit_ts與remove_ts，用于版本控制，與MVCC多版本含義一致。
Flashback Query指的是用戶可以針對SQL中的每張表指定一個時間點，查詢相應時間點數據的Snapshot。
如上圖所示，查詢的當前時間now，對應的 read_ts > (F1.remove_ts or F2.remove_ts)，所以F1、F2數據不可見，而對應的F3文件，只有commit_ts沒有remove_ts 且 read_ts > F3.commit_ts，所以F3數據可見。基于這個能力，我們提供了類似以下的SQL語法AS OF TIMESTAMP '指定時間'，指定時間做快照查詢。
SELECT XX FROM oss_orders where userId = 100
AS OF TIMESTAMP '2022-07-05 11:11:11'除此之外我們還提供了Alter FileStorage OSS As Of Timestamp '恢復指定時間' 指令，該指令可以把冷數據文件按時間戳裁剪至所需要的時間點。
備份集備份與恢復
實例級備份恢復將DN InnoDB存儲引擎的數據和OSS的冷數據視為一個整體，進行統一的恢復，需要支持指定的恢復時間點將原實例恢復到一個目標實例中。考慮到OSS冷數據的存儲規模會比較大，采用和在線庫一樣高頻的備份恢復策略，會帶來比較大的備份存儲成本，因此在實例級備份恢復任務的設計上，我們把InnoDB和OSS拆分成了相對獨立的備份恢復邏輯。這樣既可以一次性備份組合，也可以兩者分離各自備份，提供了比較好的靈活性，但兩者的備份恢復都需要一些設計約定：
支持定時或者手工觸發全量備份的接口，允許實例級備份流程進行全局觸發。其中InnoDB的備份恢復流程，在設計上也是把全量數據和增量數據拆分成了兩個相對獨立的邏輯，具體可參見PolarDB-X 是如何拯救誤刪數據的你：備份恢復。
支持任意時間點的恢復接口，在實例級恢復流程中會先調用在線數據InnoDB的時間點恢復機制，先確保對應的GMS、DN正常恢復，之后基于GMS的元數據信息，進一步恢復OSS上存儲的冷數據。
在這個備份恢復的設計前提下，基于OSS的備份恢復流程如下：
OSS數據備份流程：
固定周期全量備份OSS數據文件。
管控需要先對CN發起
Alter FileStorage OSS Backup指令，將GMS中維護的OSS數據文件元數據（主要包括數據文件名及對應的時間戳版本信息）持久化到OSS，文件名為files_meta.txt。管控讀取OSS中的files_meta.txt文件獲取所有文件元數據。
管控將數據文件逐個拷貝到備份OSS Bucket進行備份。
OSS Schema元數據存儲在GMS中，因此元數據的備份邏輯可以遵循MySQL基于Binlog的備份恢復流程。
內核固定周期Purge過期的老版本數據（Alter FileStorage OSS Purge Before Timestamp），保證每次備份數據集大小不會一直增大（需要保證Purge周期 > 備份周期）。
OSS數據恢復流程：
依賴InnoDB在線數據備份恢復，恢復出一個新的PolarDB-X實例，將GMS + DN找到最近全量備份+binlog增量恢復到指定時間點，此時對應時間點的OSS元數據會隨著GMS恢復到指定時間點。
選擇OSS數據備份集：判斷歷史周期備份集中是否存在距離恢復時間最近且備份時間大于恢復時間的備份集，如果存在則選擇；如果不存在滿足條件的歷史備份集，說明恢復時間距離當前時間較近，直接選擇當前原實例OSS下的全部數據文件，并通過
Alter FileStorage OSS Backup指令將GMS中維護的元數據文件推送至OSS。恢復任務將以上步驟中選取的OSS數據備份集拷貝一份到新實例，并更新新實例對應的OSS Bucket連接方式。
新實例上CN上執行
Alter FileStorage OSS As Of Timestamp '恢復指定時間'，將OSS數據文件按時間戳裁剪至所需要的時間點。
冷數據元數據維護的最小粒度是文件級，無法像熱數據那樣按照行去維護，所以兩者之間會有一定的差異：
類型 | InnoDB在線熱數據 | OSS歷史冷數據 |
備份數據 | 全量+binlog增量 | 元數據復用InnoDB備份能力 + 數據文件全量拷貝 |
恢復數據 | 全量+增量Apply | 元數據復用InnoDB恢復能力 + 數據文件按時間戳裁剪 |
備份周期 | 天級別或周級別 | 周或者月級別 |
如上圖所示，InnoDB和OSS備份恢復的一個顯著區別是：InnoDB會找到最近小于恢復時間點的全量備份集，再應用增量來恢復到指定時間點；而OSS則是找到最近大于恢復時間點的備份集，利用數據集內置增量數據，再應用裁剪機制來恢復到指定的時間點。
費用
OSS數據備份暫時無需單獨計費，當前可免費使用。
備份策略配置
在頁面左上角選擇目標實例所在地域。
在實例列表頁面，單擊PolarDB-X 2.0頁簽。找到目標實例，單擊實例ID。
在左側導航欄中，單擊。
在歸檔數據詳情頁的數據歸檔備份區域，單擊設置。
在數據歸檔備份設置對話框中，設置如下參數：
數據歸檔備份：開關默認為打開，不可關閉。
備份執行間隔：設置間隔多少天進行一次備份，取值范圍為1～59天。
備份保留策略：可選擇備份數據在指定時間內保留或永久保留。
備份保留時間：選擇備份的保留時間，范圍為30～730天。
單擊確定。