【LuckyWave 技術故事】電腦的房間快滿了！我和 AI 如何一起完成一場伺服器擴建工程

從 46GB 到 146GB，一次真實的 Linux 硬碟擴充經驗

2026 年 10 月 19 日，LuckyWave 遇到了一個問題。

一台替客戶 IDJ 提供服務的電腦，快要沒有空間了。

但這不是一般放在桌上的電腦，而是一台負責提供網站與系統服務的 Linux 伺服器。

你可以想像，這台伺服器就像一間每天都有人上班的辦公室。

裡面有很多重要的資料、程式和工作紀錄，每天都有新的東西需要存放。

原本這間辦公室有 46GB 的空間，可是已經使用了 95%。

如果用一個有 100 格的櫃子來比喻，其中 95 格都已經塞滿東西，只剩下 5 格可以放東西。

再繼續下去，可能連新的工作紀錄都放不進去。

我們必須替它擴建。

但問題來了。

這是一間正在營業的辦公室，我們不能隨便把牆壁拆掉，更不能讓裡面的資料消失。

第一章：明明買了更大的土地，房子卻沒有變大

我們使用的伺服器架設在 Proxmox VE 虛擬化平台上。

你可以把 Proxmox 想像成一棟管理許多房間的大樓。

每個房間都是一台獨立的虛擬電腦，而 IDJ 就住在其中一間。

當我們發現 IDJ 的空間快滿時，第一個想法很簡單：

「那就給它更大的硬碟吧！」

於是，我們先在 Proxmox 裡面，把虛擬硬碟從原本的 50GB 擴大到約 150GB。

照理說，空間應該變大了，對吧？

但當我們回到 Linux 裡面檢查，卻發現一件奇怪的事情。

房子外面的土地已經變大，裡面的房間卻還是只有 46GB。

為什麼？

因為 Linux 的磁碟管理就像蓋房子一樣，有好幾個不同的層次。

我們只是把土地買大，還沒有把圍牆往外推，也還沒有把房間真正擴建。

這才是整個挑戰真正開始的地方。

第二章：AI 幫我畫出房子的設計圖

以前遇到這種情況，我可能會上網搜尋很多教學文章。

有人說要修改磁碟分割區，有人說要使用 LVM，也有人說要執行 xfs_growfs。

每篇文章看起來都有道理。

可是，哪一篇才適合我的伺服器？

萬一照著別人的指令操作，卻把自己的資料弄壞了呢？

這一次，我選擇把伺服器的畫面與指令結果交給 AI 一起分析。

AI 沒有一開始就叫我執行擴充指令。

而是先請我確認伺服器實際的磁碟結構。

例如：

lsblk
df -hT

這兩個指令，就像是在檢查房子的設計圖。

lsblk 是看看整塊土地如何分配。

df -hT 則是看看每個房間有多大、使用了多少空間，以及採用什麼建築方式。

我們發現，這台 Linux 使用了兩個重要的技術：

• LVM：可以想像成能夠重新分配房間空間的管理員。
• XFS：可以想像成房間內真正可以使用的地板。

原來，想要讓房間變大，不能只增加硬碟容量。

還得讓每一層都知道：「現在有更多空間可以使用了。」

第三章：擴建工程，必須一關一關完成

經過檢查，我們把整個任務整理成四個步驟。

第一步：確認新土地已經出現

先確認 Proxmox 增加的磁碟容量，Linux 是否已經辨識。

就像建商說土地已經買好了，我們還是要親自確認地契與土地範圍。

第二步：把圍牆往外推

磁碟分割區原本只使用一部分空間。

現在硬碟已經變大，就需要讓分割區延伸到新增的範圍。

這個階段會涉及磁碟分割工具，例如 growpart。

但不能因為網路教學說可以使用，就直接複製執行。

必須先確認磁碟名稱、分割區編號，以及實際的系統配置。

第三步：通知空間管理員

分割區變大後，LVM 還不一定知道新增的空間能夠使用。

這時候就需要透過 pvresize 更新實體卷宗所能使用的容量，再透過 lvextend 擴大邏輯卷宗。

就像房子的圍牆已經往外移動，但管理員還沒把新增的空間分配給辦公室。

第四步：把房間的地板真正鋪好

最後，我們還需要讓 XFS 檔案系統使用新增的容量。

這時會用到：

xfs_growfs /

你可以把它想像成：

土地買好了，圍牆推開了，房間也分配好了。

最後只差把地板鋪到新的空間。

直到這一步完成，Linux 才能真正使用擴充後的容量。

這四個階段，看起來只是幾個 Linux 指令。

但每一個步驟，都必須建立在前一步已經確認正確的基礎上。

