AWS企業帳號認證 AWS EC2 磁碟空間滿了怎麼擴容

第一章：先確認「滿了」的是哪一塊

當 EC2 出現磁碟空間滿了，很多人第一反應是「直接加硬碟」。但在 AWS 上，EC2 的「磁碟」其實由多個層次組成：EBS 卷（或 NVMe 裝置）、分區、檔案系統（ext4/xfs 等）、以及應用層產生的檔案（log、暫存、容器層）。真正要擴的是哪一層，決定了你該怎麼動。

AWS企業帳號認證 我建議你先做三件事：確認告警內容、確認作業系統看到的掛載點、確認哪個掛載點百分比最高。因為最常見的狀況是：根分區 / 滿了，但你以為只有資料盤；或你看到 EBS 卷滿，但實際上是某個掛載點（例如 /var 或 /var/lib/docker）吃掉所有空間。

1. 檢查磁碟使用率與掛載點

登入機器後，先看掛載點的使用率：

df -h

重點看：

• 哪個路徑（/、/var、/home、/data…）最滿
• 使用率是多少（例如 95%、99%）
• 是哪種檔案系統（你也能順便確認 ext4 或 xfs）

如果你看到例如：

• / 使用率 99%
• /data 使用率 20%

那代表你要處理的是根卷的分區，而不是資料卷。

2. 找出「該擴哪張 EBS 卷」

接著對照分區與實體裝置。用：

lsblk

你會看到裝置（如 /dev/nvme0n1）以及上面有哪些分區（nvme0n1p1、p2…）。

再用：

df -hT

AWS企業帳號認證 它會顯示掛載點對應的檔案系統種類，方便你判斷接下來擴展時該用哪種工具。

3. 先判斷是「真的沒空間」還是「寫不進去」

磁碟滿不只是剩餘空間低，還會影響檔案系統的寫入行為。你可以留意應用錯誤訊息是否包含：

• no space left on device
• ENOSPC
• read-only file system

如果檔案系統已被掛成唯讀，你即使擴容不做正確的檔案系統調整，也可能仍然無法寫入。因此擴容後務必驗證。

第二章：找出佔用來源，避免擴了還滿

擴容可以立刻止血，但如果你不處理「為什麼會滿」，下一次擴容只是延後崩潰時間。更重要的是：有些佔用來源其實可以在不擴容的情況下釋放 30%~80% 的空間。

1. 用目標導向的方式找最大目錄

不要一上來就掃整台硬碟浪費時間。你可以針對最滿的掛載點（例如 /var 或 /）做分析。

常用做法：

sudo du -xhd1 /var 2>/dev/null

如果是根分區 /：

sudo du -xhd1 / 2>/dev/null

參數解讀：

• -x：只留在同一檔案系統，避免掃到掛載點外
• -h：人類可讀
• -d1：只看第一層目錄

你會很快看到例如 /var/log、/var/lib/docker、/var/cache、/tmp 等，哪一個最大。

2. 日誌（log）通常是第一嫌疑

log 會越堆越多，尤其是沒有輪替（logrotate）或應用輸出異常時。

你可以先看 log 檔案大小：

