只還原一張表就好：單表恢復看起來省事，但撈回來的東西未必完整

（本文事件脈絡取自 2026 年 9 月 20 日發布的技術實作文章，屬資料庫維運的常態議題，近日因企業級備份恢復討論再受關注，以回顧角度整理。）

配置表被人改亂了、一張臨時表被誤清了、想單獨撈某張表的資料去比對。這類事故有個共同點：出事的範圍只有一張表。為了一張表把整個資料庫還原一遍，等於為了找一支鑰匙把整棟房子拆了重蓋。麻煩、耗時，而且還原過程會把其他正常運作的表也一起覆蓋掉，反而製造第二次事故。

這正是 custom 格式備份搭配 sys_restore 的 -t 參數存在的理由：備份的時候整庫全備，恢復的時候按需挑物件出來。這篇把單表恢復的流程走一遍，但重點放在一個容易被略過的問題上：恢復出來的東西，到底完不完整。

先確認工具認得這個參數

sys_restore 的說明文件裡，-t 參數的描述是「restore named relation」，也就是還原指定名稱的關聯物件。這裡的措辭值得多看一眼：它挑的是「叫這個名字的那個物件本身」。

打個比方，這就像去倉庫領貨。你說要領「t_config 這箱貨」，系統就把貼著這個標籤的箱子搬給你。但箱子裡面裝了什麼、有沒有少東西，系統不會替你檢查。文件裡也註明 -t 可以和 -n（schema 名稱）等選項組合使用，這在多 schema 環境下是必要的安全網。

現場：一個庫裡三張表

示範環境是一個資料庫，底下三張表：t_customer、t_order 是對照組，t_config 是這次要單獨恢復的目標。選 t_config 是因為它沒有外鍵，看起來最乾淨。

先記住這個「乾淨」，後面會發現它沒那麼乾淨。

三張表都有資料：t_customer 兩行、t_order 兩行、t_config 三行。接著做一份普通的整庫 custom 備份。custom 格式的價值就在這裡：一份歸檔，恢復時按需取用，而不是備的時候就得決定要備哪些部分。

恢復前，先看歸檔的清單

恢復之前，先把歸檔的目錄列出來，確認目標表在裡面，順便看看它「帶了些什麼」。用 sys_restore -l 把清單輸出成檔案，再 grep 目標表名稱。

這一步撈出來的結果，是整個流程裡最值得注意的細節：t_config 在歸檔裡並非一個整體，而是拆成三條獨立條目。

第一條是 TABLE，表的定義。第二條是 TABLE DATA，表的資料。第三條是 CONSTRAINT，主鍵 t_config_pkey。

換句話說，平時在資料庫裡看起來渾然一體的一張表，在備份歸檔裡其實是被拆開存放的三個獨立物件。它的主鍵約束是一條單獨的記錄，跟表結構和表資料分開列。這意味著 -t 參數去挑「叫這個名字的關聯物件」時，實際上會同時觸及這幾條相關條目，但不同物件之間的對應關係，取決於工具如何處理這些目錄項，而非使用者直覺中的「一張表就是一個東西」。

用另一個比喻：你以為備份裡存的是一整組家具，實際上倉庫的登記簿把桌面、桌腳、抽屜分別建了檔。領貨時能不能一次領齊，要看登記簿上這幾筆有沒有被正確關聯起來。

對照組也要看

同一份清單裡，t_customer 和 t_order 也各自列出。對照組的意義在於：恢復完 t_config 之後，回頭檢查另外兩張表有沒有被波及。單表恢復的承諾是「只動這一張」，驗證的方式就是看其他表是否原封不動。

這也是實務上最容易被跳過的一步。恢復指令跑完、目標表的資料回來了，很多人到此為止。但一份整庫歸檔被部分恢復時，任何超出預期的副作用，只有靠對照才能發現。

撈回來的東西，要回頭查

這篇實作的核心結論可以收斂成一句話：單表恢復能把表和資料撈回來，可它沒有想像中那麼聽話，恢復完最好回頭查一眼。

要查的項目很具體。表的定義在不在，資料行數對不對得上，主鍵約束有沒有跟著回來。如果表上有索引、觸發器、序列（serial 欄位背後的 sequence），這些在歸檔清單裡同樣可能是獨立條目，每一項都值得在恢復後逐一確認。示範裡刻意選了「沒有外鍵、看起來乾淨」的表，結果連它的主鍵都是一條單獨記錄，那麼真實環境裡那些有外鍵、有觸發器的表，拆解只會更細。

這對日常維運的直接啟示是：備份清單不只是恢復前的確認工具，更是恢復後的驗收清單。恢復前 grep 出目標表相關的所有條目，恢復後照著這份條目逐一核對，比憑感覺判斷「應該沒問題」可靠得多。

什麼時候該用單表恢復

回到開頭的情境。單表恢復適用的場景，是事故範圍明確限定在一張表、且這張表的相依物件（外鍵指向的其他表、共用序列）不會被恢復動作影響的時候。t_config 這類配置表之所以常被拿來示範，正是因為它相對獨立。

一旦表之間有外鍵牽連，單獨還原一張表可能讓參照完整性出現缺口，這時要嘛連相依物件一起挑出來恢復，要嘛退回整庫還原到獨立環境再抽取資料。工具提供了按需取用的能力，但「哪些東西必須一起取用」的判斷，仍然落在維運的人身上。

對大多數團隊來說，這篇流程最值得帶走的並非指令本身，而是一個習慣：把備份歸檔的清單當成文件來讀。哪張表有哪些附屬物件、哪些約束是獨立條目，這些資訊在出事當下才去查已經太晚，平時備份完順手看一眼清單，事故時的判斷速度會完全不同。