重要的是，這些是本次 LVM 與 XFS 環境的技術原理，不代表所有 Linux 伺服器都能直接照抄相同指令。

第四章：我最擔心的，不是指令，而是資料

整個過程中，我反覆問 AI：

「這樣可以嗎？」

「確定不會影響資料嗎？」

「需要先備份嗎？」

「這是一整行指令，還是要分開執行？」

因為我很清楚，這不是拿來練習的電腦。

它是一台正在替客戶工作的伺服器。

如果操作錯誤，損失可能不只是重新安裝系統的時間。

還可能影響客戶原本的服務。

所以這次我學到最重要的一件事：

工程師的專業，不是敢執行多少指令，而是知道每一道指令可能帶來什麼影響。

AI 可以幫忙分析，但實際執行之前，我仍然必須確認備份、理解風險，並檢查每一步的結果。

AI 並不能保證每個指令都百分之百安全。

它的價值，是幫我降低因為不了解系統而犯錯的機會。

第五章：房間終於變大了！

當所有擴充步驟完成後，我們再次查看 Linux 的磁碟容量。

這一次，結果終於改變了。

項目	擴充前	擴充後
根目錄容量	46GB	146GB
磁碟使用率	95%	約 30%
需要重新安裝系統	否	否
需要重新開機	—	否

原本快塞滿的房間，終於有了新的使用空間。

就像一間原本擠滿文件與設備的辦公室，突然多出了兩倍以上的額外活動空間。

更重要的是，我們不需要把整間辦公室搬走，也不需要重新蓋一棟房子。

我們是在原本的系統架構下，完成了這次擴建。

但我也明白，磁碟容量擴充成功只是驗收的一部分，仍然需要確認服務正常、資料可以存取，以及後續備份機制是否可靠。

第六章：真正被擴充的，不只是硬碟

這次工作結束後，我想了一件事情。

如果是在幾年前，遇到這個問題，我可能會選擇：

找其他更有經驗的工程師。

額外購買技術支援服務。

或者擔心風險太高，而暫時不敢動它。

但這一次不一樣。

我仍然不是一個精通所有 Linux 指令的專家。

可是，透過 AI 的協助，我能夠把一個原本看不懂的技術問題，拆成一個又一個可以理解、檢查與執行的小步驟。

遇到不懂的名詞，可以立即詢問。

看到不確定的結果，可以一起分析。

擔心操作風險，可以先研究原因。

每完成一步，就重新確認下一步該怎麼做。

這不是 AI 替我按下所有按鈕。

而是 AI 幫助我理解原本陌生的知識，讓我能親自完成這件事情。

我們擴充了 100GB 的磁碟容量，也擴充了我解決問題的能力。

第七章：LuckyWave 想做的，就是這樣的 IT 服務

這次 IDJ 的維護經驗，讓我更加確定 LuckyWave 未來想走的方向。

過去，客戶購買 IT 服務，常常是在購買工程師的時間。

一個問題要處理幾個小時？

需要多少工程師？

需要額外支付多少技術費用？

但 AI 正在改變技術工作的方式。

當工程師可以透過 AI，更快理解陌生系統、分析問題並規劃解決方案時，我們便有機會把更多時間投入真正重要的事情：

讓客戶的系統維持穩定。

在問題發生前發現風險。

減少不必要的停機。

持續改善系統效能與安全性。

對 LuckyWave 而言，AI 不是用來取代工程師的工具，而是讓工程師有能力服務更多系統、處理更多技術挑戰的夥伴。

我們希望客戶購買的，不只是有人幫忙修電腦或修改網站。

而是有人能夠持續守護他們的數位服務，並在技術不斷改變的環境中，找到更好的解決方法。

結語：原本不會的事情，現在有機會做到了

回頭看這次經驗，最讓我印象深刻的，不是 pvresize、lvextend 或 xfs_growfs 這些 Linux 指令。

而是過去遇到同樣的情況，我可能只能說：

「這個我不太會，需要找專家處理。」

現在，我可以先說：

「我們先確認問題，再研究怎麼安全地解決。」

這兩句話之間的差距，就是 AI 帶給我的改變。

當然，AI 並不是萬能的。正式環境仍然需要備份、權限控管、風險評估與完整驗收。

但至少，過去因為技術門檻而不敢跨出的那一步，現在有了新的可能。

真正厲害的，不是 AI 幫我們把硬碟變大，而是它讓我們有勇氣、有方法，也更有能力面對原本不熟悉的挑戰。

這就是 LuckyWave 在 IDJ 伺服器維護中，留下的一次真實技術紀錄。

LuckyWave｜讓技術不再只是少數人的專業，讓 AI 成為企業持續成長的力量。