Migrasi VPS KVM Storage agar Server Production Tidak Penuh

Pernah nggak kamu lagi enak-enak ngopi di pagi hari, tiba-tiba monitoring server nyala terus—bunyi alarm kenceng banget, notification WhatsApp masuk bertubi-tubi. Kamu cek Grafana, disk usage server production sudah 97%. “Kok bisa ya?” Gumam kamu sambil buru-buru login SSH. Padahal kemarin masih aman di 72%. Ternyata, ada satu VPS client yang disk-nya naik dari 40GB jadi 200GB dalam semalam gara-gara mereka deploy Elasticsearch tanpa quota. Dan boom—storage server production kamu penuh. Semua VPS lain juga ikut kena imbasnya. Ibarat satu tenant di apartemen tiba-tiba isi kamarnya sampai ke langit-langit, pintu koridor jadi tersumbat, tetangga nggak bisa lewat.

Situasi kayak gini bukan cerita fiksi. Saya pernah handle kasus di mana satu production server nge-host 28 VPS KVM, dan tiba-tiba 6 di antaranya mengalami I/O error karena underlying storage sudah penuh. Yang bikin parah? Beberapa VPS itu bahkan nggak dipakai aktif lagi—client sudah lama nggak bayar, tapi masih hidup dan terus consume disk space. Nah, di artikel ini kita akan bahas tuntas cara sortir (identifikasi) VPS mana yang bikin storage penuh, dan bagaimana cara migrasi disk-nya tanpa downtime yang signifikan. Ini bukan teori—ini langkah-langkah yang sudah saya pakai berkali-kali di production.

Sebelum kita masuk ke perintah-perintah teknis, penting untuk kamu pahami dulu kenapa masalah ini bisa terjadi. Di infrastructure KVM, setiap VPS punya disk image file (biasanya format .qcow2 atau .raw) yang tersimpan di storage server. File-file ini bisa tumbuh secara dinamis—artinya walaupun kamu allocate 100GB untuk sebuah VPS, file disk-nya nggak langsung 100GB di awal. Tapi begitu data di dalam VPS nambah, file disk ini juga ikut membesar. Kalau nggak ada monitoring dan housekeeping yang proper, lama-kelamaan storage server kamu akan penuh tanpa kamu sadari. Ini masalah klasik di managed VPS hosting yang banyak dihadapi NOC engineer di seluruh dunia.

Kenapa Storage Server Production Bisa Penuh?

Sebelum kita sortir dan migrasi, ada baiknya kamu pahami dulu akar masalahnya. Storage server production bisa penuh karena beberapa alasan utama:

• Disk VPS yang tumbuh tanpa batas — Client aplikasi yang generate data terus-misern (logs, database, cache). Tanpa quota, disk terus membesar sampai makan semua space server.
• VPS tidur yang masih consume space — VPS yang sudah tidak dipakai client, tapi belum di-destruct. Disk image-nya masih ada di storage.
• Snapshot accumulation — Kalau kamu pakai snapshot untuk backup, setiap snapshot consume space tambahan. Banyak NOC engineer lupa bersihin snapshot lama.
• Log files yang tidak dirotate — VPS yang menjalankan aplikasi dengan logging tinggi (Elasticsearch, Apache, Nginx access log) bisa generate puluhan GB log per hari.
• Temporary files dan cache — /tmp, /var/cache, dan direktori cache aplikasi yang tidak pernah dibersihkan.

Symptoms yang Kamu Perlu Waspadai

Biasanya masalah storage penuh ini tidak muncul tiba-tiba tanpa gejala. Ada beberapa tanda yang perlu kamu perhatikan sebelum server benar-benar crash:

• I/O wait naik drastis di monitoring (CPU steal time juga bisa naik kalau storage sudah bottleneck)
• VPS tertentu mulai slow response, padahal bandwidth dan CPU normal
• Error message “No space left on device” di sistem operasi host
• Kesalahan write ke disk di beberapa VPS secara bersamaan
• Proses backup gagal karena tidak ada cukup space untuk menulis file backup

Langkah 1: Identifikasi dan Sortir VPS Berdasarkan Disk Usage

Oke, sekarang kita mulai dari langkah paling fundamental: identifikasi VPS mana yang paling banyak consume storage. Kalau kamu host banyak VPS di satu server, kamu nggak mungkin cek satu-satunya kan? Kamu butuh cara yang cepat dan efisien.

Pertama, login ke production server sebagai root:

ssh root@203.0.113.10

Kemudian, jalankan perintah berikut untuk melihat semua VPS yang berjalan beserta disk usage-nya:

for vm in $(virsh list --name); do echo "=== $vm ==="; virsh domblklist $vm 2>/dev/null | grep -E '.(qcow2|raw|img)$' | while read dev disk; do if [ -f "$disk" ]; then echo "  Disk: $disk"; echo "  Size: $(du -h $disk | awk '{print $1}')"; echo "  Alloc: $(qemu-img info $disk 2>/dev/null | grep 'disk size' | awk '{print $3, $4}')"; fi; done; done

