Zeabur搬遷完整指南｜備份、n8n與資料庫轉移檢查表

這份指南適合把網站、n8n、PostgreSQL、Neo4j，以及Docker／MCP服務從Zeabur搬到新環境的人。目的不是讓你盲貼一串指令，而是知道每一步要搬什麼、怎麼確認成功，以及出問題時怎麼退回。

本文是依官方文件整理的操作規劃，並非所有組合都已實測。版本、方案與部署方式不同，操作會有差異。正式服務或重要資料，請找熟悉該系統的人陪同操作。

初版：2026-10-17。2026-11-01依Zeabur官方公告重新查證：官方停運公告與遷移指南都已公開上線，並新增11/30申請期限與12/31資料刪除，已更新第1節。

先看這3件事

不要把12月31日當成你的服務保證期限。 先查自己的服務類型與專用伺服器到期日。
先做可帶走的備份，再測試還原。 後台顯示「備份成功」，不代表你已經能在別處恢復。
搬家與資安處理要並行。 尤其是環境變數裡的密碼、API key、token；但n8n解密金鑰不能直接亂換。

如果今天只有30分鐘：盤點服務、下載一份備份、確認n8n解密金鑰有安全保存。不要急著刪舊服務或購買新主機。

1. 時程：先確認自己的截止點

以下依Zeabur官方公告整理（2026-11-01查證）：停止營運公告、遷移、退款與資安事件申請說明。

即日起： 停止新的專用伺服器與網域購買；在Zeabur買的網域可以在Dashboard自助轉出。
2026/11/30前： 官方建議完成網站、應用程式、資料庫、儲存檔案、Email寄信設定及網域的遷移。這天也是帳戶餘額退款的工單申請期限（之後改Email處理），以及資安事件損失申請的截止日。
共享叢集：2026/12/1起暫停所有運行中服務。 官方說仍可手動恢復運行以備份資料，請不要把這當成正常營運延長保證。
專用伺服器：2026/12/1起停止續費，依各自到期日關機並刪除資料，可能早於12/31。每台機器的時間可能不同。
2026/12/31：所有服務停止，服務資料一併刪除。 不代表每個服務都能跑到這一天。
公告沒有寫精確時區，請不要自行補成某個時區的午夜。

官方遷移指南已上線： 搬出Zeabur：把這份指南交給你的Coding Agent，附可以交給Claude Code、Codex讀的Markdown版本。本文不是官方指南，可以和官方版對照著用。

建議安排： 共享叢集照官方建議在11/30前完成正式切換，並保留演練與修復時間；專用伺服器以自己最早的到期日往前排。

資安公告要看更新後的版本

10月事件的官方狀態頁後續修正了最初判斷：部分Google Cloud專用伺服器也遭未授權存取，平台資料庫受影響內容包括服務環境變數、帳戶資訊與API tokens。不要沿用「專用伺服器都沒有受影響」的舊說法。

官方建議輪替環境變數中的秘密資訊並重新產生Zeabur API token；Google Cloud專用伺服器用戶另須處理root密碼與不明SSH金鑰。具體影響以官方通知及自己的紀錄為準。參考：10月官方事件狀態頁、8月事件報告。

2. 搬家前，先弄懂4個名詞

程式碼／映像檔： 決定服務怎麼運作，像是Git repository、Docker image。
環境變數： 服務啟動時讀取的設定，可能包含連線位址或秘密金鑰。
Volume／持久化磁碟： 容器重新建立後，仍要保留下來的檔案。
資料庫： 真正保存工作流程、帳號、訂單或圖譜等資料的地方。

只搬程式碼，通常不會把資料一起搬走。只備份資料庫，也可能漏掉附件、金鑰或自訂節點。

3. 盤點清單：一個服務填一份

把下面模板複製到自己的私人工作文件。公開文件或社群只放空白模板，不要填入真實連線資訊。

服務名稱與用途：
類型：靜態網站／一般應用／n8n／PostgreSQL／Neo4j／其他
所在環境：共享叢集／專用伺服器
已確認的停機／到期日期：
程式碼來源、分支與目前commit：
軟體版本、Docker image tag／digest、CPU架構：
啟動指令、port、health check、反向代理設定：
需要的資料庫、Redis、外部儲存與其他服務：
所有volume名稱、掛載路徑、容量與檔案用途：
環境變數「名稱」清單（秘密值另外存放）：
網域、DNS管理位置、Webhook、OAuth callback、IP白名單：
定時任務、背景worker、會發訊息／寫資料／執行付款的流程：
最近備份時間、備份位置、還原測試結果：
誰負責切換、誰確認可以退役舊環境：

