sys_dump 單庫備份的邊界：角色與權限不在備份檔裡，跨機還原才會半路報錯

2026年9月2日，掘金用戶「一隻牛博」發表一篇約四分鐘閱讀篇幅的技術長文，標題為「sys_dump 備了庫，角色和權限別漏在外面」。文章的核心命題只有一句話：sys_dump 只匯出單一資料庫內部的物件，角色與資料表空間這類實例層級的全域物件不在輸出範圍內。本臺依據該篇公開內容與其附帶的指令紀錄，整理這條備份邊界的具體樣貌、出錯位置與作者給出的處理順序。

備份檔沒壞，還原卻在 ALTER TABLE 那一行中斷

文章開頭先描述故障的長相。單庫備份檔案完整，校驗通過，搬到另一臺機器還原時，ksql 用戶端直接回報錯誤：

ERROR: role “bak_app_owner” does not exist

作者指出，這種情況下備份沒有損毀，資料也沒有遺失，問題出在備份的邊界定義。資料表的擁有者是某個角色，某些表的查詢權限授予了另一個角色，這些「引用關係」都如實寫進了單庫備份檔；但被引用的角色本身，不歸 sys_dump 管理。新機器上不存在這些角色，還原程序執行到 ALTER TABLE … OWNER TO 一句時就無法繼續。

換句話說，出錯的時間點不在備份當下，而在還原途中；出錯的原因不是資料損失，而是缺少被引用的外部物件。

最小實驗現場：兩個角色、一個庫、一張表

為了把這條邊界講清楚，作者搭建了一個最小化環境。現場包含兩個角色與一個資料庫：bak_app_owner 擔任資料庫與資料表的擁有者，bak_readonly_user 是只讀用戶；資料庫 global_demo_db 歸 bak_app_owner 所有，庫內 app schema 下有一張表同樣由它持有，該表的查詢權限另授予只讀用戶。作者註明，建角色與建庫屬於 DBA 的職責範圍，示範過程以 system 帳號連線。

查核現場的指令依序執行四項確認。第一項以 \du bak_* 列出符合前綴的角色；第二項查詢 database 目錄，確認 global_demo_db 的 db_owner 欄位經 catalog.get_userbyid 換算後指向 bak_app_owner；第三項查詢 tables 目錄，確認 app schema 下的資料表 tableowner 欄位同樣是該角色；第四項用 has_schema_privilege 與 has_table_privilege 兩個函式，分別驗證只讀用戶對 app schema 的 USAGE 權限與對 app.t_global_customer 表的 SELECT 權限，兩項回傳值皆為 t。

這個現場呈現的結構是：庫內物件掛在外部角色名下，權限也授予外部角色。作者對此的解釋是，角色屬於資料庫實例層級的東西，不隸屬於任何一個 database，這正是它會被單庫備份漏在外面的根本原因。

備份檔裡有引用、沒有 CREATE ROLE

接著作者以 sys_dump 將這個庫匯出，格式選擇純 SQL，方便事後以 grep 檢索。匯出指令指定主機 127.0.0.1、埠 54321、以 system 身分連入 global_demo_db，輸出寫入備份目錄下的 global_demo_db.sql。

檢索結果分兩部分。第一部分以 OWNER TO 與 GRANT 為關鍵字、疊加角色名稱過濾，備份檔中可以找到 ALTER SCHEMA app OWNER TO bak_app_owner 這類語句，對只讀用戶的授權語句同樣在檔內。第二部分反向檢索 CREATE ROLE，腳本邏輯設計為若在資料庫備份檔中發現該語句就回報異常，否則輸出確認訊息。實驗結果落在後者：整份單庫備份檔裡不存在任何 CREATE ROLE。

兩相對照，結論明確。引用角色的語句全部在檔內，建立角色的語句一句也沒有。備份檔本身自洽，但它隱含假設了目標環境已經存在這些角色。

還原順序：角色先行，資料庫在後

依據文章脈絡，正確的跨機遷移順序是先把角色等全域物件在新環境建好，再執行單庫備份的還原。若順序顛倒，就會重演開頭的報錯場景：還原程序走到指定擁有者的語句時，因為角色不存在而中止。

作者並未在文中給出角色備份的具體工具選擇，文章的重點放在把邊界本身界定清楚：單庫備份裡到底有沒有角色、角色該由誰負責備份、恢復時誰先誰後。這三個問題的答案分別是：有引用而無本體、角色屬於實例層級故不在 sys_dump 的單庫職責內、角色必須先於資料庫還原存在。

訊源狀態與可核實範圍

本則內容的單一訊源為掘金平臺上「一隻牛博」於2026年9月2日發布的技術文章，文內附有可重複執行的指令與預期輸出，屬於可自行驗證的實驗紀錄類內容。文章截至發文時顯示閱讀量為個位數，尚未有其他獨立訊源複現同一實驗。文中對 sys_dump 行為的描述，與其作為單庫匯出工具、全域物件需另行處理的一般性認知方向一致；具體指令輸出以原文實驗現場為準。

對照一般資料庫運維實務，這類「備份通過、還原失敗」的案例，常見根因多落在版本不相容、路徑差異或字元編碼設定；本案指向的是另一種更容易被忽略的類型，即備份範圍與物件歸屬層級的錯配。對採用單庫備份策略的團隊而言，可核實的檢查點有三個：備份檔是否含 CREATE ROLE、目標環境是否已建齊被引用的角色、還原腳本是否在資料庫載入前完成角色建立。三項都通過，才談得上備份與還原的完整對應。