GCP企業帳號開戶 谷歌雲VM硬碟空間不足？無需重啟直接在線擴容磁碟詳細步驟

第一章：問題為什麼總是發生

GCP企業帳號開戶 在雲端運行 VM，最容易被忽視的其實不是 CPU、不是網路，而是磁碟空間。你可能只是在某天發現監控告警、系統登入後看到「No space left on device」，或是應用開始報錯：寫入日誌失敗、臨時檔無法產生、資料庫無法擴展檔案。這些症狀看似都像應用問題，但根因往往是磁碟容量逼近上限。

更麻煩的是，很多人面對「磁碟已滿」會本能地選擇重啟或停機處理。然而在 GCP 上，磁碟擴容本身並不一定需要重啟；關鍵在於：你要先在雲端層面把磁碟容量調大，然後在作業系統內讓分區與檔案系統吃掉新增空間。做錯順序，或者沒有正確識別分區，就可能導致容量沒真正生效，甚至讓系統回到“看似擴了但實際仍滿”的狀態。

下面我們以一個典型情境為線索：你的谷歌雲 VM 的持久磁碟（Persistent Disk）容量不夠，並希望在不重啟的情況下完成在線擴容。文章會把每一步都拆清楚，讓你照做即可。

第二章：擴容前的準備與原則

2.1 先確認磁碟類型與檔案系統

GCP 的持久磁碟通常是附著到 VM 內的塊裝置（block device）。在作業系統內，你需要知道兩件事：

• 你的檔案系統是 ext4、xfs 還是其他（因為擴容指令不同）。
• 你磁碟上是怎樣分區的：只有一個分區嗎？還是有多個分區（例如 /、/var、/data）？

如果你不知道檔案系統和掛載點，很容易在擴容時只“擴了磁碟卻沒擴檔案系統”，結果空間仍然不足。

2.2 盡量不要急著操作，先做快照或檢查余量

理論上擴容是可逆性較低、但通常風險相對較小的操作（尤其是只向上擴大）。然而當磁碟已滿、系統狀態可能不穩定時，仍建議你在條件允許下先做快照（或至少確認近期沒有大量寫入造成不一致）。

此外，磁碟幾乎滿載時，擴容過程可能因為臨時檔/元資料不足而失敗。你可以先針對 /var/log、臨時目錄清理一些空間，讓操作工具有喘息。

第三章：雲端側先把磁碟容量調大

3.1 在 GCP 控制台或命令列調大 Persistent Disk

在線擴容的第一步是：在雲端把 Persistent Disk 的容量調大。這一步不會影響你正在跑的服務，但容量確實會變大，並在 VM 裝置層面反映出可用空間。

你可以透過控制台操作，也可以用 gcloud 命令。無論哪種方式，核心是同一件事：把磁碟（例如 100GB）改為更大的值（例如 200GB 或 300GB）。

操作完成後，等一小段時間讓雲端變更同步到 VM。通常數分鐘內即可；如果你剛改完就立刻在 VM 端操作，偶爾會遇到裝置層面尚未更新的情況。

3.2 選擇合理擴容幅度

不少人一次只加 5GB、10GB，結果很快又告警。你擴容不是為了“補洞”，而是為了讓系統穩定運行。建議至少加到你估算的可用週期（例如未來 3~6 個月）。若不確定，用指標估算每日增長量，再乘以保留月份。

第四章：在 VM 上辨識磁碟與分區狀態

4.1 SSH 進入 VM

登入 VM 後，先切到能執行磁碟相關命令的權限（通常是 root 或有 sudo 權限）。

4.2 先看目前已掛載與檔案系統型別

執行下列命令，掌握現況：

df -hT
lsblk -f
mount | head

重點看兩類資訊：

• df -hT：顯示各掛載點的容量、已用、可用，以及檔案系統類型。
• lsblk -f：顯示裝置（例如 /dev/sdb1）與其掛載點、檔案系統類型。

你要定位“你要擴容的那個掛載點”。例如你的 / 或 /var 是否是已滿的。

4.3 確認磁碟裝置名稱與大小是否已更新