先畫出依賴關係。 例如「n8n → PostgreSQL」、「MCP → Neo4j」。搬遷演練通常先準備資料庫，再接應用程式；正式切換時則先停止會寫資料的應用與排程。

4. 搬去哪裡？先看需求，再挑平台

這份指南不直接推薦購買某台VPS，也不把最低價格當成適用規格。你可能已有可用主機，先確認容量與維運能力。

純靜態網站： 評估靜態託管；先確認沒有SSR、後端API或必須保留的本機檔案。
常駐Docker／MCP／n8n： 需要可持續運行、支援背景工作與持久化儲存的環境。
資料庫： 自管可控制較多細節，但要自己處理更新、備份與復原；代管則要確認版本、extensions、匯入限制與匯出能力。
既有VPS： 檢查CPU、RAM尖峰、磁碟可用空間、I/O、流量、架構、備份和安全狀態。不要只看服務目前「啟動得起來」。

挑選前至少回答：能不能匯入現在的備份？能不能再匯出？誰處理更新與故障？備份是否在不同故障範圍？憑證、網域和資料由誰掌握？

第一次自管主機的人，請把維運能力列入選擇。n8n官方也提醒，自架涉及伺服器、安全與資源管理，錯誤設定可能造成資料遺失或停機。n8n自架說明

5. 先備份，再做一次真的還原

所有人都要做

保存程式碼、部署設定與精確版本；不要只留一張後台截圖
匯出資料庫，另存volume／附件／外部物件儲存
安全保存必要的解密金鑰與設定；不要貼進公開文件、Git或聊天截圖
把備份下載到自己能控制、且不依賴Zeabur繼續運作的位置
保留至少兩份受控副本，記錄日期、來源、大小與校驗值
在獨立測試環境真的還原，並用應用程式驗證

備份檔可能含個資、密碼或商業資料。限制讀取權限，傳輸與儲存採用適合的加密方式；解密所需資訊也要安全保存，不能只放在即將關閉的環境。

使用Zeabur後台備份時

官方文件描述：volume備份只涵蓋掛載資料，不包含其他位置的程式碼；一般有狀態服務的離線備份需先暫停。資料庫有另外的線上備份流程。確認備份完成後，要點下載並另存。

官方文件列示備份保留7天，不要把平台保存的備份當成長期保險，而且12/31服務資料會一併刪除。Zeabur備份文件

還原演練的安全規則

新測試環境使用獨立資料庫與volume，不能指回正式資料庫。啟動前先隔離正式流量與外部副作用，避免備份中的排程一開機就寄信、發文或寫入第三方系統。測試使用沙盒帳號、測試收件人與可辨識的測試資料。

6. n8n + PostgreSQL：最常漏掉的是解密金鑰

完整搬遷要帶走什麼？

n8n不能只按「下載workflow」。完整復原至少要一起處理：

PostgreSQL資料庫
n8n使用者資料夾.n8n；Docker常見掛載位置為/home/node/.n8n，以實際設定為準
原本的N8N_ENCRYPTION_KEY，或.n8n/config裡的金鑰
檔案型binary data、附件、外部儲存與自訂目錄
部署設定、社群／自訂節點的名稱與版本、所需套件

Workflow／credentials JSON匯出可作補充，但不等於使用者、權限、執行歷史、變數與設定都完整保留。n8n完整備份與還原

金鑰保留與安全輪替，分兩條線處理

第一條：先確保能解開舊資料。 新環境復原舊資料庫時，需要原本相符的解密金鑰。不要在舊資料庫上直接把N8N_ENCRYPTION_KEY換成隨機新值；這可能讓已儲存的credentials無法讀取。自訂加密金鑰文件

第二條：處理疑似外洩的登入憑證。 到對應服務商建立替代API key、撤銷舊token、重新授權OAuth，並更新新環境。依風險決定撤銷時機；如果已出現濫用，先撤銷並接受必要中斷，不要為了零停機繼續放任舊key。

