在 Ubuntu 上更換 mdadm 陣列中的故障磁碟機

本文中的資訊是基於 Ubuntu 18.04 及其儲存庫中包含的 mdadm 版本；在撰寫本文時，版本為 v4.1-rc1。對於其他版本來說它可能有效，也可能無效。

最近，我的家用檔案伺服器突然出現磁碟機故障，該伺服器由 mdadm RAID-6 陣列中的九個磁碟機組成。這總是令人害怕，但幸運的是，我能夠迅速找到第二天就交付的替換驅動器，這樣我就可以開始重建。

我承認，當我最初設定文件伺服器時，我有點太吝嗇了；其中只有兩個驅動器是真正的 NAS 驅動器（Seagate IronWolf），其餘的則是桌上型電腦驅動器（Seagate Barracuda）。毫不奇怪，它是已經報廢的桌上型電腦硬碟之一（儘管已經使用了近三年）。它已經徹底死了；將其移至桌面 USB 外殼後，我聽到的只是令人不安的咔噠聲，Ubuntu 20.04 和 Windows 10 都無法檢測到它。

哦，好吧，開始更換部件（是的，我買的新驅動器是 IronWolf，吸取了教訓）——在運行的陣列中丟失驅動器固然可怕，但如果您不知道更換它的正確程序，那就更可怕了。這不是我第一次更換 mdadm 陣列中的故障驅動器，但幸運的是，這種情況很少見，所以我通常只需查找正確的命令。這次我決定編寫自己的小指南以供日後參考。

因此，首先，當您從 mdadm 收到可怕的故障事件電子郵件時，您需要確定哪個磁碟機發生了故障。當然，它會告訴您設備名稱（在我的情況下是 /dev/sdf），但可能不清楚它實際上是哪個實體驅動器，因為這些名稱在機器啟動時可能會發生變化。

如果您甚至不確定哪個裝置名稱出現了故障，您可以使用以下命令來查找（將 /dev/md0 替換為您的 RAID 裝置）：

如上所述，在我的情況下它是 /dev/sdf，所以讓我們繼續。

然後，您可以嘗試透過發出以下命令來尋找故障磁碟機的序號：

（如果找不到smartctl，則需要在Ubuntu上安裝smartmontools套件）

然後可以將序號與磁碟機實體標籤上的序號進行比較，以確定哪個磁碟機發生了故障。

但這次，我就沒那麼幸運了。該驅動器已完全損壞，甚至拒絕提供 SMART 或其他數據，包括序號。

由於我可以物理訪問伺服器（我想，如果您要自己更換實體驅動器，那麼您確實需要這樣做 ;-)），並且磁碟出現故障時伺服器實際上正在運行（並且由於 RAID-6 冗餘而繼續正常運行），我採用了非常原始但實際上非常有效和明顯的方法，即簡單地將大文件複製到伺服器並觀察哪個 HDD 燈沒有閃爍。幾秒鐘之內我就確定了罪魁禍首。

現在，在拔出實體磁碟機之前，最好透過發出此命令（根據需要將裝置名稱替換為您自己的裝置名稱）正式通知 mdadm 此意圖：

成功後，mdadm 將回覆一條訊息，表明它「熱刪除」了驅動器，顯然是因為虛擬 raid 設備當時實際上正在運行。

如果它失敗並出現類似於「裝置或資源繁忙」的錯誤訊息，則可能是 mdadm 實際上並未將磁碟機註冊為已完全失敗。為了使其執行此操作，請發出此命令（再次記住根據需要用您自己的名稱替換設備名稱）：

之後，您應該能夠使用上一個命令從陣列中刪除該設備。

現在是時候真正更換驅動器了。如果您真的、真的 -真的- 確定您的機器和控制器支援熱插拔，那麼您可以在不關閉機器的情況下執行此操作。這將是在真實的、合適的伺服器硬體上運行關鍵生產系統的方法，您確實知道這些硬體可以處理它。不過，我的家庭文件伺服器是基於消費級桌上型主機板，在 PCIe 插槽中配備了幾個半無名 SATA 控制器，以提供更多 SATA 連接埠。

雖然 SATA 通常應該支援熱插拔，但我不想在這種設定中冒任何風險，因此我選擇在更換驅動器時關閉機器。

在執行此操作之前，最好先註解掉 /etc/fstab 檔案中的 raid 設備，以便 Ubuntu 不會在下次啟動時嘗試自動掛載它，因為它可能會因 RAID 陣列降級而掛起並強制您進入復原模式。如果是桌面系統，這可能不是什麼大問題，但我在沒有連接顯示器或鍵盤的情況下運行該伺服器，所以這會有點麻煩。

啟動安裝了新磁碟機的機器後，使用 lsblk 或其他方法來識別它。如果您沒有更改任何其他內容，它可能會（但不一定）與您更換的驅動器同名。就我而言確實如此，因此新的也被稱為 /dev/sdf。

由於我的陣列是基於分區而不是實體設備，因此我需要將分區表從工作驅動器複製到新驅動器，以確保它們完全相同。如果您在實體設備上執行數組，則可以跳過此步驟。

為此，我使用 sgdisk，將分割表從 /dev/sdc 複製到 /dev/sdf。確保替換設備名稱以符合您自己的名稱。

注意這裡的順序：首先列出“到”驅動器！這對我來說有點違反直覺，但只要確保你做對了，就不會在陣列中出現另一個驅動器故障;-)

然後，為了避免 UUID 衝突，為新磁碟機產生新的 UUID：

現在終於到了將新驅動器添加到陣列並開始重建的時候了！ （好吧，這實際上不是一個聚會，它實際上是一個相當緩慢和令人不安的過程，因為你真的、真的不想此時再出現另一個驅動器故障。不過，啤酒可能會有幫助）

無論如何，要將新磁碟機新增至陣列，請發出此命令（再次確保根據需要用您自己的名稱取代裝置名稱）：

如果一切順利，驅動器將會順利加入陣列。我相信它實際上是預設為“熱備用”，但由於該陣列缺少一個磁碟（發生故障的磁碟），因此它立即投入使用並開始重建過程。

你可以像這樣關注它：

這可能需要一段時間；在我的低階伺服器上（請注意，主要基於消費級硬體和桌上型電腦硬碟），它能夠達到低於 100 MB/秒的速度。請記住這是 RAID-6，因此重建涉及大量奇偶校驗計算； RAID-10 的速度會更快。這台特殊的機器配備了 AMD A10 9700E 四核心 CPU（「E」表示它是低頻節能型號，即不是超級快），只是為了讓您了解可以期待什麼。由於我的設定中有 9 個 8 TB 硬碟，因此完全重建僅花了 24 個多小時。

在重建期間，您可以將檔案系統掛載在陣列上並像平常一樣使用它（如果您願意的話），但我更願意將其留在重建過程中直到完成。請記住，如果一個驅動器出現故障，另一個驅動器可能很快就會出現故障，因此您希望盡快完成重建，因為您真的不希望在此期間另一個驅動器出現故障。因此，不要讓其他不必要的 IO 負擔加重。

完成後，將其添加回您的 /etc/fstab 文件，重新啟動並享受您的文件 :-)