接著確認新容量是否已經在作業系統的塊裝置層面可見：

lsblk
sudo fdisk -l

你關注：

• 哪個磁碟是你剛擴容的 Persistent Disk（可能是 /dev/sdb、/dev/sdc 之類）。
• 該磁碟的 SIZE 是否已變更。
• 分區（例如 /dev/sdb1）的大小是否跟著更新，或仍停留在舊值。

常見情況是：磁碟（整體裝置）大小已變，但分區仍是舊大小，這時就需要在系統內做分區擴展，接著再擴檔案系統。

第五章：在線擴展分區（核心是 growpart）

要把新增容量真正用到檔案系統上，你通常需要擴展分區。Linux 常用工具是 growpart（來自 cloud-guest-utils 套件），它會針對指定磁碟與分區號，把分區往後延伸。

5.1 安裝 growpart（若系統尚未包含）

不同發行版安裝方式略有差異。以 Debian/Ubuntu 為例：

sudo apt-get update
sudo apt-get install -y cloud-guest-utils

以 CentOS/RHEL 為例：

sudo yum install -y cloud-utils-growpart

如果你的系統無法使用上述包名，也可以先用：

which growpart

看是否已存在。

5.2 使用 growpart 擴展目標分區

假設你的磁碟是 /dev/sdb，目標分區是 1（即 /dev/sdb1），可以嘗試：

sudo growpart /dev/sdb 1

若你的目標分區不是 1，需要先從 lsblk 或 fdisk 判斷分區編號。執行後，再看分區大小是否已增加：

lsblk

你應該看到 /dev/sdb1 的 SIZE 已變大。

5.3 多分區或你掛載的是某個子分區時的判斷

如果你的掛載點不是根分區 /，而是例如 /data 對應 /dev/sdb2，那你就應該對 /dev/sdb2 進行 growpart。邏輯始終一致：擴展你要承載該掛載點的分區。

錯誤做法是：擴了 /dev/sdb1，但 /data 實際是 /dev/sdb2。這樣你看起來擴容過，但實際掛載點仍滿。

第六章：擴展檔案系統以吃掉新空間

GCP企業帳號開戶 分區擴好了，下一步是讓檔案系統（ext4 或 xfs）能使用新增空間。這一步取決於檔案系統類型。

6.1 ext4：使用 resize2fs

如果 df -hT 顯示你的掛載點是 ext4，使用：

sudo resize2fs /dev/sdb1

若你不確定要對哪個裝置執行，可以先用 lsblk 找到該掛載點對應的分區。

執行後，再驗證：

df -hT

你應該看到相應掛載點的 Available 明顯增加。

6.2 xfs：使用 xfs_growfs（建議基於掛載點而非裝置）

如果你的檔案系統是 xfs，通常直接對掛載點擴展：

sudo xfs_growfs /data

GCP企業帳號開戶 其中 /data 是你的掛載點。執行完成後再 df 驗證。

需要注意：xfs_growfs 通常不吃“分區裝置路徑”，而是吃掛載點路徑，否則容易產生參數錯誤。

6.3 系統仍顯示空間不足怎麼辦

常見原因有三類：

• 你只擴了雲端磁碟，未擴分區：分區仍舊大小，檔案系統也沒變。
• 你擴了分區，但擴容指令用錯檔案系統或用錯裝置：例如對 /dev/sdb1 執行了 resize2fs，但掛載點實際是 /dev/sdb2。
• GCP企業帳號開戶 擴容工具未真正生效，或設備尚未同步：這時需要重查 lsblk 的 SIZE，必要時等待幾分鐘再重試。

第七章：完整示例流程（可直接套用）

下面用一個典型例子把步驟串起來。假設你的 VM 新增容量從 100GB 調到 300GB，你的根分區 / 是 ext4，且對應裝置是 /dev/sdb1。

7.1 在 VM 上檢查

df -hT
lsblk -f

你看到 / 掛載在 ext4，分區可能是 /dev/sdb1。

7.2 檢查磁碟大小是否已變更

lsblk

確認 /dev/sdb 的 SIZE 已到 300GB 左右。