兩者不是同一件事。換外部服務API key，不會自動更換n8n的資料加密方式；保留舊解密金鑰，也不表示舊key可以無限期繼續用。若n8n主金鑰疑似外洩，應另訂版本適用、已演練的重建／重新加密方案，不要現場試錯。官方的資料加密金鑰輪替機制有版本與回復限制，也不等同直接替換主金鑰。n8n金鑰輪替文件

選用：補充匯出workflow與credentials

以下是n8n CLI指令示例，需在你的n8n執行環境內操作，先核對版本。輸出目錄必須可持久保存，並下載離開舊主機。兩種檔案分開放。

n8n export:workflow --backup --output=backups/workflows/
n8n export:credentials --backup --output=backups/credentials/

此處不使用--decrypted，因為它會把憑證輸出成明文。即使加密的匯出檔也要視為機密。完整資料庫還原與JSON匯入是不同路線，不要兩種都盲目執行；JSON含原ID，匯入既有環境可能覆蓋同ID物件。n8n CLI文件

還原n8n的順序

先用目前相同版本建獨立測試環境；搬家與升級分開。
讓n8n保持停止，還原PostgreSQL、.n8n與其他必要檔案，檢查檔案權限。
設定新資料庫連線與正確的舊解密金鑰，確認不是連回正式資料庫。
重建相容的社群／自訂節點。來源可信度與版本要核對，不要把疑似受入侵主機的未知執行檔直接照搬。
隔離外部副作用後才啟動。資料庫整份還原可能保留流程啟用狀態，不要因JSON匯入通常停用，就以為整份還原也安全。
檢查登入、workflow、credentials解密、附件、重要節點與執行記錄。
若使用queue mode，盤點main、worker、webhook processor、Redis及未完成工作，安排排空；相關程序要使用相同解密金鑰。不要把舊queue直接重播。binary storage的支援方式也要核對。Queue mode文件

7. PostgreSQL：備份格式對了，才知道用什麼還原

先確認這5件事

來源PostgreSQL主版本、資料庫名稱與大小
使用者／roles、擁有者與權限
extensions、編碼與locale
目標是否支援相同需求，尤其是代管資料庫的權限限制
備份格式是純SQL，還是custom archive

pg_dump通常處理單一資料庫，不會把整個叢集的roles一起帶走。需要另規劃帳號與權限，不能假設還原完應用就一定能登入。新手優先在相同主版本演練；跨版另做相容性檢查，避免降版。pg_dump工具也不能比來源伺服器主版本更舊。PostgreSQL SQL Dump、pg_dump

指令示例：自行製作custom-format備份

以下給懂得辨識來源／目標的人使用；不會替你建立主機或資料庫。請把大寫占位文字換成正確值，保留引號。命令使用互動式密碼提示，不把密碼寫在命令中。TLS與網路連線依資料庫供應商要求設定，不要為求方便關閉安全驗證或把資料庫全面公開。

pg_dump --host="SOURCE_HOST" --port="5432" --username="SOURCE_USER" --dbname="SOURCE_DB" --password --format=custom --file="backup.dump"

先確認退出狀態成功且沒有錯誤，再查看檔案大小並保存校驗值。接著列出備份內容：

pg_restore --list "backup.dump"

列得出來只是初步檢查，仍需真的還原到新的空白測試資料庫。確認目標是獨立的RESTORE_TEST_DB，不是正式資料庫；先由管理者準備需要的roles／extensions／權限，再執行：

pg_restore --host="TARGET_HOST" --port="5432" --username="TARGET_USER" --dbname="RESTORE_TEST_DB" --password --exit-on-error "backup.dump"

這個示例沒有--clean或覆蓋選項。若遇到owner／權限錯誤，先修正還原計畫，不要忽略錯誤繼續切換。某些代管情境需調整ownership／ACL，但要明確重建所需權限，不能一律刪掉檢查。pg_restore文件

如果拿到的是Zeabur下載的`.sql`

官方文件表示，PostgreSQL線上備份使用pg_dumpall，可能包含多個資料庫與全域物件。它不是上面的custom archive；不要拿pg_restore硬讀，也不要當成單一資料庫備份直接丟進正式環境。先由管理者檢視內容、確認roles／建庫與權限需求，再在隔離環境依psql路線復原。Zeabur備份格式說明

