Situs WordPress tiba-tiba error, MySQL menolak menulis, atau dashboard tidak bisa menyimpan apa pun — padahal tidak ada yang Anda ubah. Salah satu penyebab yang paling sering terlewat: disk VPS penuh. Ketika partisi habis, layanan yang butuh menulis ke disk berhenti berfungsi, meski prosesnya tampak masih berjalan.
Daftar Isi
Jawaban Singkat
Periksa ruang kosong dulu, sebelum me-restart layanan apa pun. Restart tidak membebaskan disk. Temukan direktori terbesar, bersihkan yang aman (log lama, cache, backup kedaluwarsa, file sementara), pastikan MySQL dan layanan lain bisa menulis kembali, lalu pasang pencegahan agar tidak terulang.
Tanda-Tanda Disk Penuh
| Gejala | Kenapa terjadi |
|---|---|
| Error establishing database connection | MySQL tidak bisa menulis / membuat file sementara |
| WordPress tidak bisa upload media / update gagal | Tidak ada ruang untuk file baru |
| Log error “No space left on device” | Partisi benar-benar 100% terpakai |
| Situs lambat lalu mati total | Swap dan file sementara ikut kehabisan ruang |
Persiapan dan Peringatan Penting
- Jangan menghapus file yang tidak Anda kenali. Menghapus file database, file konfigurasi, atau direktori sistem bisa memperparah keadaan.
- Backup dulu apa yang bisa dibackup — tetapi bila disk sudah 100%, backup ke server yang sama tidak mungkin; pindahkan backup lama ke luar server terlebih dahulu bila perlu.
- Bekerja lewat SSH dengan hak sudo.
Langkah 1: Lihat Ruang yang Tersisa
df -h
df -iPerintah pertama menunjukkan ruang per partisi; yang kedua menunjukkan inode (jumlah file). Disk bisa “penuh” karena inode habis meski ruang masih tampak ada — biasanya karena jutaan file kecil (cache sesi, misalnya). Perhatikan baris partisi root (/) dan partisi tempat data MySQL berada.
Langkah 2: Temukan Siapa yang Memakan Disk
sudo du -sh /var/* 2>/dev/null | sort -rh | head -20
sudo du -sh /var/log/* 2>/dev/null | sort -rh | head -20
sudo du -sh /var/lib/mysql 2>/dev/null
sudo du -sh /var/www/* 2>/dev/null | sort -rh | head -20Tersangka klasik, dari yang paling sering:
- Log yang tidak dirotasi (
/var/log, log Nginx, log PHP) — membengkak diam-diam selama berbulan-bulan. - Backup lama yang menumpuk di dalam server.
- File sementara dan cache (termasuk cache sesi PHP).
- Folder uploads WordPress yang berisi media duplikat atau file besar.
- Binary log MySQL bila replikasi/binlog aktif tanpa rotasi.
Langkah 3: Bersihkan yang Aman
Log sistem dengan journalctl: batasi ukuran log systemd tanpa menghapus file manual:
sudo journalctl --vacuum-size=200MLog lama terkompresi: file .gz lama di /var/log umumnya aman dihapus setelah Anda memastikan tidak sedang menyelidiki insiden yang butuh log tersebut.
Cache paket:
sudo apt cleanFile sementara: periksa /tmp dan direktori cache aplikasi; hapus hanya file yang jelas-jelas sementara dan tidak sedang dipakai.
Backup kedaluwarsa: pindahkan backup lama ke penyimpanan luar, lalu hapus dari server. Jangan menghapus satu-satunya backup terbaru.
Yang tidak boleh dihapus sembarangan: file database MySQL (/var/lib/mysql), wp-config.php, file inti WordPress, dan log yang sedang Anda pakai untuk diagnosis insiden berjalan.
Langkah 4: Pulihkan Layanan
Setelah ada ruang kosong yang cukup (sisakan setidaknya beberapa ratus MB untuk operasi normal):
sudo systemctl restart mysql
sudo systemctl restart php8.3-fpm
sudo systemctl restart nginxSesuaikan versi PHP dengan server Anda. Muat ulang situs dan periksa apakah error database hilang dan upload media kembali berfungsi.
Langkah 5: Cegah Terulang
- Pastikan logrotate aktif untuk Nginx, PHP, dan MySQL, sehingga log dirotasi dan dikompresi otomatis.
- Batasi ukuran log systemd secara permanen lewat konfigurasi journald bila perlu.
- Jadwalkan pemeriksaan disk mingguan (
df -h) atau pasang peringatan saat pemakaian melewati 80%. - Pisahkan backup dari server produksi: backup yang tinggal di server yang sama tidak melindungi dari disk penuh — justru ikut memenuhinya.
- Tinjau media WordPress berkala: hapus media tak terpakai dan kompresi gambar besar sebelum diupload.
Verifikasi Hasil
Perbaikan berhasil bila df -h menunjukkan ruang kosong yang sehat, MySQL berjalan stabil tanpa error tulis, WordPress bisa menyimpan posting dan mengupload media, dan pemakaian disk tidak melonjak lagi dalam 24 jam berikutnya.
Troubleshooting Lanjutan
| Situasi | Langkah berikutnya |
|---|---|
| df menunjukkan penuh, tapi du tidak menemukan pelakunya | Kemungkinan file yang sudah dihapus masih dipegang proses (deleted but open); restart layanan pemegangnya atau periksa dengan lsof |
| Inode habis, ruang masih ada | Cari direktori dengan jutaan file kecil (biasanya sesi/cache) dan bersihkan dengan hati-hati |
| Disk penuh lagi dalam hitungan hari | Telusuri pertumbuhan per direktori harian; kemungkinan ada log error yang berputar tanpa henti |
| MySQL tetap error setelah ruang dibebaskan | Periksa tabel yang korup dan error log MySQL; jangan menghapus file database manual |
FAQ
Berapa ruang kosong yang aman?
Sebagai patokan praktis, jangan biarkan partisi sistem melewati 80–85% secara rutin. Di atas itu, Anda kehilangan ruang manuver untuk log, file sementara, dan update.
Apakah menghapus log berbahaya?
Menghapus log lama yang sudah dirotasi umumnya aman, tetapi jangan menghapus log aktif yang sedang Anda butuhkan untuk diagnosis. Gunakan vacuum/rotasi, bukan hapus membabi buta.
Kenapa situs down padahal CPU dan RAM normal?
Karena banyak layanan gagal bukan karena CPU/RAM, melainkan karena tidak bisa menulis. Disk adalah sumber daya ketiga yang sama pentingnya dan paling sering dilupakan.
Kesimpulan
Disk penuh adalah penyebab diam-diam dari banyak “WordPress down misterius”. Periksa df dulu, temukan pelakunya dengan du, bersihkan yang aman, pulihkan layanan, dan pasang rotasi log serta peringatan 80%. Lima langkah itu mengubah insiden berulang menjadi masalah yang tidak pernah kembali.