阿里雲國際帳號註冊 香港雲伺服器系統鏡頭重置與保留數據盤重新安裝操作系統

第一章：先把概念想清楚——什麼是「鏡頭重置」與「保留數據盤」

在雲伺服器的日常運維裡，重置系統通常比你想像的更常見。你可能遇到系統損壞、磁碟分區錯亂、核心配置被誤改、應用依賴版本對不上，或只是想把環境拉回乾淨狀態。此時，「系統鏡頭重置」這種做法就很吸引人：它讓你把系統盤恢復到某個標準影像狀態，像是把主機的作業系統重新拉回起點。

但真正需要理解的是：重置通常針對的是「系統盤（System Disk）」或「根分區」，而「資料盤（Data Disk）」則可能保持不動。雲平台在界面上常用「保留資料盤」或「不覆蓋資料盤」來描述這件事。你要做的不是盲點選項，而是先搞清楚：你將被重置的是哪些分區、你希望保留的是哪一類資料、以及重置後它們是否還能被系統正確識別和掛載。

簡單說，這個操作的核心目標是兩件事的同時達成：第一，系統盤恢復乾淨；第二，資料盤的內容仍可用、仍能被應用程式繼續存取。這兩件事只要有一步做錯，就會出現看似「系統重裝成功但資料不見」或「資料還在但服務起不來」的尷尬局面。

第二章：開始前的準備——備份不是形式，而是風險保險

阿里雲國際帳號註冊 很多人把重裝當成「不會丟資料」的保證，原因通常是界面上寫了「保留數據盤」。可真實世界裡，風險來源常常不在於資料盤被刪除，而是在於你以為保留的是某個東西，實際上保留的只是「磁碟裝置」本身，資料位置、權限、掛載路徑、甚至服務使用的連結檔可能已經改變。

因此開始前，至少做三件事：

2.1 確認資料盤在你原本的系統裡被掛載到哪裡

在 Linux 上，你可以檢查 /etc/fstab、lsblk、以及目前的掛載點。你要把資料盤「實際被挂載的路徑」記下來，例如 /data、/srv/appdata 或其他。這一步很重要，因為重裝後系統可能沒有同一套 fstab 設定，導致資料盤雖然還在，但沒有自動掛載到你預期的位置。

如果是企業環境，常見情況是資料目錄並不是放在根分區，而是透過掛載或符號連結連到應用程式讀取的位置。重裝後符號連結可能失效或指向錯誤路徑，你就必須知道原來的關係。

2.2 針對「資料盤」做可驗證的備份

你不一定要完整備份整顆資料盤，但你至少要有「可驗證」的備份策略。所謂可驗證，意思是你能在另一個位置確認檔案確實存在、內容完整，而不是只有一份看不懂的壓縮包。

具體做法可以是：把重要目錄打包後放到獨立位置；或在備份完成後檢查檔案數量、大小、或抽樣檢查內容。若你使用資料庫，尤其要注意資料庫的備份方式是否一致：例如你要的是能回復的邏輯備份（SQL dump）還是物理備份（base backup），以及重裝後你是否還能用同一份備份還原。

2.3 記錄系統盤與網路設定的關鍵資訊

重置系統鏡頭後，系統盤的設定可能會變得更乾淨，但也可能把你原本在系統盤上配置的東西覆蓋掉。你至少要知道：網路設定、SSH 登入方式、防火牆規則、時區與 NTP、安裝的基本套件清單、以及你後續需要重建的服務項目。

這裡有一個常見誤區：你以為資料都在資料盤，所以重裝不影響服務。實際上服務的配置檔、憑證、啟動腳本、環境變數，很多時候都落在系統盤或依賴系統盤上的設定檔。即便資料盤保留，服務也可能因為配置缺失或憑證路徑變了而無法正常啟動。

第三章：執行「系統鏡頭重置」——把影像範圍控制在你理解的範圍內

阿里雲國際帳號註冊 在雲平台上執行系統鏡頭重置時，你通常會遇到幾個選項：選擇鏡像版本、是否覆蓋系統盤、是否保留資料盤、是否重置密碼或重新設定密鑰。你要做的是「先對照你的目標，再選對應的選項」。

如果你的目標是「重新安裝操作系統」且「保留數據盤」，那麼通常要確認兩點：

• 鏡頭重置的範圍：是否只針對系統盤或根分區？
• 資料盤保留的語意：是保留原裝置內容，還是也保留原本的掛載配置？

很多平台的文字看起來簡單，但實際行為可能細節不同。有的平台會保留資料盤內容，但系統盤重新生成後，資料盤可能在新系統的裝置命名（如 /dev/sdb、/dev/vdb）上發生變化，進而導致自動掛載失敗。還有的情況是，新的鏡像版本可能使用不同的磁碟映射策略或不同的預設套件，讓你原本依賴的工具不可用。

因此你要在開始前做「選項對照表」。例如：

