Belajar RAID - Troubleshooting & Recovery Scenarios

#Pendahuluan

Semua prosedur di series ini dirancang untuk masa tenang. Episode 16 ini membahas masa darurat: array yang degraded, rebuild yang gagal, metadata yang korup, sampai sistem yang panic. Di sinilah keterampilan kalian benar-benar diuji.

Prinsip pertama recovery: jangan panik dan jangan membuat keadaan lebih buruk. Langkah yang salah dalam keadaan kacau — misalnya --force assemble yang gegabah — bisa mengubah kejadian yang bisa diperbaiki menjadi kehilangan data total. Mari kita bahas skenario umum satu per satu dengan kepala dingin.

#Array Degraded

#Diagnosis Awal

Skenario paling umum: monitoring memberi tahu ada array degraded. Langkah pertama adalah membaca kondisi tanpa mengubah apa pun:

cat /proc/mdstat
sudo mdadm --detail /dev/md0
sudo dmesg | grep -i "md\|raid"

Output dmesg menampilkan pesan kernel tentang disk yang gagal, seperti md/raid1:md0: Disk failure on sdb, disabling device.. Ini memberitahu disk mana yang bermasalah dan apakah disk lain ikut terpengaruh.

#Tindakan

Setelah diagnosis jelas, baru bertindak:

sudo mdadm --fail /dev/md0 /dev/sdb
sudo mdadm --remove /dev/md0 /dev/sdb
sudo mdadm --add /dev/md0 /dev/sdd

Urutan --fail, --remove, lalu --add menangani kegagalan tunggal dengan aman. Pantau rebuild sampai selesai sebelum menilai kondisi lebih lanjut.

#Rebuild Gagal

#Mengapa Rebuild Bisa Gagal

Rebuild kadang gagal di tengah jalan karena salah satu penyebab ini:

• Disk pengganti sebenarnya sudah rusak (kebetulan atau salah stok).
• Terjadi URE — sektor yang tidak terbaca di disk lain selama rebuild.
• Koneksi tidak stabil sehingga disk terputus berulang kali.

Gejalanya muncul di mdadm --detail sebagai Rebuild Status yang berhenti, atau disk pengganti tiba-tiba masuk status failed.

#Strategi Mengatasi

sudo dmesg | grep -i error | tail -20
sudo smartctl -a /dev/sdd | grep -i "reallocated\|pending"

Perintah smartctl di atas memeriksa apakah disk pengganti sehat. Jika disk pengganti bermasalah, ganti lagi. Jika masalahnya URE di disk lain, kalian harus menilai: apakah masih ada redundancy yang tersisa? Jika array parity dan satu disk lagi gagal saat rebuild, berhenti dan panggil backup.

#Metadata Korup dan --force

#Kapan --force Diperlukan

Kadang mdadm menolak meng-assemble array karena metadata tidak konsisten — misalnya dua disk mengklaim posisi yang sama, atau superblock rusak. Ini saat --force bisa digunakan, TAPI hanya setelah analisis:

sudo mdadm --examine /dev/sdb
sudo mdadm --examine /dev/sdc
sudo mdadm --examine /dev/sdd

Bandingkan output mdadm --examine dari semua disk: UUID array harus sama, dan perhatikan Device Role di setiap superblock. Jika dua disk mengklaim role yang sama, kalian harus memutuskan disk mana yang benar — biasanya yang paling baru aktif.

#Melakukan --force

Setelah yakin, assemble dengan paksa:

sudo mdadm --assemble --force /dev/md0 /dev/sdc /dev/sdd

Perintah --assemble --force memaksa mdadm memakai disk yang tersedia meski tidak lengkap. Konsekuensinya: data di disk yang dikorbankan bisa tidak konsisten. Setelah array aktif, segera --add disk pengganti dan biarkan rebuild.

#Disk Rusak dan ddrescue

#Menyalin Disk yang Failing

Jika sebuah disk sudah tidak bisa dibaca penuh tapi masih sebagian terbaca, jangan memaksa array membaca langsung dari disk itu. Salin dulu ke media lain dengan ddrescue, yang menyalin sebanyak mungkin lalu me-retry bagian yang gagal:

sudo ddrescue /dev/sdb /dev/sde /var/log/ddrescue.log

Perintah ddrescue /dev/sdb /dev/sde menyalin isi /dev/sdb ke /dev/sde sambil mencatat kemajuan di logfile. Proses bisa dijalankan berulang dengan mode -r untuk retry sektor yang gagal — ini sering menyelamatkan data dari disk yang menuju kegagalan.

#Memakai Hasil Salinan

Setelah salinan selesai, pasang hasilnya ke array:

sudo mdadm --fail /dev/md0 /dev/sdb
sudo mdadm --remove /dev/md0 /dev/sdb
sudo mdadm --add /dev/md0 /dev/sde

Perintah --add /dev/sde menjadikan hasil salinan sebagai anggota array. Rebuild dari salinan jauh lebih aman daripada memaksa disk asli yang rusak bekerja lebih keras.

#OOM dan Kernel Panic

#Storage Sebagai Korban

OOM (Out Of Memory) dan kernel panic jarang disebabkan storage, tapi sering berdampak pada array. Saat kernel panic atau sistem crash, tulis yang belum selesai bisa membuat array dan filesystem tidak konsisten. Setelah reboot, urutannya:

cat /proc/mdstat
sudo mdadm --detail /dev/md0
sudo journalctl -b -1 | grep -i "oom\|panic"

Output journalctl -b -1 menampilkan log boot sebelumnya; cari jejak OOM atau panic. Jika array tampak tidak konsisten, pertimbangkan fsck pada filesystem setelah memastikan array bersih — dan tinjau penyebab OOM agar tidak terulang.

#Mencegah Terulang

• Atur vm.swappiness dan batas memory untuk proses besar.
• Pasang swap yang memadai atau tinjau kembali alokasi workload.
• Gunakan write-intent bitmap (episode 17) agar crash tidak membuat rebuild panjang.

#Penutup

Episode 16 membekali kalian dengan prosedur recovery untuk skenario terburuk: menangani array degraded, rebuild gagal, metadata korup dengan --force, menyalin disk rusak dengan ddrescue, serta menghadapi OOM dan kernel panic — selalu dengan disiplin: diagnosis dulu, bertindak kemudian.

Inti yang harus dibawa pulang:

• Diagnosis dengan mdstat, --detail, dan dmesg sebelum mengubah apa pun.
• Rebuild gagal biasanya karena disk pengganti rusak atau URE.
• --force assemble hanya setelah membandingkan metadata semua disk.
• ddrescue menyelamatkan data dari disk yang menuju kegagalan.
• OOM dan panic meninggalkan array tidak konsisten — periksa sebelum menulis.
• Jika ragu antara --force dan backup, prioritaskan backup.

Di episode 17 selanjutnya kita akan membahas advanced mdadm features — internal bitmap untuk rebuild yang lebih cepat, lockless bitmap baru di mdadm 4.6, serta write-intent journal untuk stabilitas RAID 4/5/6. Kalian akan belajar fitur-fitur yang jarang dipakai tapi menentukan ketahanan array.