最後比較重要資料表數量、筆數、抽樣內容、索引與應用程式讀寫。只看到資料庫「連線成功」不算驗收。

8. Neo4j：先分清楚Community、Enterprise與版本

不要把PostgreSQL的備份指令套到Neo4j，也不要直接複製正在寫入的資料目錄。

Community： 使用離線dump／load路線，需安排Neo4j停機。先停止依賴它的MCP／應用程式，再安全停止資料庫。
Enterprise： 可依版本使用線上backup工具，也可使用符合條件的離線dump；多資料庫或叢集要有專門計畫。
代管服務： 先核對目標支援的匯入格式、版本、edition與容量限制，不假設任何dump都能直接上傳。

來源：Neo4j備份與還原總覽、線上備份。

離線dump／load示意

以下採現行neo4j-admin database語法，舊版語法可能不同。使用相符版本的工具，在具備資料檔權限的環境執行。來源資料庫必須離線；Community的DBMS也需停止。備份目錄需先建立並限制讀取權限。

neo4j-admin database dump neo4j --to-path="/PRIVATE_BACKUP_DIR"

這裡neo4j是示例資料庫名稱。停掉容器後，不能再對它直接執行容器內指令；容器部署需由熟悉Docker的人，用相同版本管理工具掛載已停止服務的資料volume，避免另一個資料庫程序同時開啟它。離線備份文件

把dump帶到全新、隔離且相容的目標環境，確認沒有要保留的同名資料庫。Community目標DBMS停止時，依正確檔案權限執行：

neo4j-admin database load neo4j --from-path="/PRIVATE_BACKUP_DIR"

沒有加入覆寫參數。若目標已有同名資料庫，先停下來確認，不要為了消除錯誤直接覆蓋。Enterprise新資料庫可能另需建立資料庫步驟；請依自己的版本與拓樸文件處理。還原dump文件

Neo4j另外要保存與驗證

所有業務資料庫清單；system資料庫與使用者／角色另訂備份復原計畫，不能假設單一圖譜dump已完整處理帳號
設定、plugins、APOC／GDS等版本與授權需求
節點與關係數量、labels、constraints、索引，包含vector indexes狀態
代表性的Cypher查詢，以及MCP／應用的真實查詢
新連線URI、TLS、驗證方式、driver相容性與網路允許清單

9. 其他服務怎麼分流？

純靜態網站

重新取得程式碼、核對build command與輸出目錄，先用測試網址看圖片、深層路徑、重新整理、redirect和表單。build時嵌入的公開設定可能要更新；伺服器秘密不能打包進前端。

一般Docker／後端API

固定映像版本與架構；帶走部署設定、volume清單、啟動順序、健康檢查、必要檔案與外部依賴。容器不是備份，映像也不等於volume。資料庫要用相應一致性備份方式，不要把Docker的一般檔案打包示例當成所有資料庫都能熱拷貝的保證。Docker volumes文件

MCP服務

先分清楚是本機stdio，還是遠端HTTP／SSE等連線方式，再核對client實際支援的傳輸。保存版本與非秘密設定，更新資料庫位址、認證與允許存取範圍。測試時先呼叫唯讀工具；確認工具清單、權限、超時與長連線行為，再測有副作用的功能。

OpenClaw或其他常駐代理

把它當作可能持有帳號權限、瀏覽器工作階段與排程的服務盤點，不要當成單純網頁。確認實際版本、官方備份方式、工作目錄、設定與憑證儲存方式後另做遷移計畫。先暫停自主動作與排程，避免新舊兩邊同時發訊息或執行操作；未知或疑似受污染的環境不要整台原封不動搬過去。

10. 網址改了，還有這些地方要跟著改

自訂網域的DNS記錄與TLS憑證
n8n對外的WEBHOOK_URL與適用的編輯器網址設定
反向代理轉送標頭與實際代理層數，不要盲設N8N_PROXY_HOPS
第三方webhook設定、OAuth redirect URI與重新授權
CORS、allowed origins、IP白名單、資料庫／MCP連線位址
LINE／Telegram／Slack等整合的接收網址與驗證設定，依你實際使用的服務核對