7.3 擴展分區

sudo growpart /dev/sdb 1

再驗證：

lsblk

應看到 /dev/sdb1 的 SIZE 變大。

7.4 擴展檔案系統

sudo resize2fs /dev/sdb1

最後驗證容量：

df -hT

此時 / 的 Available 應增加並不再告警。

第八章：驗證、監控與後續建議

8.1 用多種方式驗證“真正可用”

GCP企業帳號開戶 單看 df 很直觀，但為避免誤判，建議至少再做一次：

• 確認掛載點可寫：在掛載點下建立一個小檔（或寫一小段），避免“只顯示空間變大但仍有配額/磁碟配額”的情況。
• 查看應用日志：如果曾報“寫入失敗”，擴容後應不再出現同類錯誤。

8.2 把告警閾值調得更合理

如果你是因為硬碟滿才擴容，代表告警可能太晚觸發。建議把告警提前，常見做法是：

• 70%~80%：提示與建議清理策略
• 85%：開始自動化檢查（例如清理日誌、清除臨時檔、擴容工單）
• 90%~95%：強提醒並準備緊急擴容或擴展流程

8.3 擴容不是萬能，仍要解決“增長來源”

擴容只是把容量問題延後，如果日誌爆長、快取不會清理、或者某個任務卡住持續寫入，就算擴到 1TB 仍可能很快滿。建議你事後回頭查：

• 最近最大的目錄變化：du -sh /var/*（視需求調整）
• 日誌是否有無限制輪轉：logrotate 設定是否合理
• 資料庫是否有自動成長且未設限：例如 WAL、index、temp space

第九章：常見錯誤排查（你可能會遇到）

9.1 growpart 報錯：分區號或磁碟裝置錯誤

GCP企業帳號開戶 這通常是你用錯了 /dev/sdX 或分區號。解法是回到 lsblk、fdisk -l 找到精確裝置名稱。尤其是多磁碟環境，/dev/sdb 不一定永遠是你以為的那塊。

9.2 resize2fs 提示文件系統大小不匹配或無法擴展

這多半是你沒有先擴分區，或分區仍未反映到檔案系統。先：

• 確認分區大小：lsblk 看 /dev/sdb1 是否已增大。
• 確認檔案系統類型：df -hT 檢查是否仍是 ext4。

必要時等待裝置同步後重試。

9.3 xfs_growfs 顯示已增但 df 還是滿

常見原因是你傳入了錯誤掛載點，或者實際掛載點不是你以為的那個目錄。回到 df -hT 找到目標掛載點，對應地執行 xfs_growfs。

9.4 擴容後應用還在報磁碟寫入失敗

有時並不是文件系統仍滿，而是：

• 應用還保留了舊的暫存檔路徑或錯誤狀態，需要重啟服務。
• 應用有自己的磁碟配額或限制（例如某些容器的 ephemeral storage 限額、或某些程序有目標路徑不對）。
• 磁碟已經滿載導致應用內部錯誤尚未清理。

擴容完成後，再觀察應用錯誤是否消失；若仍持續，才考慮是否需要重啟服務（但不一定需要重啟 VM）。

第十章：結論——不重啟也能完成在線擴容

谷歌雲 VM 硬碟空間不足，確實會影響服務，但你不必急著重啟整台機器。只要遵循正確順序：先在雲端擴大 Persistent Disk，再在 VM 內擴展分區（通常用 growpart），最後根據檔案系統類型擴展檔案系統（ext4 用 resize2fs，xfs 用 xfs_growfs），就能在多數情況下完成真正的在線擴容。

GCP企業帳號開戶 把驗證環節也納入流程：用 df -hT、lsblk 確認容量與掛載點一致；同時檢查應用是否恢復正常寫入。當你把這套流程變成“標準操作”，以後磁碟告警就不再是恐慌事件，而只是可控的維運節點。

如果你願意，我也可以根據你 VM 的實際輸出（df -hT、lsblk -f、以及已擴容後磁碟的大小）幫你判斷應該對哪個分區執行 growpart、以及該用哪個擴容指令。這樣你就能把每一步做得更精準、更安心。