Mengganti Drive yang Gagal dalam Array mdadm di Ubuntu
Diterbitkan: 15 Februari 2025 pukul 22.02.21 UTC
Terakhir diperbarui: 12 Januari 2026 pukul 08.49.55 UTC
Jika Anda mengalami situasi yang mengerikan yaitu kerusakan hard drive pada susunan RAID mdadm, artikel ini menjelaskan cara menggantinya dengan benar pada sistem Ubuntu.
Replacing a Failed Drive in an mdadm Array on Ubuntu
Informasi dalam posting ini didasarkan pada Ubuntu 18.04 dan versi mdadm yang disertakan dalam repositorinya; pada saat penulisan, versinya adalah v4.1-rc1. Informasi ini mungkin berlaku atau mungkin tidak berlaku untuk versi lain.
Baru-baru ini saya mengalami kerusakan hard drive mendadak di server file rumahan saya, yang terdiri dari sembilan hard drive dalam susunan RAID-6 mdadm. Itu selalu menakutkan, tetapi untungnya saya dapat dengan cepat mendapatkan hard drive pengganti yang sudah dikirimkan keesokan harinya sehingga saya dapat memulai proses pembangunan ulang.
Saya akui, saya agak terlalu hemat ketika pertama kali menyiapkan server file; hanya dua drive yang merupakan drive NAS asli (Seagate IronWolf), sedangkan sisanya adalah drive desktop (Seagate Barracuda). Tidak mengherankan, salah satu drive desktop itulah yang rusak (setelah hampir tiga tahun digunakan). Drive tersebut benar-benar mati; setelah dipindahkan ke enclosure USB desktop, yang saya dapatkan hanyalah suara klik yang mengkhawatirkan dan baik Ubuntu 20.04 maupun Windows 10 tidak dapat mendeteksinya.
Baiklah, mari kita lanjutkan ke bagian pengganti (dan ya, hard drive baru yang saya beli adalah IronWolf, pelajaran berharga) - meskipun kehilangan hard drive dalam array yang sedang berjalan itu menakutkan, akan lebih menakutkan lagi jika Anda tidak mengetahui prosedur yang benar untuk menggantinya. Ini bukan pertama kalinya saya harus mengganti hard drive yang rusak dalam array mdadm, tetapi untungnya hal itu sangat jarang terjadi sehingga saya biasanya hanya perlu mencari perintah yang tepat. Kali ini saya memutuskan untuk membuat panduan kecil saya sendiri untuk referensi di masa mendatang.
Jadi, pertama-tama, ketika Anda menerima email pemberitahuan kegagalan yang ditakuti dari mdadm, Anda perlu mengidentifikasi drive mana yang mengalami kegagalan. Tentu, email tersebut akan memberi tahu Anda nama perangkat (dalam kasus saya /dev/sdf), tetapi mungkin tidak jelas drive fisik mana yang sebenarnya karena nama-nama tersebut dapat berubah saat mesin dihidupkan.
Jika Anda bahkan tidak yakin perangkat mana yang mengalami kegagalan, Anda dapat menggunakan perintah berikut untuk mengetahuinya (ganti /dev/md0 dengan perangkat RAID Anda):
Seperti yang disebutkan, dalam kasus saya itu adalah /dev/sdf, jadi mari kita lanjutkan dengan itu.
Kemudian, Anda dapat mencoba menemukan nomor seri drive yang rusak dengan menjalankan perintah ini:
(Jika smartctl tidak ditemukan, Anda perlu menginstal paket smartmontools di Ubuntu)
Nomor seri tersebut kemudian dapat dibandingkan dengan nomor seri pada label fisik di drive untuk mengetahui drive mana yang mengalami kerusakan.
Namun kali ini, saya kurang beruntung. Hard drive tersebut benar-benar mati dan bahkan menolak untuk menampilkan data SMART atau data lainnya, termasuk nomor seri.
Karena saya memiliki akses fisik ke server (yang sangat Anda butuhkan jika Anda akan mengganti hard drive fisik sendiri, saya kira ;-)) dan server sebenarnya sedang berjalan ketika disk rusak (dan terus berjalan dengan baik berkat redundansi RAID-6), saya menggunakan metode yang sangat primitif, tetapi sebenarnya sangat efektif dan jelas, yaitu dengan hanya menyalin file besar ke server dan mengamati lampu HDD mana yang tidak berkedip. Dalam beberapa detik saya telah mengidentifikasi penyebabnya.
Nah, sebelum mencabut drive fisik, ada baiknya untuk secara resmi memberi tahu mdadm tentang niat ini, dengan mengeluarkan perintah ini (ganti nama perangkat dengan nama Anda sendiri sesuai kebutuhan):
Jika berhasil, mdadm akan membalas dengan pesan yang menyatakan bahwa ia telah "melepas drive saat sedang berjalan", tampaknya karena perangkat RAID virtual tersebut sebenarnya sedang berjalan pada saat itu.
Jika gagal dengan pesan kesalahan yang mirip dengan "perangkat atau sumber daya sedang sibuk", mungkin mdadm sebenarnya belum mendaftarkan drive tersebut sebagai drive yang benar-benar gagal. Untuk membuatnya terdaftar, jalankan perintah ini (sekali lagi, ingat untuk mengganti nama perangkat dengan nama perangkat Anda sendiri sesuai kebutuhan):
Setelah itu, Anda seharusnya dapat menghapus perangkat dari array dengan perintah sebelumnya.
Sekarang saatnya untuk benar-benar mengganti hard drive. Jika Anda benar-benar yakin bahwa mesin dan kontroler Anda mendukung hot swapping, Anda dapat melakukannya tanpa mematikan mesin. Itu adalah cara yang tepat untuk sistem produksi kritis yang berjalan pada perangkat keras server yang sebenarnya dan Anda tahu pasti mampu menanganinya. Namun, server file rumahan saya berbasis pada motherboard desktop kelas konsumen dengan beberapa kontroler SATA semi-noname di slot PCIe untuk menyediakan lebih banyak port SATA.
Meskipun SATA umumnya mendukung hot swapping, saya tidak mau mengambil risiko apa pun dalam pengaturan ini, jadi saya memilih untuk mematikan mesin saat mengganti drive.
Sebelum melakukan itu, ada baiknya untuk menonaktifkan perangkat RAID di file /etc/fstab agar Ubuntu tidak mencoba memasangnya secara otomatis pada boot berikutnya, karena hal itu dapat menyebabkan sistem macet dan memaksa Anda masuk ke mode pemulihan karena array RAID yang rusak. Itu mungkin bukan masalah besar jika sistemnya desktop, tetapi saya menjalankan server ini tanpa monitor atau keyboard terpasang, jadi ini akan sedikit merepotkan.
Setelah menghidupkan komputer dengan hard drive baru yang terpasang, gunakan perintah lsblk atau cara lain untuk mengidentifikasinya. Jika Anda tidak mengubah apa pun, kemungkinan besar (tetapi tidak selalu) namanya akan sama dengan hard drive yang Anda ganti. Dalam kasus saya, memang demikian, jadi hard drive baru tersebut juga bernama /dev/sdf.
Karena array saya berbasis partisi dan bukan perangkat fisik, saya perlu menyalin tabel partisi dari drive yang berfungsi ke drive baru untuk memastikan keduanya persis sama. Jika Anda menjalankan array Anda pada perangkat fisik, Anda dapat melewati langkah ini.
Saya menggunakan sgdisk untuk tujuan ini, menyalin tabel partisi dari /dev/sdc ke /dev/sdf. Pastikan untuk mengganti nama perangkat agar sesuai dengan milik Anda.
Perhatikan urutannya di sini: Anda mencantumkan drive "tujuan" terlebih dahulu! Ini agak berlawanan dengan intuisi saya, tetapi pastikan Anda melakukannya dengan benar agar tidak terjadi kegagalan drive lain di array ;-)
Kemudian, untuk menghindari konflik UUID, buat UUID baru untuk drive baru:
Dan akhirnya tiba saatnya untuk menambahkan drive baru ke array dan memulai proses pembangunan ulang! (Oke, ini sebenarnya bukan pesta, ini adalah proses yang cukup lambat dan menegangkan karena Anda benar-benar tidak ingin drive lain gagal saat ini. Bir mungkin bisa membantu.)
Baiklah, untuk menambahkan drive baru ke array, jalankan perintah ini (sekali lagi, pastikan untuk mengganti nama perangkat dengan nama perangkat Anda sendiri sesuai kebutuhan):
Jika semuanya berjalan lancar, drive akan ditambahkan ke array tanpa hambatan. Saya yakin drive tersebut sebenarnya ditambahkan sebagai "hot spare" secara default, tetapi karena array ini kehilangan satu disk (yang mengalami kegagalan), drive tersebut langsung digunakan dan proses pembangunan ulang akan dimulai.
Anda bisa memantaunya seperti ini:
Ini mungkin akan memakan waktu cukup lama; pada server saya yang sederhana (yang sebagian besar berbasis pada perangkat keras kelas konsumen dan hard drive desktop), kecepatannya mencapai hampir 100 MB/detik. Perlu diingat bahwa ini adalah RAID-6, jadi ada banyak perhitungan paritas yang terlibat dalam proses pembangunan ulang; RAID-10 akan jauh lebih cepat. Mesin khusus ini memiliki CPU quad core AMD A10 9700E (huruf "E" berarti model hemat energi dengan kecepatan clock yang lebih rendah, yaitu tidak super cepat), hanya untuk memberi Anda gambaran tentang apa yang diharapkan. Dengan sembilan hard drive 8 TB dalam pengaturan saya, pembangunan ulang penuh membutuhkan waktu lebih dari 24 jam.
Selama proses pembangunan ulang, Anda dapat memasang sistem file pada array dan menggunakannya seperti biasa jika Anda mau, tetapi saya lebih suka membiarkannya hingga proses pembangunan ulang selesai. Perlu diingat bahwa jika satu drive gagal, drive lain mungkin akan segera menyusul, jadi Anda ingin proses pembangunan ulang dilakukan secepat mungkin karena Anda benar-benar tidak ingin drive lain gagal selama proses tersebut. Oleh karena itu, jangan membebaninya dengan operasi I/O lain yang tidak benar-benar diperlukan.
Setelah selesai, tambahkan kembali ke file /etc/fstab Anda, reboot, dan nikmati file Anda :-)
