Synology NAS Docker 維運 SOP：更新、備份與還原

在 Synology NAS 上架好 Vaultwarden、Immich、Jellyfin 或 Home Assistant 的那一刻，很容易以為最困難的部分已經結束。

其實剛好相反。服務開始承載你的密碼、照片、影音或家庭自動化後，真正重要的問題才出現：容器要不要更新？更新前該備份哪裡？服務打不開時，要從哪一層開始查？NAS 換機或資料毀損時，能不能重建回原本的樣子？

這篇不是教你多裝一個 Docker 服務，而是給已經有幾個容器在跑的 Synology 使用者一套實際可執行的維運 SOP。它不需要企業級工具，也不要求你每天盯著 NAS；重點是讓更新、備份、監控與還原有固定順序。

🎯 這篇適合誰

🧭 維運不是「每天更新」，而是知道下一步做什麼

家用 NAS 最常見的兩個極端是：

• 容器看到有新版本就立刻更新。
• 一次架好後，半年都不敢碰。

前者有可能把不相容的版本直接帶進正式環境；後者則可能錯過安全修正，也會讓日後一次累積太多變動，很難排錯。

比較穩的做法是把服務分級：重要資料優先保守，純娛樂或測試服務可以稍微積極。你不需要追每一版，只要在自己能承受的節奏下，做到「更新前可回退、更新後有確認」。

如果你還沒有用 Compose 管理服務，建議先讀 Synology Docker Compose 完整教學：資料夾結構、更新與維護。Compose 把容器設定留在檔案中，是可重建、可備份的起點。

📋 先建立服務清單，不要靠記憶維護

當 NAS 只有一兩個容器時，憑印象還撐得住；服務變成十個以後，最危險的往往不是技術，而是你已經不知道「這個資料夾是誰的、刪掉會不會出事」。

請先建立一份簡單清單。放在 NAS 的 docker/README.md、筆記軟體或試算表都可以，格式不重要，資訊完整比較重要。

這份表至少要回答五件事：

1. 這個服務壞了，誰會受影響？
2. 它的 docker-compose.yml 放在哪？
3. 真正重要的持久化資料放在哪個 volume 或資料夾？
4. 它有沒有對外公開？公開入口是反向代理、VPN，還是直接開 port？
5. 最近一次成功備份和還原演練是什麼時候？

把服務分成「高、中、低」三種備份等級即可。密碼、照片、文件、資料庫是高；監控歷史和媒體伺服器設定通常是中；純測試或可隨時重建的服務才是低。這個分類會決定你更新前要做多少準備。

🗂️ 資料夾與設定檔：先把可重建的東西留好

每一個 Docker 服務最好獨立放在自己的目錄。概念如下：

複製/volume1/docker/
  vaultwarden/
    docker-compose.yml
    .env
    data/
  uptime-kuma/
    docker-compose.yml
    data/
  jellyfin/
    docker-compose.yml
    config/
    cache/

這種結構的關鍵不是整齊，而是把「如何建立服務」和「服務正在使用的資料」留在一起：

• docker-compose.yml：服務的規格書，記錄 image、port、volume、network 與 restart policy。
• .env：帳密、路徑、時區或版本號等不想直接寫在 Compose 檔的值。
• data/、config/、uploads/：真正要留住的持久化資料。

.env 不該直接放到公開 Git repository；但它又常常包含重建服務必要的資訊。最務實的做法是把它納入加密備份，或至少把需要的變數與秘密保存於可靠的密碼管理器。若你還沒有做這件事，Vaultwarden 自架 Bitwarden 完整教學 可以作為起點。

另外，請避免把所有服務的資料都塞在同一個 appdata 目錄而沒有分隔。出問題時，獨立資料夾可以讓備份、還原與刪除都更有把握。

🔄 更新前的標準流程：先備份，再動手

「看到新 image 就按更新」不是 SOP。重要服務建議照下面順序走，熟了以後一次只要十幾分鐘。

1. 先判斷這次要不要更新

不是每個更新都同樣急。先看服務的發布說明或專案公告，判斷它是：

高重要性服務不要只使用模糊的 latest 標籤。當你要更高的可預期性，可以在 Compose 裡指定已驗證的版本標籤；等你看完更新說明、備份完成後，再主動改成新版本。這樣出問題時，至少知道自己從哪一版升上來。

2. 確認備份不是「看起來有在跑」

更新前至少確認最近一次備份任務成功，而且備份範圍包含該服務的持久化資料夾、Compose 檔與 .env。如果是資料庫型服務，還要確認官方建議的是檔案層級備份、資料庫匯出，或兩者都要。

例如 Immich、Gitea、Nextcloud 這類有資料庫的服務，不能只因為複製了某一個資料夾就斷定可以完整還原。請依服務官方的備份與升級說明，確認資料庫和上傳檔各自要怎麼保護。