Perintah di atas akan loop semua VPS, cek file disk image-nya, dan tampilkan ukuran aktual. Hasilnya kurang lebih seperti ini:

=== vps-client-a ===
  Disk: /var/lib/libvirt/images/vps-client-a.qcow2
  Size: 45G
  Alloc: 42.3 GB

=== vps-client-b ===
  Disk: /var/lib/libvirt/images/vps-client-b.qcow2
  Size: 200G
  Alloc: 187.6 GB

=== vps-client-c ===
  Disk: /var/lib/libvirt/images/vps-client-c.qcow2
  Size: 10G
  Alloc: 3.2 GB

=== vps-client-d ===
  Disk: /var/lib/libvirt/images/vps-client-d.qcow2
  Size: 80G
  Alloc: 76.1 GB

Nah, dari situ langsung keliatan kan? VPS client-b consume hampir 188GB. Kalau server kamu cuma punya 1TB total storage dan sudah host 28 VPS, satu VPS yang makan 188GB itu sudah hampir 20% dari total. Belum lagi VPS lain yang juga consume space cukup besar.

Untuk sorting yang lebih cepat, kamu bisa pakai satu-liner ini:

for vm in $(virsh list --name); do disk=$(virsh domblklist $vm 2>/dev/null | grep -E '.(qcow2|raw|img)$' | awk '{print $2}'); if [ -f "$disk" ]; then size=$(du -b "$disk" | awk '{print $1}'); echo "$size $vm $disk"; fi; done | sort -rn | head -20

Perintah ini akan mengurutkan VPS dari yang paling besar sampai yang paling kecil. Sangat praktikal kalau kamu punya banyak VPS di satu server.

Langkah 2: Analisis Lebih Dalam — Apa yang Bikin Disk VPS Besar?

Setelah kamu tahu VPS mana yang paling besar, langkah selanjutnya adalah masuk ke dalam VPS itu dan cari tahu apa yang bikin disk-nya membengkak. Login ke VPS yang bermasalah:

virsh console vps-client-b

Atau kalau kamu pakai SSH, langsung aja ssh ke IP VPS tersebut. Kemudian jalankan analisis disk:

df -h
du -sh /* 2>/dev/null | sort -rh | head -15

Dari situ kamu bisa lihat direktori mana yang consume paling banyak space. Biasanya yang sering jadi masalah:

/var/log         45G
/var/lib/mysql   38G
/home/user       67G
/tmp             12G

Kalau /var/log yang besar, kemungkinan besar log rotation tidak jalan. Kamu bisa cek:

ls -lah /var/log/*.log* | head -20
ls -lah /var/log/syslog* | head -10

Atau kalau /var/lib/mysql yang besar, itu berarti database-nya sudah cukup besar dan mungkin perlu optimization atau dump ke storage lain.

Langkah 3: Membuat Rencana Migrasi

Oke, sekarang kamu sudah tahu VPS mana yang bermasalah dan apa penyebabnya. Ada beberapa opsi yang bisa kamu ambil:

1. Cleanup di tempat — Bersihkan log, cache, dan file tidak perlu di dalam VPS tanpa migrasi.
2. Shrink disk image — Kalau kamu sudah bersihkan file di dalam VPS, kamu bisa shrink disk image-nya agar space terpakai berkurang.
3. Migrate ke storage lain — Pindahkan disk image VPS ke storage server tambahan (NAS, SAN, atau server lain).
4. Migrate VPS ke server lain — Pindahkan seluruh VPS ke production server yang punya lebih banyak storage.

Untuk artikel ini, kita fokus ke opsi 3 dan 4 — migrasi. Kenapa? Karena kadang cleanup aja nggak cukup. VPS-nya memang butuh storage yang lebih banyak, atau server production kamu memang sudah waktunya di-offload beberapa VPS-nya.

Langkah 4: Persiapan Migrasi

Sebelum mulai migrasi, pastikan beberapa hal ini sudah siap:

• Storage destination sudah siap — Baik itu NAS (NFS mount), storage server lain, atau LVM volume baru. Pastikan space-nya cukup.
• Network bandwidth cukup — Migrasi disk image berukuran besar butuh bandwidth yang memadai. Kalau bisa, pakai dedicated network (management VLAN).
• Backup sudah dilakukan — SELALU backup dulu. Ini bukan opsional.
• Jadwalkan maintenance window — Beritahu client kalau ada downtime. Jangan migrasi diam-diam—itu unprofessional dan bisa bikin trust hilang.
• Dokumentasikan semua langkah — Tulis di ticketing system. Kamu nggak mau lupa langkah yang sudah dilakukan saat ada masalah.

du -sh /var/lib/libvirt/images/vps-client-b.qcow2
# Output: 200G

# Cek space di destination
df -h /mnt/nas-storage/
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/nfs-share  2.0T  800G  1.2T  40% /mnt/nas-storage

Langkah 5: Migrasi Disk VPS dengan virsh

Ada beberapa cara migrasi yang bisa kamu pilih tergantung situasi:

Metode A: Offline Migration (Blockcopy via SCP/rsync)

Cara ini paling straightforward. Matikan VPS, copy file disk image, jalankan ulang VPS di lokasi baru.

# 1. Matikan VPS
virsh shutdown vps-client-b
# Tunggu sampai VPS benar-benar mati
virsh list --name | grep vps-client-b
# Kalau tidak ada output, berarti sudah mati

# 2. Verifikasi file disk
ls -lah /var/lib/libvirt/images/vps-client-b.qcow2
# -rw------- 1 root root 200G Jul 15 10:30 /var/lib/libvirt/images/vps-client-b.qcow2

# 3. Copy ke storage destination
rsync -avP --progress /var/lib/libvirt/images/vps-client-b.qcow2 /mnt/nas-storage/vps-client-b.qcow2

# 4. Verifikasi integritas file di destination
md5sum /var/lib/libvirt/images/vps-client-b.qcow2
md5sum /mnt/nas-storage/vps-client-b.qcow2
# Pastikan MD5 hash kedua file IDENTIK

# 5. Update XML config VPS untuk pointing ke lokasi baru
virsh dumpxml vps-client-b > /tmp/vps-client-b.xml
# Edit path di dalam XML:
# Ganti /var/lib/libvirt/images/vps-client-b.qcow2
# Menjadi /mnt/nas-storage/vps-client-b.qcow2

# 6. Define ulang VPS dengan config baru
virsh undefine vps-client-b --nvram
virsh define /tmp/vps-client-b.xml

# 7. Jalankan VPS
virsh start vps-client-b

Metode B: Live Migration (virsh migrate)

Kalau kamu tidak bisa toleransi downtime sama sekali, live migration adalah pilihannya. Tapi perlu diingat—live migration biasanya untuk migrate antar server, bukan antar storage di server yang sama.

# Live migration ke server lain
virsh migrate --live vps-client-b qemu+ssh://server-dest/system

# Cek status migrasi
virsh domjobinfo vps-client-b

Live migration cocok kalau kamu mau pindahkan VPS dari server yang storage-nya penuh ke server baru yang punya lebih banyak space. Tapi pastikan network antar server cukup cepat—minimal 1Gbps dedicated, lebih bagus kalau 10Gbps.

Metode C: Block Copy (virsh blockcopy)

Ini cara yang lebih advanced, cocok untuk migrasi block device secara live:

# Mulai block copy ke file baru
virsh blockcopy vps-client-b vda /mnt/nas-storage/vps-client-b-copy.qcow2 --wait --verbose

# Setelah selesai, switch block device
virsh blockjob vps-client-b vda --pivot

# Cek status
virsh domblkinfo vps-client-b vda

Troubleshooting: Masalah yang Sering Muncul Saat Migrasi

Pro Tips dari Lapangan

# Quick alert script - tambahkan ke crontab
#!/bin/bash
USAGE=$(df /var/lib/libvirt/images | tail -1 | awk '{print $5}' | sed 's/%//')
if [ $USAGE -gt 80 ]; then
    echo "WARNING: Storage usage at ${USAGE}% on $(hostname)" | mail -s "Storage Alert" noc@company.com
fi

Related Issues

Masalah storage di production server seringkali berkaitan erat dengan beberapa issue lain yang perlu kamu pahami juga. Misalnya, kalau kamu mengalami cara mengecek disk full di VPS, itu bisa jadi early warning sebelum masalah jadi lebih parah. Selain itu, memahami optimasi storage di VPS Linux bisa membantu kamu mencegah masalah serupa terjadi di kemudian hari. Dan kalau kamu memang sudah harus upgrade infrastruktur, baca juga tentang migrasi VPS ke server baru untuk panduan yang lebih komprehensif.

Kesimpulan

Masalah storage penuh di production server itu serius, tapi bukan akhir dari segalanya. Dengan pendekatan yang terstruktur—identifikasi, analisis, perencanaan, dan eksekusi migrasi yang proper—kamu bisa resolve masalah ini tanpa harus kehilangan data atau trust dari client. Intinya: jangan tunggu sampai server penuh baru bertindak. Setup monitoring, buat housekeeping routine, dan selalu punya rencana backup untuk setiap VPS yang kamu manage. Kalau kamu butuh bantuan lebih lanjut soal infrastructure VPS management, jangan ragu untuk konsultasi dengan tim NOC yang berpengalaman.