• 目標系統版本：選與你原本應用相容的版本（尤其是作業系統版本與核心版本）。
• 是否保留資料盤：選保留後，確認資料盤是否仍可見。
• 重置密碼/SSH 金鑰：若你後續要自動化部署，確保你知道新系統的登入方式。
• 是否刪除/重建系統盤：通常必須重建才能達到「恢復乾淨」的效果，但也意味著你要把所有必要的設定重建計畫準備好。

第四章：重裝期間的注意事項——避免「看似完成其實卡住」

重置與重新安裝通常是雲平台在後台執行，過程可能包括關機、挂載影像、初始化檔案系統、重置引導項等。對你來說，最重要是不要在流程未完成時做多餘的操作，也不要急著假設服務會自動恢復。

你可以做的事情是：

• 觀察狀態是否真正完成（例如狀態從「重置中」變成「運行中」或「已啟動」）。
• 確認新系統的登入資訊（IP 不一定變，但憑證可能變）。
• 準備好一份「啟動後的驗證清單」，包含磁碟掛載、服務狀態、與應用可用性。

如果你需要更精確控制，建議在執行前設定維護窗口，並在重裝完成後立即進行驗證。因為資料盤保留並不等於應用馬上可用，很多故障會在「你以為應該好了」後才浮現。

第五章：開機後的關鍵步驟——資料盤能掛載、路徑要對、權限要可用

阿里雲國際帳號註冊 重裝完成後，先不要急著啟動服務，第一件事是把「磁碟狀態」確認清楚。你要回答三個問題：資料盤還在嗎？它在哪個裝置上？它被掛載到哪裡了？

5.1 確認資料盤是否存在、識別是否正常

在新系統裡使用 lsblk 或等價工具，確認資料盤的容量、分區、檔案系統類型（例如 ext4、xfs、ntfs 等）。若資料盤是分區形式，要確認分區號與原本一致；若是整顆盤做成單一分區，也要確認。

常見狀況包括：新系統看到的裝置代號變了；但檔案系統內容仍在。這並非錯誤，只要你能正確掛載到目標路徑即可。

阿里雲國際帳號註冊 5.2 檢查是否自動掛載；必要時手動掛載

你需要看是否有相依檔案。新鏡像可能不包含你舊 /etc/fstab 裡的設定，或 fstab 根本是新生成的。這時候最直接的方式是手動掛載一次，確認資料目錄可讀寫。

更穩定的做法是：在確認能正確掛載後，把掛載配置寫回 /etc/fstab，並使用 UUID 或永久識別方式，避免未來裝置代號改變導致自動掛載失效。UUID 通常是比 /dev/sdb1 這種命名更可靠的策略。

5.3 檢查目錄所有權與權限

保留資料盤並不代表保留所有權策略對應到新系統。原因是新系統的使用者 UID/GID 可能不同，或某些服務使用者在新鏡像裡不再存在。當你掛載成功後，如果應用程式報「permission denied」或無法讀寫，十有八九就是權限問題。

你需要做的不是盲目把權限設成 777，而是把權限調整到應用真正需要的使用者。通常可以先查資料目錄目前的擁有者與權限，再對照新系統中服務執行用戶，進行合理調整。

如果你原本把資料盤用於多服務共享，要特別小心群組權限（group）與檔案 umask 策略。重新安裝後 umask 或啟動腳本可能不同，會讓新建立的檔案落在非預期權限模式。

第六章：重新安裝與重建環境——把系統依賴的東西補回來

當資料盤可用後，你仍然需要重建系統盤上的應用依賴。重置系統鏡頭通常會帶來乾淨的 base，但也意味著你需要把原本用來支撐服務的元件重新安裝與配置。

這部分可以用「分層思維」處理：先把系統層（OS、網路、防火牆、DNS、時鐘）確認，再到平台層（語言環境、依賴套件），最後才是應用層（設定檔、服務啟動、外部對接）。

6.1 確認系統層：時間、網路與基本工具

很多問題其實是「小問題的連鎖」。例如系統時間不準會影響憑證驗證，DNS 解析異常會影響外部服務連接，防火牆規則重置會導致外部連不到。你應該把這些先驗證過，否則你會花時間在錯誤的地方排查。

6.2 套件與運行時環境：避免版本漂移

你選的鏡像版本可能跟舊系統不同，導致語言版本、套件版本有差異。若你的應用對某些版本敏感，就要在重裝後確認版本是否符合需求。最好的做法是：把原本的依賴版本記錄下來，重裝時依照文件重新建立。

如果你沒有版本記錄，也不要硬猜。可以透過應用程式的依賴管理檔（例如 package lock、requirements、composer.lock、或容器映像）來確保可重現性。你越重視「可重現」，未來再遇到同類事件就越省時間。

6.3 設定檔與憑證：別把它們假設已保留

設定檔與憑證通常在系統盤或特定目錄。重置系統後它們可能被清除。你需要確認你的應用設定裡，資料庫連線字串、儲存路徑、對外服務的 API Key、TLS 憑證路徑是否存在。

