香港雲伺服器系統鏡頭重置與保留數據盤重新安裝操作系統

引言：為什麼要做「鏡頭重置 + 保留數據盤」

在雲伺服器的日常運維裡，最讓人頭痛的不是「系統壞掉」，而是「壞掉之後你還得保住資料」。很多人第一次遇到這類情況時會直覺想整機重置，但一旦選錯範圍，數據盤可能也被連帶抹除，後續就算再重建服務，業務也已經失血。

因此，這篇文章聚焦一個更精準的做法：針對系統盤進行鏡頭重置（也就是重置系統狀態），同時保留數據盤，並在保持數據不被清空的前提下重新安裝操作系統。這種方案的優點很明確：不必從零搬運所有資料；可以用乾淨的系統環境修復依賴錯亂、升級失敗或安全配置混亂；而服務恢復速度通常比「手動修補整套系統」更快。

但要做好它也有前提：你得理解雲端資源在「鏡頭/映像、系統盤、數據盤、掛載點」這幾個概念之間到底是怎麼關聯的。你只要在某一步做錯選項，保留數據盤就可能變成口號。下面我們用一套可落地的流程把風險拆開處理。

第一章：在操作前先想清楚三件事

1. 你的目標是「重置」而不是「修修補補」

系統鏡頭重置的本質是把系統盤恢復到一個可控、可重建的狀態。它適用於：系統服務崩潰但你無法快速定位；套件依賴被污染；安全加固流程走偏；或你需要把環境標準化到指定版本。

如果你的問題只是單一服務的小問題，強行重置反而會浪費時間。建議先用最短路徑判斷：是否已經嘗試過重啟、回滾、重裝服務，仍無法恢復穩定？當故障牽涉到系統底層（例如網卡驅動、核心依賴、包管理器壞掉），重置就會更有價值。

2. 你要保留的是「數據盤內容」而不是「同一台機器的狀態」

保留數據盤通常意味著：在重新安裝操作系統後，數據盤仍然存在，且其中資料不會被清空。你需要確認雲平台是否允許「保留磁碟、只重置系統盤」。另外，資料盤在新系統裡的裝載方式可能會變動：設備名稱（例如 /dev/sdb）不一定永遠一致，所以不能只靠「以前是什麼掛載點」這種直覺。

換句話說，你要保留的是「磁碟上的內容」，而不是「舊系統會如何自動識別」。要靠掛載策略和配置檔，確保新系統能正確掛載它。

3. 你必須先知道哪些內容屬於系統盤、哪些屬於數據盤

很多事故發生在「以為資料在數據盤，其實在系統盤」。例如：

• 網站程式目錄（/var/www、/opt/app）放在系統盤？
• 資料庫檔案（MySQL 的 datadir、PostgreSQL 的 data directory）是否曾搬到數據盤？
• 日誌是否被設到系統盤？
• 設定檔是否只存在於系統盤（/etc 下）？

這些都會影響你重裝之後是否還能直接恢復服務。即使數據盤被保留，程式與設定仍可能需要重新部署。

第二章：準備清單（真的要做，因為它省時間）

1. 盤點資產

在重置前先寫下或截圖以下資訊：雲伺服器實例 ID、當前鏡頭/映像版本、系統盤類型與大小、數據盤的盤符/設備、掛載點、以及任何附加卷的規格。特別是數據盤：

• 數據盤是否為獨立磁碟？
• 是否已設定自動掛載？（例如透過 fstab 或雲端初始化腳本）
• 是否使用 LVM 或 RAID？

你需要知道它複雜到哪一步，因為越複雜的儲存架構，越依賴正確的識別流程。

2. 備份：不是只有「備份資料」，還包括「備份配置」

就算你保留數據盤，也仍建議備份兩類內容：

• 系統相關配置：例如 /etc 下的服務設定、使用者與權限（至少要知道有哪些目錄與權限）。
• 服務部署清單：例如容器映像來源、環境變數、啟動腳本、反向代理設定。

備份方式可以簡單：把關鍵配置壓縮保存到另一個存儲或對象儲存；或至少在操作日把配置複製到記事或文檔。重裝之後，你需要的是「能快速讓服務重新長出來」，而不是只保住資料庫檔案。

3. 記錄當前掛載資訊

在重置前，請把掛載情況記錄下來：例如使用 mount、df -h、lsblk 這類輸出。你要知道數據盤掛載到了哪個目錄、是 ext4 還是 xfs、檔案系統 UUID 是什麼。這會直接影響你重裝後如何保證自動掛載。

4. 檢查服務依賴是否會受重置影響

若你運行的是資料庫、訊息隊列、或依賴特定核心模組、特定版本的運行環境，請在重置前確認「新系統能否直接滿足依賴」。你不一定要一次做到完美，但至少要知道：哪些包需要在新系統先裝好，哪些設定需要從備份中覆蓋。

