Studi Kasus LVM Error, Ketika PVS Missing dan Server Gagal Booting

Pernahkah kamu merasakan dinginnya keringat di punggung saat menyadari server database utama tiba-tiba mati dan tidak mau menyala kembali? Itu yang saya alami minggu lalu.

Di artikel ini, kita membahas LVM error PVS/LVS secara praktis agar kamu paham konteks dan penerapannya.

Semuanya berawal dari peringatan monitoring biasa “Disk Usage Warning”. Namun saat saya masuk untuk mengecek, situasinya jauh lebih buruk. Direktori /var/lib/mysql kosong melompong. Mount pointnya hilang. Dan saat saya mencoba merestart server, ia tersangkut di mode emergency.

Penyebabnya? Kegagalan pada lapisan LVM (Logical Volume Manager). Salah satu disk fisik dianggap “hilang” oleh sistem, menyebabkan seluruh Volume Group menjadi tidak konsisten.

Dalam artikel ini, saya akan membedah kejadian tersebut langkah demi langkah. Mulai dari kepanikan awal, diagnosis yang salah, hingga akhirnya berhasil memulihkan sistem menggunakan perintah-perintah LVM yang jarang tersentuh dalam operasi harian.

Gejala awal: dimana data saya?

Malam itu, aplikasi web utama client saya melaporkan “Database Connection Error”. Asumsi awal saya standar, mungkin service MySQL mati.

Saya coba start manual:

sudo systemctl start mysql

Gagal. Log error di /var/log/syslog mengatakan: Directory /var/lib/mysql not found.

Jantung saya mulai berdegup lebih kencang. Saya mengecek daftar mount point:

df -h

Benar saja, partisi yang seharusnya memount direktori data tersebut tidak ada di daftar.

Investigasi lapis demi lapis

Di Linux, storage itu seperti kue lapis. Kita harus mengeceknya dari bawah ke atas.

Cek disk fisik (layer paling bawah)

Saya menggunakan lsblk untuk melihat apakah sistem operasi masih mendeteksi hard disk fisiknya.

lsblk

Hasilnya:

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda       8:0    0   50G  0 disk
├─sda1    8:1    0  500M  0 part /boot
└─sda2    8:2    0 49.5G  0 part /
sdb       8:16   0  100G  0 disk
└─sdb1    8:17   0  100G  0 part

Disk /dev/sdb (disk data) masih terdeteksi. Ini kabar baik. Artinya disknya tidak corupt atau hilang secara fisik.

Cek lvm (layer tengah)

Di sinilah masalahnya terlihat jelas. Saya menjalankan perintah pvs (Physical Volume Scan) untuk melihat status disk LVM.

sudo pvs

Outputnya membuat saya lemas:

  PV         VG        Fmt  Attr PSize    PFree
  /dev/sda2  rootvg    lvm2 a--    49.50g    0
  unknown    datavg    lvm2 a-m   100.00g    0

Perhatikan kata unknown dan atribut a-m (m = missing). LVM tahu ada anggota grup datavg yang hilang, tapi dia tidak bisa menemukan /dev/sdb1 yang seharusnya menjadi anggotanya.

Karena salah satu anggotanya “hilang”, LVM secara otomatis menonaktifkan seluruh Logical Volume di atasnya demi keamanan data.

Mengapa bisa terjadi?

Setelah menelusuri dmesg, saya menemukan banyak pesan error I/O pada /dev/sdb.

dmesg | grep sdb

Ternyata, disk tersebut adalah volume virtual (di lingkungan VMware) yang sempat mengalami detach sesaat karena masalah di sisi storage hypervisor. Walaupun disknya sudah tersambung kembali, metadata LVM sudah terlanjur menandainya sebagai “rusak/hilang”.

Langkah pemulihan (recovery)

Jangan buru-buru menjalankan perintah perbaikan disk (fsck) karena masalahnya bukan di filesystem, tapi di wadahnya (LVM).

Langkah 1: scan ulang

Saya mencoba menyuruh LVM untuk memindai ulang semua perangkat blok yang ada.

sudo pvscan

Output:

  PV /dev/sda2   VG rootvg   lvm2 [49.50 GiB / 0    free]
  PV /dev/sdb1   VG datavg   lvm2 [100.00 GiB / 0    free]

Ajaib! /dev/sdb1 kembali terdeteksi. Namun, Volume Group datavg masih belum aktif.

Langkah 2: cek status volume group

sudo vgs

Sekarang statusnya sudah tidak ada yang “missing”, tapi Logical Volume (LV) di dalamnya masih inactive.

Langkah 3: re-aktivasi volume

Ini adalah momen penentuan. Saya harus memaksa LVM untuk mengaktifkan kembali volume tersebut.

sudo vgchange -ay datavg

• -a = activate
• y = yes

Output: 1 logical volume(s) in volume group "datavg" now active

Langkah 4: mount dan verifikasi

Sekarang perangkat /dev/datavg/mylv sudah muncul kembali. Saya memountnya dengan hati-hati.

sudo mount /dev/datavg/mylv /var/lib/mysql

Saya menahan napas sambil mengecek isinya:

ls -l /var/lib/mysql

Semua file ada di sana! .ibd, .frm, semuanya lengkap.

Pelajaran berharga

Insiden ini mengajarkan saya bahwa:

1. Monitoring Layer LVM itu Penting: Selama ini saya hanya memonitor Disk Space (df -h). Saya lupa memonitor status LVM (vgs atau lvs). Jika saya tahu disk sempat flapping (mati-nyala), saya bisa bertindak lebih cepat.
2. Jangan Panik: Saat direktori hilang, insting pertama biasanya adalah “format ulang” atau “restore backup”. Padahal datanya masih ada, hanya wadahnya yang terkunci.
3. Dokumentasi Partisi: Saya sangat bersyukur punya catatan server yang menjelaskan disk /dev/sdb itu isinya apa. Tanpa itu, saya mungkin akan bingung menebak-nebak disk mana yang bermasalah.

Troubleshooting storage memang membutuhkan pemahaman layer by layer. Pendekatan yang sama juga berlaku saat menangani container Docker yang crash. Dan untuk mencegah masalah di masa depan, pastikan server kamu sudah di-hardening dengan benar.

Sekarang, setiap kali ada alert disk, hal pertama yang saya ketik bukan lagi reboot, melainkan lsblk dan pvs. Pahami lapisannya, maka kamu akan menemukan solusinya.

---

Semoga pembahasan LVM error PVS/LVS ini membantu kamu mengambil keputusan yang lebih tepat di lapangan.