n8n官方說明，反向代理後的webhook URL需正確設定，讓外部服務使用真正可連入的網址。n8n Webhook／反向代理文件

如果原本用的是平台配發網域，不要假設能帶走；先確認並準備替代網址。在Zeabur買的自有網域可以自助轉出，記得排進計畫；修改DNS與轉移網域註冊商是兩件事，不要同時亂改。提前降低TTL有助切換，但既有快取仍需要時間，不保證即時生效。

11. 正式切換：一次只允許一邊寫入

演練通過後，安排維護時段，通知受影響的人，記錄當次操作時間與負責人。

確認回復方案。 舊設定、DNS值、完整備份與金鑰都可取得；若舊環境疑似受入侵，不能預設回去就安全。
停止新工作進來。 暫停舊端排程、webhook入口與會寫資料的應用；處理正在執行與排隊的工作，記錄未完成項目。
做最後一次一致性備份。 包含資料庫與相關檔案；多服務有關聯時，要確保它們對應同一個可理解的業務時間點。
還原到正式新環境。 使用演練過的版本和步驟，不臨時順便升級。
在尚未開放正常流量前驗收。 先登入、讀取、抽樣、測試指定流程。
切換DNS、webhook、OAuth與相關client。 確認外部事件實際到達新環境。
只啟用新端排程與寫入。 舊端保持停止或受控唯讀，避免重複發送、重複執行與資料分岔。
觀察真實運作週期。 至少涵蓋你的關鍵排程與重要業務事件；若重要任務每週才跑，不能只看幾分鐘無錯誤就結案。

什麼情況要停下來？

備份無法還原、資料筆數異常、credentials無法解密
webhook收不到、OAuth失敗、附件遺失
發現新舊同時執行、重複副作用或未知資料變動
新環境資源不足、持續重啟或出現新的安全疑慮

回復不是只改DNS回去。 如果新環境已產生新資料，直接回到舊資料庫可能遺失或重複資料。先暫停寫入，保存新環境資料與事件紀錄，決定如何同步或補做，再執行經確認的回復方案。

12. 最後驗收清單

備份已離開Zeabur，且有成功還原紀錄
所有必要的資料庫、檔案、金鑰與設定都能取回
使用者登入與最小必要權限正常
n8n重要workflow與credentials正常，沒有缺節點或附件
PostgreSQL重要資料、權限與應用連線正常
Neo4j查詢、索引與MCP呼叫正常
DNS、TLS、Webhook、OAuth、排程時區已驗證
新舊環境沒有同時執行會產生副作用的工作
已處理疑似外洩憑證，並確認舊憑證撤銷後服務仍正常
新環境有獨立備份與可操作的復原說明
觀察涵蓋重要運作週期，負責人確認可以退役舊服務

全部確認後，才依保存需求退役舊服務、清理多餘備份與撤銷舊存取權。刪除前再次核對目標與可恢復性。不要為了讓搬家清單看起來完成，就先把最後一份可用資料刪掉。

常見問題

可以直接讓AI幫我全部搬完嗎？

AI可以協助盤點、整理設定與解讀錯誤，官方遷移指南也附了給Coding Agent讀的版本。但要先給它明確的來源、目標和可操作範圍。正式資料覆寫、憑證處理、切DNS、啟用排程與刪除舊服務，應逐步核對。不要把所有秘密貼進公開對話或公開文件。

有workflow JSON，是不是就安全了？

還不夠。它可能不包含你的使用者、歷史、外部檔案或可解密的credentials。請依第6節做完整備份與還原測試。

需要先升到最新版嗎？

通常先用原版本完成可重複的還原與搬遷，再另排升級；若原版本有急迫安全問題，需評估相容性與隔離措施，不要為了方便讓已知不安全的服務繼續對外。

12/1之後還能補救嗎？

官方說共享叢集暫停後仍可手動恢復運行以備份，但12/31服務資料會一併刪除，專用伺服器則在各自到期日就刪資料。現在先下載並測試，是風險更低的做法。

一句話記住

先盤點 → 先備份 → 先還原測試 → 再切換 → 驗證完成才退役。

這份指南可先收藏，搬遷時逐項對照。官方時程或產品文件更新後，請再次確認你正在使用的版本與操作方式。