kingbase備份與復原實戰（七）—— 復原演練與驗收：從「能恢復」到「可交付預案」
引言
備份這件事，就算你平時做得再勤快，要是不去做「演練和驗收」的話，很多時候往往僅僅只是個心理安慰罷了：
你以為你能恢復。那咱們做維運交付，真正能拿得出手的東西，到底應該是什麼呢？其實應該是一套能複製、能落地的閉環：
- 事故發生之後，怎麼去判斷到底要用什麼恢復策略
- 恢復操作具體該怎麼執行（也就是誰來做、大概要花多久）
- 恢復完了之後怎麼去驗收（什麼叫「恢復成功」得定清楚）
要是失敗了的話該怎麼回滾或者重新來過（這些在預案裡面得寫得清清楚楚），這篇文章是《備份與復原實戰》系列的最後一篇，那麼我會直接給大家拿出一套「拿來就能用」的模板：包含演練劇本、驗收清單、處置流程圖還有常見問題排查，你可以把它當成演練腳本來用，或者說當成維運交付的架構支撐也是沒問題的。 
@[toc]
一、演練目標與邊界（先把「恢復到哪裡」說清楚）
做演練的時候，最怕的就是有兩件事沒說清楚：
- 目標沒弄清：到底要恢復到哪個時間點？又要恢復到哪個資料庫裡去？
- 邊界沒弄清：在恢復的過程裡，允不允許覆蓋原來的資料庫？能不能停機？
所以這部分，我就直接給出一個標準模板了（大家可以直接複製過去填空）：
項目值（示例）演練對象backup_lab演練方式恢復到新資料庫 backup_lab_drill事故類型誤刪表（DROP TABLE backup_demo.t_order）恢復策略歸檔格式邏輯備份 + sys_restore 精準恢復目標指標RPO ≤ 24h，RTO ≤ 30min（示例）驗收標準物件齊全、列數一致、關鍵彙總一致回滾策略演練在新資料庫，不影響原庫；失敗可重做#### 1.1 角色分工（把「誰來做」寫清楚，預案才可交付）
角色主要職責交付物DBA/資料庫維運執行恢復、分析日誌、給出恢復點建議恢復操作記錄、恢復耗時、問題清單系統維運服務啟停、目錄權限、磁碟空間、排程系統側日誌、磁碟/權限確認業務方/測試業務驗收、關鍵報表/介面驗證驗收結果、異常描述、簽字確認### 二、演練流程圖
三、案例腳本清單
那麼為了讓演練可以重複去做，還能重用，通常來說建議把「造資料—製造事故—驗收」這一套拆成腳本清單：
01_prepare_env.sql- 去建立示範資料庫、模式還有資料表
- 往裡面塞一點示範資料
02_business_increment.sql- 備份完之後新增的資料（這是用來驗證「精準恢復不會覆蓋其他表」的情況）
03_incident_drop_table.sql- 模擬一個事故：
DROP TABLE backup_demo.t_order;
- 模擬一個事故：
04_acceptance_check.sql- 驗收用的 SQL：查查物件清單、列數，還有關鍵的彙總資料
05_cleanup.sql- 把演練資料庫
backup_lab_drill清理掉（這樣下次演練的時候還能接著用）
- 把演練資料庫
四、演練記錄表（讓 RTO/RPO 可量化、可回顧）
演練做完以後，你「憑感覺說恢復用了 20 分鐘」，這其實沒什麼說服力。那更可靠一點的做法是什麼呢？也就是說，我們得邊演練邊做記錄。
時間點動作負責人證據（日誌/截圖）備註T0確認事故與恢復目標T1確認備份檔與可讀性sys_restore -l 輸出T2建立演練資料庫（隔離）SQL 執行記錄T3執行恢復恢復日誌檔T4執行驗收 SQL查詢結果截圖/日誌T5業務驗收通過業務簽字/記錄T6輸出演練報告與改進項報告文件### 四、演練劇本（按時間線寫，照做即可）
4.1 T0：演練前準備（5~10 分鐘）
1）先確認備份檔是不是存在，而且大小合不合理（看個示例）：
D:\KB_LAB\backup\logical\YYYYMMDD_HHMM_backup_lab_full.dump
2）接著要先「列出歸檔內容」，確認一下這個備份集中，是不是真的包含了你要的目標物件：
cmd 體驗AI代碼助手 代碼解讀複製代碼cd /d D:\Tools\Kingbase\ES\Server\bin
sys_restore -l D:\KB_LAB\backup\logical\<dump>.dump > D:\KB_LAB\logs\<dump>.list.txt3）準備一下演練的目標資料庫（建立一個新資料庫隔離開來）：
cmd 體驗AI代碼助手 代碼解讀複製代碼cd /d D:\Tools\Kingbase\ES\Server\bin
ksql -U system -d kingbase -h 127.0.0.1 -p 54321sql 體驗AI代碼助手 代碼解讀複製代碼DROP DATABASE IF EXISTS backup_lab_drill;
CREATE DATABASE backup_lab_drill WITH TEMPLATE = template0 ENCODING = 'UTF8';4）把「演練的目標指標」（也就是 RPO/RTO）先定下來，並且記到本子上：
- RPO：這次允許遺失的資料窗口有多大（例如 ≤ 24h）
- RTO：這次允許的恢復耗時是多久（例如 ≤ 30min）
RPO/RTO 這兩個東西可不是喊喊口號就行的，它們得能被「備份頻率 + 實際恢復耗時 + 驗收結果」給撐得住才行。
4.2 T1：恢復到新資料庫（10~30 分鐘，視資料量）
接著用 sys_restore 把備份恢復到演練資料庫裡去：
cmd 體驗AI代碼助手 代碼解讀複製代碼sys_restore -h 127.0.0.1 -p 54321 -U system -d backup_lab_drill D:\KB_LAB\backup\logical\<dump>.dump4.3 T2：製造事故（演練用）
連上演練資料庫，然後我們去製造一個「誤刪表」的事故出來：
cmd 體驗AI代碼助手 代碼解讀複製代碼ksql -U system -d backup_lab_drill -h 127.0.0.1 -p 54321sql 體驗AI代碼助手 代碼解讀複製代碼DROP TABLE backup_demo.t_order;
\dt backup_demo.*4.4 T3：執行應急恢復（精準恢復）
從同一份備份集中，我們僅僅只恢復 t_order 這張表：
cmd 體驗AI代碼助手 代碼解讀複製代碼sys_restore -h 127.0.0.1 -p 54321 -U system -d backup_lab_drill -t backup_demo.t_order D:\KB_LAB\backup\logical\<dump>.dump4.5 T4：恢復後驗收（必須做）
在 ksql 裡面執行下面的驗收項（這是個示例）：
sql 體驗AI代碼助手 代碼解讀複製代碼\dt backup_demo.*
SELECT COUNT(*) AS account_cnt FROM backup_demo.t_account;
SELECT COUNT(*) AS order_cnt FROM backup_demo.t_order;
SELECT SUM(balance) AS total_balance FROM backup_demo.t_account;如果你想讓驗收變得更「維運化」一點的話，我通常來說建議把驗收拆成三層來做：
- 層 1：物件層（看看 schema/table/index 這些是不是都齊了）
- 層 2：資料層（查查列數、關鍵彙總資料一不一致）
- 層 3：業務層（跑跑關鍵查詢和關鍵報表，看還能不能用）
4.6 T5：形成「可交付預案」（演練產出不只一份庫）
那應該有什麼呢？其實是這些：
1）一份恢復操作的記錄（裡面有命令、路徑、耗時還有日誌）
2）一份驗收記錄（包含 SQL 結果、業務校驗、通過標準這些）
3）一份改進清單（比如自動化、監控、保留策略、權限規範這些東西）
五、驗收清單
驗收項驗收方法通過標準備份集可讀sys_restore -l能列出物件清單，無報錯目標資料庫可連線ksql -d backup_lab_drill連線成功資料表物件存在\dt backup_demo.*目標表存在列數一致COUNT(*)列數與預期一致關鍵彙總一致SUM/COUNT彙總結果一致恢復過程可追溯日誌檔/排程記錄有開始/結束時間與結果### 六、驗收的「高頻漏項」
很多時候恢復失敗，往往不只是因為「表沒回來」，而是「表雖然回來了，但是用起來感覺不對勁」。這裡就有 4 個常見的漏項：
1）索引還在不在（這會影響效能還有業務體驗）
2）約束或者外鍵還在不在（這會影響資料一致性）
3）序列對不對（這會影響自增主鍵寫入）
4）權限對不對（這會影響應用帳號去存取）
對應的最小檢查動作（看個示例）：
sql 體驗AI代碼助手 代碼解讀複製代碼\di+ backup_demo.*
\d backup_demo.t_order六、常見失敗場景與處理建議
失敗 1：恢復時報權限不足
處理建議：
- 統一用管理員使用者去執行恢復操作（例如用
system） - 或者提前在目標資料庫裡，把需要的權限和擁有者準備好
失敗 2：只恢復單表後外鍵/依賴報錯
處理建議：
- 先把依賴鏈上游的物件恢復了（像父表、型別、函數這些）
- 或者乾脆升級一下，做個「按 schema 恢復」，別只恢復單表了
失敗 3：備份存在但不可用（檔案損壞/格式不相符）
處理建議：
- 日常做完備份之後，順手跑個
sys_restore -l，做個快速的可讀性檢查 - 每週最好做一次恢復演練，免得等真的出事了，才發現「備份根本不能用」
失敗 4：PITR 找不到 WAL 段（歸檔缺失）
處理建議：
- 把歸檔目錄納入監控：盯好容量、檔案成長還有失敗次數
- 明確「歸檔保留週期」，這個週期必須得把「基線備份到目標時間點」這段時間覆蓋住才行
七、演練報告模板
- 演練時間：YYYY-MM-DD HH:MM
- 演練人員：xxx
- 演練對象：backup_lab
- 事故類型：誤刪表
- 恢復策略：邏輯備份+ sys_restore 精準恢復（或者做 PITR）
- RPO/RTO 目標：RPO=xx，RTO=xx
- 實際恢復耗時：xx 分鐘
- 驗收結果：通過/不通過
- 問題與改進：
- 備份耗時還得優化
- 恢復腳本得固化下來
- 歸檔目錄得加上監控
八、把演練變成制度
- 每週做一次小演練：恢復到新資料庫，再跑跑驗收 SQL（花的時間短，但是收益大）
- 每季做一次大演練：裡面得包含應急溝通、切換還有業務驗收簽字
- 每次演練必須得產出一些改進項，而且要在下次演練之前把它們關掉（這樣才能形成閉環）
總結
寫到這一篇的時候，其實你已經把「備份復原」從單純的操作層面，提升成「可交付能力」了：
- 有策略（RPO/RTO 的目標很清楚）
- 有流程（有那種可視化的處置路徑）
- 有演練（去恢復到新資料庫，做隔離驗證）
- 有驗收（有可以量化的通過標準）
回顧的時候也把問題的自動化還有監測部分包含進去了。這樣的話，《備份與復原實戰》這個系列的 7 篇文章，也就算是完成了一個大循環了。我們聊的東西，涉及到了入門級的邏輯備份、精確復原、物理備份、PITR、自動化，還有操作演練驗證這些方面。這幾乎就是維運場景裡面最常被用到，也是非常重要的一套能力集合了。要是大家還有什麼別的問題，其實可以在我這裡留言，或者私訊我也行。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