Synology 端可以用 Hyper Backup 完整教學 建立版本備份；如果你希望有離站副本，可再參考 Hyper Backup 備份到 Cloudflare R2。

3. 記錄目前運作中的版本與狀態

在動手前截一張服務首頁或 Container Manager 狀態畫面，並寫下：

• 現在的 image tag 或版本號。
• 容器目前是否健康、是否有反覆重啟。
• 使用者能否登入、核心功能是否正常。
• 是否剛改過反向代理、DNS、憑證或防火牆設定。

這看起來有點多餘，但更新後出狀況時，它能幫你分辨「是新版本造成的」還是「原本就已經不穩」。

4. 在維護時段更新，不要邊用邊賭

對重要服務，挑一段不會有人正在上傳相片、看影片或登入密碼庫的時間。若服務要做大版本升級，先告知家人或使用者；有時候最好的維運工具就是一句「今晚十點會短暫維護」。

如果你是用 SSH 搭配 Docker Compose 管理，常見的更新流程如下。請在該服務的 Compose 目錄執行，並先確認路徑正確：

複製docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100

pull 只會下載你 Compose 檔指定的 image；up -d 會依現有設定重新建立需要更新的容器。不要為了更新就習慣性執行會一併移除資源的指令，也不要在不理解影響範圍時清理 volume。

偏好圖形介面時，可以用 Container Manager 或 Portainer：Container Manager 視覺化升級 操作；原則仍然一樣：先確認設定與備份，再重新部署，最後驗證。

✅ 更新後的驗證：容器顯示 Running 還不夠

容器是 Running，只代表程序沒有立刻結束，不代表服務真的可用。更新完成後，最少做這四件事：

1. 用內網網址開啟服務，確認登入頁與主畫面正常。
2. 做一個核心動作，例如新增一筆測試資料、上傳一張測試相片，或讀取一個既有項目。
3. 用平常對外的網址測一次，確認反向代理與 HTTPS 路徑沒有被影響。
4. 看容器最近的日誌，確認沒有資料庫遷移失敗、權限錯誤或連線失敗。

如果服務走 Nginx Proxy Manager 反向代理，要同時測內網網址與外部網址。這可以幫你辨別問題是在應用程式本身，還是在網域、憑證或反向代理那一層。

💾 Docker 備份的三個層次

很多人說「我有備份 Docker」，實際上只備到其中一層。要能安心還原，至少把下面三層分開想。

第一層：服務定義

這是 docker-compose.yml、.env、自訂設定檔、反向代理紀錄，以及你為服務寫的操作筆記。

少了這些，你可能還有資料，卻不知道當初怎麼把服務跑起來。這一層檔案通常很小，卻是最容易被忽略的救命資料。

第二層：持久化資料

例如：

• Vaultwarden 的密碼庫資料。
• Uptime Kuma 的監控歷史與通知設定。
• Gitea 的 repository、設定與資料庫。
• Jellyfin 的媒體庫設定、觀看紀錄與 metadata。
• Immich 的上傳檔與資料庫。

這些通常對應到 Compose 裡的 volumes:。請逐一確認它們是在 NAS 的資料夾中，而不是只存在 container 內部。Container 可以重建，沒有掛載出去的資料很可能會隨重建消失。

第三層：可用的還原能力

真正的備份不是「任務顯示成功」，而是你知道如何把它放回來。至少做過一次低風險演練：在測試資料夾還原一個檔案、重建一個不重要的服務，或用舊設定在不同 port 啟動。

這也是為什麼 3-2-1 原則仍然重要：同一台 NAS 上有副本，不等於可以抵抗 NAS 本身故障、誤刪或勒索軟體。需要建立整體策略時，可接著看 NAS 備份 3-2-1 原則實作。

📡 監控：讓你在問題變成抱怨前先知道

手動開網頁檢查服務，通常只會在你「剛好要用」的時候發現它壞了。監控的目標不是追求完美儀表板，而是把「不知道什麼時候掛掉」變成「幾分鐘內收到通知」。

Synology NAS 安裝 Uptime Kuma 很適合當第一個監控工具。對每個重要服務，建議至少建立兩種檢查：

內網 HTTP 和外部 HTTPS 同時存在不是重複：外部檢查失敗、內網還成功，通常是網域、憑證或反向代理問題；兩個都失敗，才更像是服務或 NAS 本身出了問題。

提醒一點：如果 Uptime Kuma 也跑在同一台 NAS，它無法偵測 NAS 完全斷電或整台死機。它仍能很有效地抓到單一容器、反向代理或應用服務異常。若你非常在意整台 NAS 的可用性，再把關鍵服務交給外部監控來源檢查。

🩹 故障時的還原順序

服務打不開時，先不要急著刪 container 重裝。刪除是不可逆動作，尤其當你還沒有確認資料存在哪裡。

