Cloudways Staging 資料庫推送教學：避免覆蓋訂單與會員資料

把 Staging 的資料庫推送到正式站是高風險操作：測試站建立後，正式站可能已新增訂單、會員、留言或表單資料。本文示範 Cloudways 推送前如何界定檔案和資料庫範圍、建立備份並在完成後驗證。截圖中的網域、IP、帳戶、電郵、伺服器及應用程式名稱均已遮蔽。

哪些情況不應整庫推送？

若正式站持續接收訂單、註冊、付款或表單，整庫覆蓋很可能遺失新資料。應優先只推送檔案、選擇性資料表，或由技術人員制定合併方案。

在推送入口先確認來源與目的地，避免從過期測試站或錯誤環境推送。公開畫面只使用「測試站」與「正式站」匿名標籤。

若變更只涉及主題、外掛、CSS 或程式碼，先選擇檔案模式。推送前記錄會覆蓋的路徑，避免把使用者上載或設定檔意外換回舊版本。

若確實需要資料庫變更，先識別涉及設定、內容、訂單、會員和外掛資料的表格。不要在未備份或未了解資料表用途時推送整庫。

在執行前建立正式站按需備份，確認完成時間和還原入口。若推送結果不如預期，先停止其他變更，再使用已驗證的回退點。

確認來源、目的地、檔案／資料庫範圍和備份狀態。高流量或付款中的網站應安排維護時段，並在操作前通知相關團隊。

完成後測試首頁、登入、表單、購物車、付款、會員和最新內容，再查看 PHP、部署與應用程式日誌。觀察一個高峰週期，確認沒有延遲出現的資料問題。

仍有風險，例如新舊外掛版本不一致或設定檔被覆蓋。應先備份、在 Staging 測試，並記錄推送內容。

立即停止新變更，保存現況及錯誤時間，使用備份或資料庫專家協助復原。不要反覆推送，否則會令可救回資料更少。

Staging 資料庫推送的安全原則是先界定範圍、優先檔案模式、備份正式站、覆核摘要，再完成完整驗證。交易和會員網站尤其需要避免整庫覆蓋。