如何備份應用程式資料庫（並確保真的能還原）

要備份應用程式資料庫，請按排程將資料庫匯出成檔案（以 Postgres 為例，標準工具是 pg_dump），將副本存放在與資料庫分開的地方，並定期把某個備份還原到空白資料庫，以證明備份真的可用。在任何高風險改動之前，額外做一次備份。程式碼備份（無論是 GitHub 儲存庫還是匯出檔）並不包含你的資料。

本指南適用於經營小型應用程式、希望不再擔心資料遺失的人。由於大部分 AI 製作的應用程式都使用 Postgres，範例以它為準，但這些原則適用於任何資料庫。

備份需要涵蓋什麼

應用程式不只是資料庫。你要清楚每份備份保護的是哪一部分。

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

第一步：決定你能承受失去多少資料

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

• 你能承受失去多少最近的資料？ 如果你每日備份一次，而資料庫在晚上故障，你就會失去當天的改動。對於個人小應用程式，這樣可以接受；但如果應用程式需要處理訂單，就未必可以。
• 還原期間，應用程式可以停止運作多久？ 小型資料庫幾分鐘便能還原，大型資料庫則可能需時更久。你需要在真正用到之前就知道這點。

對大部分小型應用程式來說，一個每日自動備份，加上高風險改動前的一次手動備份，是合理的起步方案。如果應用程式涉及金錢或健康資料，就應該更頻密地備份，或使用支援「時間點還原」（即可以還原到任何一刻，而不只是最近一次備份）的代管資料庫。

第二步：查看你的主機已經提供什麼

不少代管資料庫的服務供應商會自動備份。請確認：

• 你的方案是否已開啟備份，備份的頻率是多少？
• 備份會保留多久？
• 可以還原到某個時間點，還是只能還原到每日快照？
• 你可以下載備份，還是只能在他們的系統內還原？

服務供應商的備份很有用，但它與你的資料庫共用同一個單一故障點：也就是帳戶。如果帳戶被關閉、暫停，或專案被刪除，備份也可能一併消失。因此，你也需要自己保存一份副本。

第三步：使用 pg_dump 製作傾印檔

pg_dump 會把 Postgres 資料庫匯出成檔案。它會讀取一致的快照，所以應用程式可以在傾印期間繼續運作。

以下是一個典型指令，使用應用程式已在環境變數中設定的連線字串：

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 版本相同，或更新。如果版本太舊，它可能會拒絕執行。

如果你是用 AI 製作應用程式，又不想直接使用命令列，可以這樣要求：

使用 pg_dump 的自訂格式為應用程式的資料庫建立備份，檔案名稱包含今天的日期。請不要印出連線字串或任何機密資料。完成後告訴我檔案名稱和大小。

第四步：自動化備份

手動備份很容易被忘記。請按你的設定，使用以下任何一種方式自動化：

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

無論選擇哪一種，都要確保備份失敗時會通知你。備份工作悄悄失敗了三個月，是最典型的恐怖故事。

第五步：把副本存放在其他地方

一般會以「3-2-1 法則」作為參考：三份資料副本，存放在兩種不同類型的儲存媒體上，並且其中一份存放在異地。對小型應用程式來說，實用的做法是：

• 正式運作中的資料庫
• 服務供應商自動提供的備份
• 你自己的傾印檔，存放在另一個帳戶中的獨立物件儲存桶等地方

此外還要注意：

• 限制存取。 備份包含每位用戶的資料，應與正式資料庫同樣看待。
• 訂立保留政策。 例如每日備份保留兩星期，每月備份保留一年。舊備份要有計劃地刪除，並留意私隱法例可能規定，應用戶要求刪除其個人資料。
• 切勿把備份提交到 Git。 儲存庫中的傾印檔隨時會變成資料外洩的源頭。

第六步：測試還原

備份是否可靠，取決於你最近一次成功還原的結果。至少每幾個月測試一次，並且在任何備份流程改動之後也要測試：

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. 如果可以，讓應用程式的一個副本連接到這個資料庫，並嘗試登入。
3. 記下還原所需的時間。這就是你實際的復原時間。

第七步：在高風險改動前備份

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

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

在 AI 製作的應用程式中，代理可能會把資料表結構改動作為某項功能的一部分。檢查點和版本控制可以還原程式碼，但無法復原已刪除的資料列。在大改動前花三十秒做一次備份，是很便宜的保險。

常見錯誤

• 以為 Git 或程式碼匯出就是備份。 它們只有程式碼，沒有資料。
• 從未測試還原。 很多備份直到真正需要時才發現是空白、不完整或無法讀取的。
• 把備份存放在與資料庫相同的帳戶中。 一旦帳戶被入侵或關閉，兩者同時失去。
• 忘記上載的檔案。 資料庫只儲存檔案的路徑，圖片本身存放在儲存空間中。
• 把機密資料留在備份腳本內。 應從環境變數讀取連線字串，切勿寫在腳本的文字內容中。參閱如何妥善保管 API 金鑰。

備份與 Mythex

Mythex 專案可以擁有專屬的 Postgres 資料庫，其連線資料會注入工作區及已發布的應用程式中。Mythex 文件並未描述資料庫備份或還原功能，因此請自行規劃：要求代理製作傾印檔，下載後妥善保存，尤其是在大改動之前。專案匯出（Pro 方案）包含你的程式碼，並會排除機密資料和 node_modules；它不包含資料庫資料列。詳情請參閱文件中的資料庫和資料擁有權。如果想進一步了解資料庫本身，請閱讀什麼是 Postgres。

備份檢查清單

• 已決定能承受失去多少資料，以及能停止服務多久
• 已確認資料庫服務供應商提供哪些自動備份
• 你自己的傾印檔按排程執行，失敗時會發出通知
• 副本存放在獨立於資料庫的地方，並限制存取
• 保留政策已寫下來
• 上載的檔案與資料庫一併備份
• 已測試還原到空白資料庫，並核對資料列數目
• 每次高風險改動之前都已備份

常見問題