題幹與適用場景
一個大型 PostgreSQL 叢集希望減少全量備份的窗口和儲存成本。請設計基於增量 base backup 的備份鏈，說明 pgbasebackup、WAL 依賴、backup manifest、pgcombinebackup、校驗、保留策略與恢復演練。
PostgreSQL 文件指出，增量備份不能直接用於恢復，必須與其依賴的舊備份合成 synthetic full；工具會檢查鏈條關係，但不會替你追蹤依賴，也不會證明每個備份內容完整。面試重點是恢復可證明性，不是只會執行一條備份命令。
面試官考察點
面試官會看你能否區分 full、incremental、WAL 與 manifest；能否解釋 reference backup、依賴鏈與合成全量；能否設計 pg_verifybackup、checksum、物件儲存不可變版本與完整性檢查；能否處理鏈斷裂、備份來自 standby、複製槽/WAL 保留、加密與恢復時間目標；能否用演練證明 RPO/RTO。
回答前需要釐清的問題
恢復目標
確認 RPO、RTO、目標時間點、是否需要跨區域恢復、是否允許恢復到較低 PostgreSQL 版本，以及資料庫是否包含多個 tablespace。
備份工作負載
確認全量大小、每日變更量、WAL 速率、備份窗口、網路頻寬、物件儲存生命週期與並發備份限制。
一致性與合規
確認備份加密與金鑰輪換、不可變保留、刪除權限、manifest 校驗演算法、審計記錄與恢復演練頻率。
30 秒回答框架
「我會以一份可驗證的 full backup 作為鏈起點，按變更量生成 incremental，並保存每份 backup manifest、依賴關係和連續 WAL。增量不能直接恢復，恢復前按時間順序用 pgcombinebackup 生成 synthetic full，再套用所需 WAL。物件儲存啟用不可變版本與加密，定期用 pgverifybackup 與抽樣恢復驗證內容；遺失任何依賴就讓排程器阻止清理相關備份。最後用真實大小和故障演練證明 RPO、RTO，而不是只看備份成功率。」
分步驟深入解答
第一步：建立備份鏈模型
記錄 full、每份 incremental 的 reference backup、LSN 時間範圍、manifest、加密金鑰版本與儲存 URI。鏈上的每個節點都指向前置依賴；刪除策略必須先計算仍可恢復的最早時間點。
第二步：產生增量備份
pg_basebackup 可用 reference manifest 請求增量，增量檔案只包含相對參考備份發生變化的區塊。備份仍針對整個叢集，而不是單一資料庫物件；複製連線需要 REPLICATION 權限或超級使用者，並配置足夠的 walsender。
full_0 = pg_basebackup(full)
inc_1 = pg_basebackup(incremental, reference=full_0.manifest)
inc_2 = pg_basebackup(incremental, reference=inc_1.manifest)第三步：保留連續 WAL
基備份期間產生的 WAL 必須可取得。使用 stream 方法會並行開啟第二個複製連線；使用 fetch 方法則需保證 walkeepsize 或歸檔在傳輸完成前不回收所需 WAL。複製槽能減少過早清理風險，但也可能造成磁碟增長，必須監控最舊 required LSN。
第四步：驗證 manifest 與鏈條
pgcombinebackup 只驗證輸入備份之間的合法關係，不驗證每個備份本身是否完整；每個節點應另用 pgverifybackup 與 manifest checksum 校驗。物件儲存上傳完成後再登記狀態，校驗失敗的節點不得進入可恢復鏈。
第五步：合成恢復輸入
恢復到某個時間點時，按 full 到目標 incremental 的順序呼叫 pg_combinebackup，輸出 synthetic full。它可以作為下一次合併的起點，但不能取代 WAL；隨後把從備份結束 LSN 到目標時間點的 WAL 放入恢復目錄並設定恢復目標。
第六步：處理鏈斷裂與保留
排程器維護依賴圖與最早可恢復時間。任意前置備份遺失、校驗失敗或金鑰不可用，就標記所有後繼節點不可恢復，禁止自動刪除前置節點。週期性建立新的 full 或 synthetic full，壓縮鏈長度與恢復時間。
第七步：演練 RPO/RTO
在隔離環境恢復隨機時間點，核對系統目錄、tablespace、WAL、擴充套件與應用一致性。記錄下載位元組、合併耗時、WAL 回放速率、恢復完成時間與資料校驗結果；模擬物件儲存 404、壞 manifest、金鑰撤銷與主庫故障。
高品質示範回答
我會把備份當成帶依賴的有向鏈：full 是根，incremental 指向 reference backup，WAL 補齊時間點。每個節點保存 manifest、checksum、LSN、金鑰版本與不可變物件 URI。恢復先用 pgcombinebackup 按順序生成 synthetic full，再回放連續 WAL；pgcombinebackup 的鏈關係檢查不能取代 pg_verifybackup 的內容檢查。保留策略透過依賴圖計算，恢復演練覆蓋鏈斷裂、WAL 缺失、金鑰撤銷與多 tablespace，並以實測 RPO/RTO 放行發布。
常見錯誤
- 錯誤表現： 把 incremental 當作可獨立啟動的目錄。→ 失敗原因： 它依賴 reference backup，不能直接恢復。→ 修正方法： 先合成 full，再套用 WAL。
- 錯誤表現： 只看 pg_combinebackup 返回成功。→ 失敗原因： 它不證明各備份內容完整。→ 修正方法： 對每個節點執行 manifest/checksum 驗證與抽樣恢復。
- 錯誤表現： 清理舊 full 只按時間判斷。→ 失敗原因： 後繼增量仍依賴它。→ 修正方法： 用依賴圖與最早可恢復時間決定保留。
- 錯誤表現： 備份成功卻沒有連續 WAL。→ 失敗原因： 目標時間點無法重播。→ 修正方法： 監控 required LSN、歸檔延遲與複製槽佔用。
追問及應對
full、synthetic full 和 incremental 有什麼區別？
full 是獨立的叢集檔案副本；incremental 只包含相對參考備份變化的區塊；synthetic full 是用鏈條重建出的可作為恢復輸入的目錄，但仍需要目標時間點之後的 WAL。
為什麼不能無限延長增量鏈？
鏈越長，下載、合併、校驗與失敗面越大，RTO 也會上升。按變更率、儲存成本與演練資料定期插入新的 full 或 synthetic full。
如何處理 manifest 遺失？
將節點標記為不可自動使用，不憑檔名猜依賴。若能從受信任副本恢復 manifest，先校驗檔案 checksum、LSN 和鏈關係，再重新登記。
如何驗證備份加密不會阻塞恢復？
在隔離環境定期用目前和歷史金鑰恢復樣本，驗證金鑰輪換、撤銷、權限與跨區域 KMS 可用性；金鑰不可用時應明確告警並阻止宣稱該時間點可恢復。