有些人把憑證放在資料盤，心裡覺得比較安全，但如果應用設定檔仍指向舊路徑，就會出現「證書文件找不到」。因此你不能只確認資料盤存在，還要確認應用設定是否指向正確位置。

第七章：服務切換與驗證——用「可觀測性」確保一切真的好了

重裝後的驗證不應該只靠「看起來能登入」。你需要有能量化的驗證方式，例如服務端口是否可連、核心流程是否通、錯誤日誌是否為零或在可接受範圍。

7.1 先啟服務，再測核心流程

啟動服務後，先檢查狀態是否正常（例如 systemd 服務狀態、容器健康狀態、應用 log 是否報錯）。接著測核心流程：登入、上傳/讀取、查詢、支付（若有）、或你最關心的業務鏈路。

尤其是使用資料盤的應用，最重要的是確保讀寫路徑正確，並且資料完整性沒有被因為掛載錯誤而破壞。例如你可能遇到掛載到錯誤分區、或掛載檔案系統後需要 fsck 修復的情況。這些在 log 裡往往會露出線索。

7.2 檢查資料庫與外部依賴（如有）

如果你的應用依賴資料庫（本機或外部），要確認連線。若資料庫也在資料盤或同一台主機，重裝後可能需要初始化服務、修復權限或重新建立索引。若資料庫是外部服務，通常只是連線參數或憑證需要重新設定。

驗證方式建議分兩層：連線層（能不能打到）、功能層（查詢是否正確返回）。只做連線測試不夠，功能層的測試能避免很多「能連但設定錯了」的問題。

第八章：常見錯誤與排查路徑——讓失敗更可控

這類操作常見錯誤可以分成幾類，對應的排查路徑也相對固定。

8.1 資料盤保留了，但資料「看起來不見」

通常原因不是磁碟被刪，而是沒有正確掛載，或掛載到不同路徑。你需要回到前面的檢查：資料盤是否出現在 lsblk，檔案系統是否可掛載，掛載點是否是你的應用期望的目錄。若應用讀的是某個固定路徑，確保掛載點與它一致。

8.2 掛載成功，但應用報權限錯誤

這通常是 UID/GID 不一致或目錄所有權改變。你要核對應用執行用戶，並調整資料目錄的擁有者或群組。避免「全盤放寬權限」當捷徑，因為那可能帶來安全風險並掩蓋真正的配置問題。

阿里雲國際帳號註冊 8.3 重裝後服務起不來

可能的原因包括：設定檔缺失、環境變數不存在、憑證路徑改了、依賴套件版本不匹配、防火牆規則被重置。排查順序建議：先看服務啟動時的錯誤日誌，再確認設定檔是否存在與內容是否正確，最後才調整套件版本。

阿里雲國際帳號註冊 8.4 網路可連，但對外服務不通

這常見於防火牆或安全組規則重置。你需要在雲平台層面確認安全組或防火牆設定，也要在主機層面確認服務正在監聽正確的地址與端口。

第九章：把它變成流程——可複用的操作清單

如果你經常遇到類似情境，建議把整件事固化成可重複的流程。下面是一個實用的清單（你可以按你的環境微調）：

• 確認資料盤掛載點、路徑、UUID（記錄下來）。
• 對資料盤的關鍵資料做可驗證備份。
• 記錄系統盤上的關鍵設定：網路、防火牆、時區、服務配置位置。
• 在鏡頭重置前列出要重建的服務與套件清單。
• 執行系統鏡頭重置，選擇保留資料盤。
• 重裝完成後登入新系統，先用 lsblk 確認資料盤存在與分區狀態。
• 必要時手動掛載資料盤，並把掛載配置寫入 /etc/fstab 使用 UUID。
• 檢查資料目錄權限與服務用戶匹配。
• 重建系統依賴（語言、套件、運行環境）。
• 恢復應用設定檔與憑證（確認路徑與內容）。
• 啟動服務並檢查日誌。
• 測核心業務流程，最後確認外部可用性。

你會發現，這套清單的重點不是在「怎麼重置」，而是在「怎麼保證重置之後依然可用」。當你把思考放在驗證與可重現性上，整體失敗率會大幅下降。

第十章：結語——重置不是破壞，而是更成熟的運維方式

把系統鏡頭重置、重新安裝操作系統，並同時保留數據盤，是一種成熟的運維手段。它的價值在於：當環境不再可控時，你不必花數天追著錯誤修補，而是快速回到可預期的標準狀態；同時把最有價值、最不應該丟失的資料留在那裡。

真正決定成敗的，不是你有沒有點選「保留資料盤」，而是你是否理解資料如何被掛載、如何被應用程式定位、以及權限與設定如何在新系統中延續。只要你在開始前做好核對與備份，在重裝後按順序驗證與修正，就能把一場看似高風險的操作，變成可控、可交付、可回復的流程。

下次當你或團隊遇到類似情況時，不妨先問自己三句話：重置的是什麼？保留的是哪一部分？驗證的指標是什麼？把這三句話想清楚，你就不會被「看起來完成」所騙，也能更穩定地在雲端維持服務品質。