第三章：理解「鏡頭重置」與「保留數據盤」的操作邏輯

1. 鏡頭/映像代表的是系統盤的起點

系統鏡頭通常包含：操作系統內核、核心套件、基礎服務與初始化腳本。重置鏡頭後，系統盤會回到鏡頭指定的狀態或指定模板的狀態。這代表：你之前在系統盤上做的變更大概率會消失，包括手動安裝的工具、系統服務調整、以及系統級設定。

因此，重置後你應該把它視為「重新開機 + 全新系統環境」，只不過網卡、IP、以及數據盤內容可能維持在雲端資源層。

2. 數據盤保留是以「磁碟不刪除」為前提

保留數據盤通常意味着你選擇「系統盤重置」而不是「整機刪除並重新建立」。在雲平台的操作選項中，常見會有類似：

• 是否清除系統盤
• 是否保留額外磁碟
• 重置後是否會重建或保留資料盤

你必須逐一核對。最好用「最保守的方式」確認：數據盤是否在流程中被標記為刪除/格式化。任何可能格式化的選項都要先停下來確認後再點。

3. 重裝後的掛載點要重新建立信任

就算數據盤不刪，重裝後仍可能出現：設備名稱變了、fstab 沒有正確指向、掛載失敗導致服務找不到資料目錄。你要用兩個方法保護自己：

• 用 UUID 或標籤掛載（比用 /dev/sdb 這種名稱穩定）。
• 準備掛載驗證步驟：重裝後先確認資料盤能被正確讀取。

第四章：實際操作流程（從下決心到驗證完成）

步驟一：停服務並進行最後確認

在重置前先停掉依賴數據盤的服務，避免在你重裝的過程中寫入資料造成不一致。即使你保留數據盤，停服務仍能讓你後續恢復更順暢。你可以按優先順序停止：

• 先停 Web/應用服務
• 再停資料庫或需要寫入的服務
• 最後停止依賴鏈路（如果有訊息隊列、任務排程也一併停）

停止後做一次確認：確保程式已停止、端口不再對外提供服務，並保留一份「當前狀態」記錄（例如當前版本號、資料庫版本、主要設定路徑）。

步驟二：確認數據盤保留選項並鎖定風險邊界

進入雲端控制台時，請把注意力集中在與磁碟相關的選項上。核心原則是：系統盤可以重置或替換，但數據盤必須明確保留且不被格式化。

在做選擇之前，先做一個心智檢查：

• 重置範圍是否明確只涉及系統盤？
• 是否有「格式化資料盤」的選項？如果有，是否已被取消？
• 重裝後數據盤的掛載是否會自動恢復？若不能自動，是否有你的備份掛載配置可以套用？

步驟三：執行系統盤鏡頭重置與操作系統重新安裝

選定目標操作系統版本後執行重裝。這裡有兩個策略可以選擇：

• 保持相近版本：降低依賴差異。
• 升級到你要的標準版本：前提是你確定應用與資料兼容。

如果你近期要做安全加固或修補漏洞，升級到固定鏡頭版本是更合理的路徑。但若應用依賴較舊套件，保持相近版本會讓風險更低。

步驟四：重裝完成後先驗證「系統是否能讀到數據盤」

操作系統啟動後，第一件事不是開服務，而是驗證儲存可用性：

• 確認磁碟出現（例如 lsblk 是否顯示額外磁碟）
• 確認檔案系統類型與狀態（必要時檢查 fsck 計畫，但不要在不確定情況下擅自修復）
• 確認掛載點與目錄權限

如果你之前記錄了 UUID，那麼你可以直接用 UUID 對照並在 /etc/fstab 裡建立或修正掛載規則。接著執行掛載測試：確保數據目錄可讀可寫（取決於你的服務需求）。

步驟五：恢復服務之前先做資料一致性檢查

資料庫類服務最常見。重裝後你可能要做兩件事：

• 確認資料目錄已存在且未被意外清空
• 確認服務能正常讀取資料（例如檢查權限、檔案所有者、SELinux/AppArmor 狀態是否影響讀寫）

如果資料庫是有一致性要求的（例如 PostgreSQL、MySQL），建議先用最保守的方式啟動或使用其資料檢查工具，再進行完整服務啟動。你越早發現問題，越容易修復。

步驟六：從配置備份恢復服務與依賴

當數據盤已掛載且資料可讀，你就可以開始恢復應用。這時要按順序來：

• 先安裝系統依賴與運行環境（語言、套件、客戶端工具）
• 再恢復服務設定（/etc 或應用設定檔）
• 最後啟動服務並驗證功能

若你使用容器，通常需要重新拉取映像並重新建立容器，但資料卷會來自數據盤映射或已掛載的目錄。你要確保容器掛載點與數據盤目錄一致。

步驟七：驗證與回歸測試

重裝結束後，至少做三層驗證：