請按由外到內的順序檢查：

1. 判斷問題在哪一層

2. 先保留現場

在變更任何設定前，先複製當前的 Compose 檔與重要設定，並保存最近日誌。即使服務已經壞了，這些資料仍可能告訴你它當初為什麼失敗。

也不要立刻把整個資料夾刪掉重新建。錯誤的 owner、錯誤路徑或遺漏環境變數，都可能讓「重建後看似乾淨」變成真正的資料遺失。

3. 用最小變更恢復服務

若問題是剛更新後產生，優先確認：

• Compose 檔是否仍使用正確的 volume 路徑。
• .env 裡的資料庫密碼、網址、時區是否齊全。
• 該版本是否要求資料庫升級或新增環境變數。
• 容器的日誌是否明確指出權限、連線或資料庫錯誤。

有明確原因時，先修正那一項再重新部署。不要同時改版本、改資料夾、改 port、改反向代理；一次改太多，只會讓你失去判斷依據。

4. 最後才進行還原

確認是設定或資料已損毀、且無法用小修改修復時，再依你的備份方案還原。最安全的順序通常是：

1. 停止有問題的服務，保留原資料夾作為現場副本。
2. 把備份還原到新資料夾或測試位置。
3. 用相同 Compose 設定、不同 port 測試啟動。
4. 確認資料完整、服務可登入後，再切換正式入口。

這樣做比直接覆蓋正式資料夾多一點步驟，卻能保留第二次修正的空間。維運最怕的不是第一個錯誤，而是為了救它又覆蓋掉最後一份可用資料。

🗓️ 每月維運清單

把以下清單排在每月固定一天，例如第一個週末晚上。一次處理全部服務，比每天零碎焦慮更有效。

每週 10 分鐘

• 看 Uptime Kuma 是否有反覆失敗或異常通知。
• 確認 NAS 儲存空間沒有接近滿載。
• 對最重要的服務做一次登入或核心功能檢查。

每月 30–60 分鐘

• 檢查高重要性服務是否有安全修正或必要升級。
• 確認備份任務成功，並抽查一個檔案能否還原到測試位置。
• 按「先備份、再更新、後驗證」流程更新已決定要升級的服務。
• 查看容器是否有反覆重啟、異常日誌或不再使用的服務。
• 更新服務清單，移除已停用的項目，補上新服務的資料位置與備份等級。

每季一次

• 演練還原一個低風險服務，確認 Compose 檔、資料與秘密資訊都找得到。
• 檢查遠端存取、防火牆與管理帳號；不再需要的入口應關閉。
• 檢查備份是否真的有異地副本，以及該副本的帳號與金鑰是否還能使用。

NAS 維運不是把所有時間花在維護，而是用少量固定時間，換取服務出狀況時不必手忙腳亂。

❓ 常見問題

Q：可以用自動更新工具嗎？

可以，但不建議把它當成所有服務的預設。純測試服務或不保存重要資料的容器，風險較低；密碼庫、相簿、資料庫、家庭自動化等服務，應先確認備份與相容性。自動更新省下的是點按時間，付出的可能是排錯成本。

Q：我只備份 /volume1/docker/，這樣夠嗎？

不一定。先確認所有 Compose volume 都真的掛載在這個目錄下；有些服務會另外使用照片共用資料夾、資料庫目錄、反向代理設定或 DSM 應用程式資料。備份範圍要跟你的服務清單一一對照。

Q：容器刪掉了，資料一定還在嗎？

如果資料有正確掛載到 NAS 資料夾，通常可以用 Compose 重新建立容器並接回原資料；如果重要資料只存在 container 可寫層，刪除後就很危險。這正是每個服務都要先確認 volume 的原因。

Q：NAS 已經有 RAID，還需要備份嗎？

需要。RAID 的主要用途是降低單顆硬碟故障造成的中斷，不等於能處理誤刪、勒索軟體、錯誤更新、火災或整台 NAS 故障。可用性和備份是兩件不同的事。

Docker 維運的成熟，不在於你裝了多少服務，而在於你是否能回答三個問題：資料在哪裡？壞掉時先查什麼？真的救不回來時如何還原？

把這套 SOP 跑過幾次後，更新就不再是一場賭注。服務可以慢慢增加，但你也會有一套穩定的方法，讓它們一直留在自己掌握得住的範圍裡。

🔗 延伸閱讀

• Synology Docker Compose 完整教學：資料夾結構、更新與維護 — 先把每個服務整理成可重建的 Compose 結構
• Synology NAS 安裝 Uptime Kuma：自架服務監控，掛了通知你 — 建立服務異常通知
• Hyper Backup 備份到 Cloudflare R2：版本化離站備份 — 幫重要資料建立離站版本副本
• NAS 備份 3-2-1 原則實作 — 把 Docker 服務放進完整備份策略