Recovery RAID + LVM, server GLC, & SSH
Hari ini, waktu seharian dihabiskan untuk Recovery RAID + LVM, Server GLC? iya. Server GLC yang menghosting situs ini, GLC-CAMPUS, dan glc-portal.
Troubleshooting ini makan waktu lama (dari pagi sampai malam) karena teknologi yang dipakai lebih kompleks dari yang biasa. server GLC menggunakan RAID + LVM, diatas hardware yang ternyata memang harus pensiun. sebenernya problem ini munculnya udah lama semenjak server menjadi susah diakses dengan ssh, dan service http pun juga error. namun karena kendala mudik & lokasi, maka diputuskan untuk meload data lama dari backup pada server lain. konsekuensinya jelas: artikel yang ada menjadi tidak uptodate, namun dengan pertimbangan “daripada website down?” mending pake data yang lama dulu sambil perlahan2 direcovery.
Ketika dicoba di nyalakan, menu grub sudah muncul dan sangat lama sekali ketika masuk ke tahap berikutnya yaitu me-load kernel. dicoba me-load safe-mode, dicoba untuk me-load old-kernel, hasilnya nihil. testing memory juga ngak masalah. intinya, ngak bisa masuk OS. gimana bisa masuk lah kernelnya ada ngak bisa di load?
recovery dari external bootdisk juga tidak langsung terbaca partisinya karena menggunakan RAID dan diperparah lagi diinstall LVM diatasnya. jadi perlu extra energy & skill untuk troubleshooting kasus ini.
ohya, jangan jalankan fsck untuk partisi RAID ini meskipun anda udah ngebet banget, hehehe. ini karena fsck dapat merubah metadata disana, dimana kalo metadata berubah, kita ngak bisa merecover RAID, dan jika ngak bisa recovery RAID, maka LVMpun lenyap. fsck dilakukan kalo semua partisinya udah ketemu. dengan kata lain: RAID + LVM harus direcovery dahulu, baru dijalankan fscknya (Recovery RAID + LVM)
OK, tahap pertama: recovery RAID. jadi kita perlu scan RAID dengan mdadm –examine –scan . setelah ketemu, jangan lupa dimasukkan hasilnya ke mdadm.conf. setelah ketemu konfigurasi RAID yang sudah terdapat disana, maka aktifkan RAID tsb dengan mdadm -A -s. horeee… RAIDnya udah berhasi direcover. jika sudah jadi maka akan ada meta-device /dev/md0.
tahap kedua, adalah recovery LVM. disini, kita perlu mencari partisi & konfigurasi LVM yang tersisa. untuk itu, kita bisa pake pv/vg/lvscan untuk menemukankan mereka. bisa juga pake vgchange -ay untuk mendeteksi ulang partisi LVM yang ada. kalo ada lv yang terdeteksi namun belum ada devicenya, maka perlu dicreate udevnya dengan utility vgscan. horeee… LVM sudah terdeteksi… sekarang tinggal fsck dan menyelamatkan data yang ada. dari hasil fsck, terlihat jelas, bahwa banyak sekali masalah di filesystem: missing inode, crosslink, dll. perlu diingat tentang konsekuensi fsck adalah data anda dapat terpotong. jadi siap2 aja untuk ini (Recovery RAID + LVM).
akhir kata, sebagian besar data dapat dikembalikan dengan sempurna terutama file-file aplikasi (wordpress, pictures, dll). hal ini wajar karena pada partisi tsb, lebih banyak operasi read daripada write. yang paling parah kena dampak kerusakan adalah partisi /var & /var/lib (tempat log & database), nah loooo… hehehe beberapa tabel mysql rusak berat, dan konsekuensinya datanya hilang. sedih… 🙁 beberapa artikel website ini juga hilang sehingga harus nulis ulang lagi… hadooohhhh…
lesson learnt:
- pelajaran berharga: kalo OS anda menggunakan RAID + LVM, sangat disarankan untuk tidak mengupgrade kernel karena bisa jadi bad things could happen. script ngak compatible, grubnya ngak ngeload kernel, dll
- Pake hardware yang bagus.
- Mungkin sebaiknya jangan pake mysql terutama engine myisam, karena lebih rentan terhadap kerusakan data. sebagai alternatifnya, bisa coba postgresql, atau mysql dengan innodb.
- jika memutuskan untuk menggunakan RAID & LVM, sang admin harus punya skill juga untuk melakukan troubleshooting jika ada kerusakan/problem. bukan cuman install doang.
- dalam melakukan recovery, anda mungkin akan heran bahwa load mesin menjadi tinggi, namun CPU utility adalah low. ini adalah wajar, karena yang bikin load tinggi adalah IO bukan CPU usage.