• 系統層：網路通、DNS、必要端口可被訪問
• 儲存層：資料庫可連、應用可讀寫
• 功能層：關鍵流程可用（例如登入、讀取核心頁面、寫入關鍵資料）

驗證通過後再考慮把服務切回正式流量。如果你的環境支持灰度或測試域名，這一步能大幅降低重裝造成的不可逆損害。

第五章：常見失敗情況與對應策略

失敗一：數據盤其實被格式化或清空

這是最糟的情況。通常原因是操作選項選到了「刪除/格式化」。一旦發生，能做的通常取決於你是否有額外備份、以及檔案系統是否真的被重建。若是檔案系統仍有可恢復的痕跡，可能需要資料恢復流程；若已被完整重建，恢復成本會非常高。

對策：重置前務必確認選項；同時做最基本的備份策略，即使你相信數據盤會保留，也仍建議把關鍵資料做快照或複製到另一處。

失敗二：掛載成功了，但權限錯誤導致資料庫起不來

重裝後 /etc/fstab 或掛載規則可能不同，權限也可能因為掛載方式改變。常見現象是：資料夾存在，但服務報「permission denied」或資料庫啟動失敗。

對策：在掛載完成後立刻檢查所有者與權限，並與應用期望一致。若你使用 SELinux，還要檢查安全上下文。

失敗三：設備名稱變了，fstab 指向了錯的 /dev/sdX

這個問題很常見。你重裝前可能是 /dev/sdb，但重裝後可能變成 /dev/sdc，導致掛載錯磁碟甚至掛載到空設備。

對策：使用 UUID 或磁碟標籤掛載；不要依賴固定的 /dev/sdX。

失敗四：重新安裝後核心依賴或驅動不匹配，導致服務間接失效

例如儲存相關的模組、網卡驅動、時間同步服務等，可能影響整體可用性。雖然系統能啟動，但業務不一定正常。

對策：重置後先完成基本健康檢查（網路、DNS、時間、磁碟掛載、系統服務狀態），再進入應用恢復。

失敗五：版本不兼容（應用/資料庫版本跳躍導致升級需求）

如果你把操作系統重裝時也選了不同的資料庫版本或運行環境，可能觸發資料遷移或相容性問題。資料能被讀到，但服務拒絕啟動或報錯。

對策：保持應用依賴版本與原環境一致，或在重裝前就做兼容性驗證（例如測試環境先跑一遍）。不要臨時把多個不確定因素混在同一次重裝裡。

第六章：一套「可重複」的操作節奏（降低心理負擔）

把流程寫成節奏，最大的好處是你在緊張時仍能做對事。建議你把下面節奏固化成 SOP：

• 準備：盤點資產、確認數據盤保留選項、備份配置、記錄掛載資訊
• 停止：停服務 → 檢查沒有寫入 → 產生最後狀態記錄
• 重置：鏡頭重置/重新安裝系統盤（只做系統範圍）
• 驗證：先讀數據盤 → 再掛載驗證 → 再權限檢查
• 恢復：恢復依賴與配置 → 啟動服務 → 功能回歸測試
• 確認：觀察一段時間（例如 30 分鐘到數小時）再進入穩態

你會發現真正耗時間的不是重裝本身，而是每次重裝都要「重新想一次」該做什麼。當你有 SOP，時間就能被壓縮，錯誤也會下降。

第七章：建議的工程化細節（讓未來更省心）

1. 讓掛載配置可追蹤

把 /etc/fstab、掛載腳本、以及磁碟標籤策略納入版本管理或至少納入文檔。你不需要做得很大，但要能追溯。下一次重裝就會像照著菜譜做，而不是憑印象操作。

2. 把關鍵配置從「系統盤」搬到「可控位置」

如果你的應用配置非常重要（例如多環境參數、密鑰管理策略），可以考慮讓配置可重建：例如使用環境變數注入、或使用集中式配置管理。這樣即使系統鏡頭重置，你仍能在新系統快速恢復。

3. 使用快照或備份策略形成保險

保留數據盤不等於永遠安全。建議對數據盤做定期快照，尤其是資料庫類型。如果雲平台支援一致性快照或可以配合停機/預處理的策略，效果會更好。

結語：重置是手術，不是災難

「香港雲伺服器系統鏡頭重置與保留數據盤重新安裝操作系統」這件事，本質上是一種運維手術：你切的是系統盤，保的是數據盤，並且用驗證與回退思維降低風險。只要你把重置前的盤點、選項確認、掛載策略、以及恢復節奏做扎實，重裝就不再是恐懼，而是可控的工程流程。

真正的差別在於：有人做重置時只看按鈕選了什麼；而更成熟的做法，是從資料邊界、掛載信任、配置可重建這三個角度建立完整心智。下次當你再次遇到系統混亂或環境污染時，你會更快、更穩、更少犯錯。