sudo du -sh /var/log/* 2>/dev/null | sort -h

常見解法：

• 停止或重啟服務（若 log 爆量要先處理元凶）
• 刪除過期 log 或壓縮後的舊檔
• 確保 logrotate 正常

但注意：不要只刪檔案不重啟服務，某些服務仍會持有已刪除的檔案描述符，磁碟空間看似還是滿。你通常要配合重啟或讓服務重新打開 log 檔。

3. Docker/容器常把你「誤以為沒有在用」

如果你在 EC2 上跑容器，磁碟常被 image、container、volume、build cache 吃光。你可以檢查：

docker system df

AWS企業帳號認證 常見清理（需謹慎，避免刪掉你還在用的映像/volume）：

• 清理未使用的映像：docker image prune
• 清理未使用的資源：docker system prune
• 針對特定用法保留 volume

實務上，很多團隊會建立一個排程清理機制，並把磁碟使用率與容器層監控一起做告警。

4. 快取與臨時檔（cache/tmp）也會慢慢爬上來

AWS企業帳號認證 像是 apt/yum 快取、pip/wget 的下載快取、應用的臨時目錄（/tmp）都可能不受控。

例如 Debian/Ubuntu 常見：

AWS企業帳號認證 sudo du -sh /var/cache/apt 2>/dev/null

必要時可以清理：

sudo apt-get clean

但清理前要確保你不會影響正在進行的更新或安裝流程。

第三章：AWS 擴容 EBS 的正確流程（止血版）

當你已確認是 EBS 裝置對應的分區滿了，或你已嘗試清理仍很快會回到滿狀態，就進入擴容流程。擴容分兩段：AWS 端調整 EBS 卷大小、以及 OS 端擴展分區與檔案系統。

注意：只有調整 EBS 卷大小不等於磁碟立刻變大。OS 還要把檔案系統擴展到新空間。

1. 在 AWS 主控台找到對應的 EBS 卷

進入 AWS Console：

• EC2 > Instances > 找到你的實例
• 查看 Block devices（區塊裝置）

你需要知道：是 根裝置（通常是 /）還是某個 附加資料卷。

對於根卷，調整大小可能會涉及快照策略與重啟風險（但 EBS 調整通常可線上發生，是否需重啟要看分區/檔案系統處理方式與你使用的系統）。

2. 修改 Volume size

在 EBS 卷頁面選擇 Modify volume，將 Size 調大到你需要的值（例如從 20GiB 改 40GiB）。

常見規劃建議：

• 如果你目前接近 100%，至少加到能容納 2~3 倍你目前的增長速度
• 不要只加 1GiB 這種「差一點就滿」的量
• 把下一次擴容成本算進去：時間、風險、測試

修改後狀態通常會顯示為 optimizing/available。等它完成。

AWS企業帳號認證 3. OS 端先確認磁碟新容量是否被辨識

AWS企業帳號認證 回到 EC2 端執行：

lsblk

你可能會看到裝置容量變大了，但分區大小未必立刻跟著變。通常 EBS 變大後，裝置會顯示更大的 size，但 partition 還是原本的區間。

AWS企業帳號認證 接著你要擴展分區，然後擴展檔案系統。

第四章：擴展分區與檔案系統（不同檔案系統對應不同指令）

這一章是關鍵。因為只做 AWS 端改大小，你的檔案系統仍然只認得原本分區大小。真正可用空間增加，必須把分區或檔案系統擴展到新容量。

1. 常見路徑 A：單一分區（例如 / 在一個 ext4 分區）

如果你的根卷是單一分區，且使用的是 ext4 或 xfs，流程會相對順。

先確認：

df -hT

如果檔案系統是 ext4，常見擴展方法：

sudo resize2fs /dev/nvme0n1p1

注意：把 /dev/nvme0n1p1 換成你的實際分區名稱。裝置名需要從 lsblk 或 df 對應。

如果是 xfs，常見擴展方法：

sudo xfs_growfs /

xfs 通常以掛載點作為參數，且可以在線擴展。

2. 常見路徑 B：需要先擴分區（尤其是 partition 表還沒跟上）

有些情況下，分區仍停留在原大小。這時你需要先擴分區到佔滿整個裝置。

你可以使用 growpart（許多系統預先可用，或可先安裝）。例如：

sudo growpart /dev/nvme0n1 1

AWS企業帳號認證 這裡的 1 是分區號，需依你的實際情況調整。然後再用 ext4/xfs 的方式擴檔案系統。

如果你用的是 GPT/MBR 與不同 NVMe 命名規則，分區號與裝置名稱可能不同。務必以 lsblk 結果為準。

3. 處理 LVM 的額外步驟（稍複雜但常見）

有些企業環境會把根分區或資料分區放在 LVM。這時你要走多一步：先擴 PV，再擴 LV，再擴檔案系統。

你可先檢查有沒有 LVM：

sudo pvs

sudo lvs

若存在，流程常見如下（只提供方向，具體名稱以你實例為準）：

• 擴展 PV：sudo pvresize ...
• 擴展 LV：sudo lvextend -l +100%FREE ...
• 擴展檔案系統：ext4 用 resize2fs，xfs 用 xfs_growfs

LVM 的細節容易因環境命名不同而出錯，所以在動手前我會建議你先把磁碟與分區資訊完整記錄（lsblk、pvs/lvs、df -hT）。

第五章：驗證與回歸測試，確認真的「能用、能寫」

擴容後，最常見的失敗不是指令寫錯，而是你以為成功，但實際只是裝置變大，檔案系統仍舊沒擴展，或應用還在原本的失敗狀態。

1. 先驗證 df 是否反映新容量

回到最初的掛載點，執行：

df -h

確認：

• 最滿的掛載點使用率是否下降（例如從 99% 變到 30%~70%）
• 容量數值有沒有成長

2. 檢查檔案系統一致性

對於 ext4，你可以考慮檢查（視需求而定）。但不要在你不確定狀態時隨意破壞性操作。大多數情況擴展工具本身會做基本處理。

重要的是：先讓應用寫入正常運作，比做過多檢查更直接。

3. 驗證應用層：日誌、臨時檔與讀寫權限

如果你原本看到應用因 ENOSPC 失敗，擴容後可以做簡單驗證：

• AWS企業帳號認證 觀察服務是否恢復
• 產生一點新 log 看 log 是否能寫入
• 確認 /var/tmp 或應用暫存目錄能否寫入

這一步很「人類」，但也很實際：因為很多問題是應用策略導致，例如程式寫 log 失敗後進入重試循環，磁碟空間剛擴大但程式仍可能處於不正常狀態。

第六章：避免再次發生的設計：告警、治理與容量規劃

擴容只是解決當下。真正的勝利是讓你下次不需要半夜擴容。

1. 告警要針對「掛載點」，不是只看 EBS 卷

AWS CloudWatch 告警常見是看磁碟使用率指標，但你需要確保是針對正確的掛載點。因為 EBS 卷可能有多個分區，或應用實際寫入的是特定目錄。

最佳做法是：

• 對 /var/log、/var/lib/docker、/tmp 這類常爆點做監控
• 設定告警閾值，例如 80% 提醒、90% 進入行動

2. 設置自動輪替與保留策略

logrotate 不只是「有就好」，要確保它真的跑起來。你可以確認：

• 輪替頻率
• 保留天數/保留份數
• 壓縮策略

此外，最好讓應用把日誌輸出到可控的方案（例如統一的 log 管道、或集中式收集），避免單機無限制增長。

3. 容器/快取建立「可清理」的規則

如果你使用 Docker，建議建立規則：

• 定期清理未使用映像與 build cache
• 避免把大檔寫進可釋放空間以外的位置
• volume 設定明確的容量管理

關鍵不是清得多，而是清得對、清完後服務不出事。

4. 容量規劃：用增長曲線而不是「現在夠就好」

你可以回顧過去 2~4 週的磁碟使用率變化，估計每日或每週的增長量，再乘上你允許的擴容週期。很多時候，磁碟增長是可預測的，例如 log 與交易量線性或接近線性。

只要你把規劃做成一個簡單公式：預估增長量 + 安全緩衝，下一次擴容就會變成計畫內工作，而不是事件處理。

第七章：常見坑與排錯思路

擴容時真正讓人卡住的，往往是「你以為成功但其實沒成功」或「系統拒絕擴展」。下面列幾個我見過最常出現的坑。

坑 1：df 顯示容量沒變

最常見原因：

• 只改了 EBS 卷大小，沒有擴分區或沒有擴檔案系統
• 擴的不是正確的分區（裝置名稱/分區號對錯）

排查方式：

• AWS企業帳號認證 重新看 lsblk：分區 size 是否變了
• 看 df -hT：檔案系統容量是否更新

坑 2：擴完還是 read-only 或寫不進去

原因可能是原本檔案系統因滿盤進入保護狀態。你需要先確保檔案系統擴展完成，並檢查服務是否能正常寫入。

不要在不明狀態下亂重啟或強行修復，先看錯誤訊息（dmesg、system logs）。

坑 3：LVM 沒擴對，導致容量「看起來變多但用不到」

LVM 的世界裡，PV/LV/檔案系統要同步擴。你只做其中一層，剩下兩層不變，就會出現「EBS 變大了，但分區還是老樣子」。

排查：對照 pvs/lvs 與 df。

坑 4：清理動了不該動的資源

例如清了 Docker image prune 把服務需要的映像刪掉，或刪了還在用的臨時檔導致服務異常。這類風險通常能透過「只清理未使用資源、或先確認服務來源映像」降低。

如果你要做清理，最好在維護窗口或至少先備份重要配置。

第八章：一個實務可用的「操作清單」

AWS企業帳號認證 把前面的內容濃縮成行動清單，你可以在事故當下照著做，不會迷路。

Step 1：確認是哪個掛載點滿

df -h df -hT

記錄滿的路徑與百分比。

Step 2：找出最大佔用來源

sudo du -xhd1 /var 2>/dev/null 或針對 /

優先處理 log、docker、cache、tmp。

Step 3：判斷是否還需要擴容

如果清理能讓空間降到安全範圍，先止血並修治理；若預期很快滿，直接進行擴容。

Step 4：AWS 端把對應 EBS 卷 Size 增大

修改 Volume size，等狀態完成。

Step 5：OS 端擴分區與檔案系統

使用 lsblk 對照分區與檔案系統。

• ext4：resize2fs
• xfs：xfs_growfs（掛載點）
• 需分區擴展：先 growpart
• LVM：pvresize / lvextend / 再擴檔案系統

Step 6：驗證與確認可寫入

df -h 看容量是否反映 觀察應用 log 是否恢復寫入

Step 7：補上告警與輪替，避免再次發生

告警針對掛載點、設定保留策略、容器清理規則、容量規劃。

結語：擴容不是唯一答案，但要做得乾淨

EC2 磁碟空間滿了的處理，最重要的是把問題拆成三段：確定滿的是哪裡、找出為什麼滿、再決定是否擴容。擴容本身並不神秘，真正難的是判斷正確的層次，以及擴完後驗證與治理。

當你能做到：先用 df/lsblk 找到目標掛載點與檔案系統，再用 du 快速定位主要佔用，最後在 AWS 和 OS 端完整擴展並驗證可寫入，你就能把「磁碟滿了」從事故變成可控流程。下一次告警響起時，你不必慌，也不會只會做同一件事。