如何備份你的 App 資料庫（並確實還原）

要備份你的 App 資料庫，請依排程把資料庫匯出成檔案（Postgres 的標準工具是 pg_dump），把副本存放在與資料庫分開的地方，並定期把其中一份還原到空的資料庫，確認它真的可以用。在進行有風險的變更前，多做一次額外備份。你的程式碼備份（無論是 GitHub 儲存庫還是匯出檔）並不包含你的資料。

本指南適用於經營小型 App、希望不再擔心資料遺失的人。範例使用 Postgres，因為大多數 AI 建置的 App 都用它，但這些原則適用於任何資料庫。

備份必須涵蓋什麼

App 不只是資料庫。請清楚知道每一份備份保護的是哪一部分。

資料是無法重新建立的部分。程式碼可以重寫，設定可以重新輸入，但你客戶的訂單無法重來。

步驟 1：決定你能承受多少損失

有兩個問題會決定你的備份計畫：

• 你能承受損失多少近期資料？ 如果每天備份一次，而資料庫在傍晚故障，你就會損失當天的變更。對個人小專案來說沒關係；但如果是接受訂單的 App，可能就不行。
• 還原期間 App 能停機多久？ 小型資料庫幾分鐘就能還原，大型的可能久得多。你需要在真正用到之前就先知道這點。

對大多數小型 App 而言，每日自動備份加上有風險變更前的手動備份，是合理的起點。涉及金錢或健康資料的 App，應該更頻繁地備份，或使用支援時間點還原（能還原到任一時刻，而不只是上一次備份）的代管資料庫。

步驟 2：確認你的主機已經提供什麼

許多代管資料庫服務商會自動備份。請確認：

• 你的方案是否有開啟備份？多久執行一次？
• 備份保留多久？
• 能還原到某個時間點，還是只能還原到每日快照？
• 你能下載備份檔，還是只能在他們的系統內還原？

服務商的備份很有用，但它和你的資料庫共用同一個單一故障點：帳號。如果帳號被關閉、停用，或專案被刪除，備份也可能一起消失。這就是為什麼你還需要自己的一份副本。

步驟 3：用 pg_dump 製作傾印檔

pg_dump 會把 Postgres 資料庫匯出成檔案。它讀取的是一致性快照，所以工具運作時 App 仍可繼續執行。

一個典型的指令，使用你的 App 已經放在環境變數中的連線字串：

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

各選項的作用：

• --format=custom 會寫出 pg_restore 能讀取的壓縮檔，並讓你之後能只還原單一資料表。如果你想要可讀的 .sql 檔，請改用 --format=plain。
• --no-owner 會省略擁有者相關的指令，讓還原到不同資料庫時更簡單。
• 檔名中的日期可以把不同時間的備份區分開來。

pg_dump 的版本應該與你的資料庫 Postgres 版本相同或更新。舊版的 pg_dump 可能會拒絕執行。

如果你是用 AI 建置，又不想碰命令列，可以這樣請它：

請用 pg_dump 的 custom 格式備份 App 的資料庫，檔名要包含今天的日期。請不要印出連線字串或任何祕密資訊。完成後請告訴我檔名與檔案大小。

步驟 4：自動化

手動備份很容易被忘記。請依你的設定，用可行的方式自動化：

• 你的資料庫服務商提供的排程備份（如果有的話）。
• 排程工作：在伺服器或 CI 服務上執行 pg_dump，並把檔案上傳到儲存空間。
• 代管備份服務：連接到你的資料庫。

不管選哪一種，都要讓它在備份失敗時通知你。備份工作悄悄失敗了三個月，是最經典的恐怖故事。

步驟 5：把副本存到別處

常被稱為 3-2-1 原則：三份資料副本、兩種不同類型的儲存媒體，其中一份存放在異地。對小型 App 來說，實用的版本是：

• 正式運作的資料庫
• 服務商自己的自動備份
• 你自己的傾印檔，存放在另一個帳號的獨立儲存空間，例如不同帳號下的物件儲存儲存桶

另外：

• 限制存取。 備份包含每一位使用者的資料，請把它當成正式資料庫來保護。
• 訂定保留政策。 例如每日備份保留兩週、每月備份保留一年。舊的備份要刻意刪除，並記得隱私法規可能要求你在當事人要求時刪除個人資料。
• 絕不把備份提交到 Git。 儲存庫裡的傾印檔是一場等待發生的資料外洩。

步驟 6：測試還原

備份的價值取決於你上一次成功還原的時間。至少每幾個月一次，以及每次更動備份流程之後，都應該測試：

1. 建立一個新的空資料庫。測試時絕對不要還原到正式運作的資料庫上。
2. 把最新的備份還原進去：

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

如果是純 .sql 檔，請改用 psql "$TEST_DATABASE_URL" -f backup.sql。

1. 確認每個資料表都存在，比對正式資料庫的資料列數，並檢視幾筆最近的紀錄。
2. 如果可以，讓 App 的副本連到這個資料庫，並嘗試登入。
3. 記下還原花了多久時間。那才是你真正的復原時間。

步驟 7：有風險的變更前先備份

在下列操作之前，請先做一次新的備份：

• 執行會刪除或重新命名欄位的資料庫遷移
• 大量匯入資料
• 讓 AI 代理對資料模型做大幅變更
• 刪除舊的紀錄

在 AI 建置的 App 裡，代理可能會在開發功能的過程中改變資料表結構。檢查點與版本控制可以還原程式碼，但無法復原已刪除的資料列。大變更前花三十秒做備份，是很便宜的保險。

常見錯誤

• 以為 Git 或程式碼匯出就是備份。 它們有程式碼，但沒有資料。
• 從來不測試還原。 許多備份在真正需要時才發現是空的、不完整或無法讀取。
• 把備份和資料庫放在同一個帳號。 一個帳號遭入侵或被關閉，兩者會同時遺失。
• 忘了上傳的檔案。 資料庫只存檔案的路徑，圖片本身存在儲存空間裡。
• 把祕密資訊留在備份腳本中。 連線字串應從環境變數讀取，絕不寫在腳本內容裡。請參閱如何安全保管 API 金鑰。

備份與 Mythex

Mythex 專案可以擁有專屬的 Postgres 資料庫，其連線資訊會注入到工作區與已發佈的 App 中。Mythex 文件並未描述資料庫備份或還原功能，因此請自行規劃：請代理製作傾印檔、下載並妥善保管，尤其是在大變更之前。專案匯出（Pro）包含你的程式碼，但會排除祕密資訊與 node_modules，不包含資料庫中的資料列。詳情請見文件中的資料庫與資料所有權。想進一步了解資料庫本身，請閱讀什麼是 Postgres。

備份檢查清單

• 已決定能承受多少資料損失，以及能停機多久
• 已確認資料庫主機提供哪些自動備份
• 你自己的傾印檔依排程執行，失敗時會通知你
• 副本與資料庫分開存放，並限制存取
• 已寫下保留政策
• 資料庫與上傳的檔案都已備份
• 已在空的資料庫中測試還原，並核對資料列數
• 每次有風險的變更前都已備份

常見問題