VPS 更新網站時哪些檔案不能覆蓋？我製作安全更新包的做法

為什麼更新包不能包含整個網站目錄？

以前更新網站時，我最直接的想法，是把本機修改後的專案全部壓縮，再上傳到 VPS 覆蓋原來的程式。

這種做法看起來比較省事，但我後來發現，網站目錄裡不只有程式碼，還包含正式環境才會使用的設定、密碼、資料庫資料和使用者上傳的圖片。

如果更新包把這些檔案一起帶上去，解壓縮時就可能覆蓋 VPS 上正在使用的正式資料。程式也許更新成功了，但網站可能會因為設定被替換、圖片遺失或資料庫連線錯誤而無法正常運作。

因此，我開始把「網站程式」和「正式環境資料」分開處理。

我會從更新包中排除哪些內容？

製作更新包時，我會特別檢查以下專案：

1. .env 和其他環境設定檔。
2. 資料庫資料、備份檔和匯出檔。
3. uploads 上傳圖片目錄。
4. node_modules 程式依賴目錄。
5. dist 已經產生的舊建置檔案。
6. 包含密碼、金鑰或連線資料的設定檔。

.env 通常儲存資料庫密碼、網站網址和其他正式環境設定。本機與 VPS 的設定可能不同，所以不應該使用本機檔案直接覆蓋。

資料庫和 uploads 則屬於網站營運後產生的資料。它們不是單純的程式碼，一旦被舊版本取代，可能會造成文章、圖片或後臺資料遺失。

node_modules 可以根據 package.json 和鎖定檔重新安裝，不需要放進更新包。這個目錄通常包含大量小檔案，放進壓縮包只會增加容量和傳輸時間。

dist 是建置後產生的檔案。部署時重新建置，可以避免舊版本輸出混入新的網站程式。

安全更新包應該包含什麼？

我的更新包只保留這次真正修改的程式碼、必要的資料庫遷移檔，以及部署說明。

如果加入了新的程式套件，我也會同步更新 package.json 和鎖定檔。這樣 VPS 在重新建立網站時，才能安裝與本機相同的依賴版本。

更新包不是完整備份，也不應該取代完整備份。它的用途只是把經過確認的程式修改安全地送到 VPS。

上傳前先確認更新包

完成更新包後，我不會立刻解壓縮，而是先檢查檔名、儲存位置和檔案大小。

我會確認更新包確實位於本機電腦，而不是放在已經刪除的 OneDrive 舊目錄。檔名也會加入清楚的功能名稱或日期，避免同時存在多個更新包時選錯檔案。

如果壓縮包的容量突然比預期大很多，我會重新檢查裡面是否誤放了 node_modules、uploads、備份檔或其他不應該上傳的內容。

這個簡單的檢查，可以在檔案進入正式伺服器之前發現問題。

必須在本機 PowerShell 執行上傳

我以前曾經把本機 PowerShell 和 VPS 終端的指令混在一起。

當畫面顯示：

root@伺服器名稱:~#

代表我目前正在 VPS 裡面。這時候直接輸入 C:\projects\... 之類的 Windows 路徑，VPS 並不能讀取，因為那個檔案只存在我的電腦。

正確做法是保留 VPS 視窗，再另外開啟一個本機 PowerShell 視窗。確認提示符號顯示為：

PS C:\...>

然後從本機執行 SCP 上傳，把更新包傳到 VPS 的 /root/ 目錄。

上傳完成後，畫面會顯示 100%。這只代表檔案傳輸完成，還不代表網站已經更新。

上傳完成不等於可以直接覆蓋

在解壓縮更新包之前，我會再次確認 VPS 已經完成程式和資料庫備份。

如果這次更新包含資料庫欄位調整，我也會先閱讀遷移檔，確認它應該執行一次還是可以重複執行。資料庫遷移通常不能在不確定的情況下重複執行。

我的處理順序是：

1. 在本機檢查更新包內容。
2. 將更新包上傳到 VPS。
3. 確認網站程式備份存在。
4. 確認資料庫備份存在。
5. 最後才解壓縮和重新建立網站。

這樣即使部署過程出現問題，我仍然保留可以回復的原始程式和資料。

在正確的 VPS 目錄解壓縮

更新包上傳完成後，我會重新進入 VPS，並先切換到網站實際使用的專案目錄。

我的網站專案位於：

/root/source-code

在解壓縮之前，我會再次檢視當前所在位置和更新包名稱，避免把檔案解壓到 /root/、其他專案目錄或錯誤的網站版本中。

確認路徑無誤後，才把更新包解壓到正式專案目錄。解壓縮完成沒有出現錯誤，只代表檔案已經放到指定位置，接下來仍然需要重新建立網站。

重新建立網站並檢查容器

如果更新加入了新的程式依賴，我會先根據 package.json 和鎖定檔安裝依賴，再使用 Docker Compose 重新建立應用程式。

重新建立過程中，我會從錯誤資訊最早出現的位置開始檢查，而不是隻看終端最後一行。

建立成功後，我會確認兩個主要服務：

• 網站應用程式容器已經啟動。
• MySQL 容器維持 Healthy 狀態。

同時還要檢視網站日誌，確認沒有資料庫連線失敗、缺少環境變數或模組無法載入等錯誤。

如果新版本建立失敗，原來的容器通常仍可能繼續執行。因此我不會因為看到大量紅色錯誤，就立刻重複覆蓋檔案或刪除資料庫，而是先確認舊網站是否仍然能夠開啟。

部署後必須實際檢查網頁

容器顯示 Started 並不代表所有頁面都正常。

我會使用電腦和手機實際開啟網站，並檢查：

1. 首頁能否正常顯示。
2. 新文章和舊圖集能否開啟。
3. 文章圖片是否仍然存在。
4. 後臺能否登入和編輯內容。
5. 普通文章是否連續顯示，不再出現上一頁和下一頁。
6. 舊圖集是否繼續保留原來的分頁功能。
7. 舊網址是否正確跳轉到新的固定網址。
8. 推薦內容的標題、圖片和連結是否對應。

完成這些檢查後，我才會確認更新成功。臨時更新包也不會立即刪除，而是等網站穩定執行一段時間後再清理。

這次處理讓我建立的更新原則

經過多次實際部署，我現在會把網站內容分成三個部分：

• 程式程式碼：通過安全更新包部署。
• 正式環境設定：保留在 VPS，不由更新包覆蓋。
• 資料庫和上傳圖片：獨立備份並持續儲存。

這種方式雖然比直接壓縮整個目錄多幾個步驟，但每個檔案的用途更加清楚，發生問題時也比較容易判斷原因。

對我來說，一個安全的更新包並不是包含越多檔案越好，而是隻包含這次更新真正需要改變的內容。

先排除敏感資料、完成程式和資料庫備份，再上傳、解壓縮、重新建立和逐項驗證，才是我現在更新 VPS 網站時會遵守的完整流程。