Disk VPS Penuh? 7 Langkah Mencari Penyebabnya Sebelum Menghapus Apa Pun

Disk VPS penuh hampir selalu datang tanpa undangan. Pagi masih lega 40 persen, sore tiba-tiba MySQL menolak menulis, Nginx membalas 500, dan SSH kita sendiri mulai lambat karena tidak bisa membuat file sementara. Yang paling menjengkelkan: angka di panel hosting sering terlambat beberapa jam, jadi kita baru sadar setelah layanan mati.

Refleks pertama biasanya langsung menghapus sesuatu — folder backup, log lama, atau lebih nekat lagi rm -rf pada direktori yang tidak kita kenali. Saran saya: tahan dulu. Menghapus tanpa tahu penyebabnya hanya memindahkan masalah ke minggu depan, dan kadang menghapus data yang justru masih dipakai. Urutan yang benar adalah mengukur dulu, menghapus kemudian.

Oke, lanjuutt.. kita jalankan tujuh langkah pemeriksaan di bawah ini. Semuanya perintah baca-saja kecuali dua langkah terakhir, dan itu pun ditandai jelas supaya kita tidak menghapus sesuatu secara tidak sengaja.

Kenapa Disk Bisa Penuh Tanpa Kita Sadari

Ada tiga sumber pertumbuhan yang paling sering luput dari pandangan:

Log yang tidak pernah diputar. Aplikasi menulis ke application.log, logrotate tidak pernah dikonfigurasi untuk direktori itu, dan dalam tiga bulan filenya membengkak jadi puluhan GB.
Journal systemd. Di banyak distro, journal dibatasi ukuran maksimal, tapi kalau batasnya longgar atau ada log kernel yang banjir error, dia ikut menelan ruang.
Docker. Image lama, container mati, build cache, dan volume anonim menumpuk. Satu docker build yang gagal berulang kali bisa meninggalkan cache lebih besar dari seluruh aplikasi kita.

Belum lagi dua yang tidak terlihat sama sekali: file yang sudah dihapus tapi masih dipegang proses (ruangnya belum kembali), dan inode habis walau kapasitas masih longgar. Dua kasus ini yang paling sering bikin orang bingung karena df -h dan kenyataan di lapangan tidak cocok.

Langkah 1: Pastikan Apa yang Sebenarnya Penuh

Mulai dari dua perintah ini, jangan lebih dulu yang lain:


df -h
df -i

df -h menunjukkan kapasitas per filesystem, sedangkan df -i menunjukkan pemakaian inode. Kalau df -h masih 60 persen tapi df -i sudah 100 persen, masalah kita bukan ukuran file, melainkan jumlah file — biasanya jutaan file sesi, cache thumbnail, atau antrean mail yang tidak pernah dibersihkan. Menghapus satu file besar tidak akan menolong sama sekali di kasus ini.

Perhatikan juga nama filesystem-nya. Di VPS dengan LVM atau container, bisa jadi yang penuh hanya /var atau / sementara /home masih lapang. Kita perlu tahu persis mount point mana yang bermasalah sebelum menyusuri direktori.

Langkah 2: Cari Direktori Terbesar, Bukan File Terbesar

Setelah tahu mount point yang penuh, ukur isinya per direktori:


sudo du -xhd1 / | sort -h

Flag -x penting: dia membuat du tetap di filesystem yang sama, jadi tidak ikut masuk ke mount lain (misalnya volume Docker yang ter-mount terpisah) dan hasilnya tidak dobel. Ulangi perintah yang sama pada direktori yang paling besar, misalnya sudo du -xhd1 /var | sort -h, sampai ketemu kandidatnya.

Kalau ingin lebih nyaman, pasang ncdu — penjelajah disk berbasis terminal yang bisa kita jalankan dengan tombol panah:


sudo apt install ncdu
sudo ncdu -x /

ncdu memindai dulu (di server besar bisa beberapa menit), lalu menampilkan ukuran per folder secara interaktif. Ini jauh lebih aman daripada langsung rm pada nama folder yang kita tebak-tebak.

Untuk mencari file besar secara spesifik, tambahkan satu perintah lagi:


sudo find / -xdev -type f -size +500M -exec ls -lh {} \; 2>/dev/null

Langkah 3: Cek File Terhapus yang Masih Dipegang Proses

Ini langkah yang paling sering menyelamatkan saya dari kebingungan. Kita sudah hapus log 8 GB, df -h tidak berubah sedikit pun, dan kita mulai curiga sistemnya bohong. Padahal file itu masih terbuka oleh proses yang menulis ke sana — selama prosesnya hidup, kernel belum mengembalikan blok disknya.


sudo lsof +L1

Opsi +L1 menampilkan file dengan link count kurang dari 1, yaitu file yang sudah tidak punya nama di filesystem tapi masih dibuka proses. Alternatif tanpa lsof adalah membaca /proc:


sudo ls -l /proc/*/fd 2>/dev/null | grep deleted

Solusinya bukan menghapus lagi, tapi me-restart proses pemiliknya (Nginx, PHP-FPM, Docker container, atau service aplikasi). Setelah restart, ruangnya baru benar-benar kembali. Ini juga alasan kita sebaiknya mengosongkan log dengan truncate -s 0 namafile.log atau : > namafile.log, bukan rm — file yang dipotong tetap terpakai proses yang sama dan ruangnya langsung dibebaskan.

Langkah 4: Periksa Journal dan Log Sistem

Ukur dulu seberapa besar journal menempati disk:


journalctl --disk-usage

Kalau angkanya besar, kita bisa memangkasnya tanpa menghapus konfigurasi apa pun. Opsi --vacuum-size menghapus arsip journal paling lama sampai ukurannya turun di bawah batas yang kita tentukan:


sudo journalctl --vacuum-size=500M

Dokumentasi systemd menjelaskan satu detail yang sering salah dipahami: --vacuum-size hanya menyentuh file journal yang sudah diarsipkan, bukan file aktif yang sedang ditulis. Karena itu hasil --disk-usage sesudahnya bisa tidak persis 500 MB. Kalau ingin lebih agresif, gabungkan dengan rotasi lebih dulu:


sudo journalctl --rotate
sudo journalctl --vacuum-time=14d

Supaya tidak berulang tiap bulan, tetapkan batas permanen di /etc/systemd/journald.conf:


[Journal]
SystemMaxUse=1G
SystemMaxFileSize=200M

Setelah itu jalankan sudo systemctl restart systemd-journald. Untuk log aplikasi di /var/log, periksa apakah ada yang tidak tercakup logrotate:


sudo du -sh /var/log/* | sort -h | tail -20

File seperti *.log.1 yang menahun, atau direktori aplikasi yang menulis log sendiri di luar /var/log, biasanya jadi tersangka.

Langkah 5: Audit Pemakaian Docker

Kalau VPS kita menjalankan Docker, hampir pasti ada sampah di sana. Lihat ringkasannya lebih dulu:


docker system df
docker system df -v

Opsi -v menampilkan rincian per image, container, dan volume — termasuk kolom RECLAIMABLE, yaitu ruang yang bisa diambil kembali. Baru setelah angkanya jelas, kita bersihkan secara bertahap, dari yang paling aman:


docker builder prune

# 2. container berhenti, network tak terpakai, image dangling, build cache
docker system prune

# 3. lebih agresif: semua image tanpa container + volume anonim
docker system prune -a --volumes

Hati-hati pada perintah ketiga. Dokumentasi Docker menyatakan --volumes hanya memangkas volume anonim yang tidak dipakai container mana pun, tapi tetap saja perintah ini menghapus image yang tidak sedang dipakai — termasuk image yang nanti harus diunduh ulang. Jangan pernah jalankan -a --volumes pada server produksi tanpa membaca daftar docker system df -v lebih dulu, apalagi kalau ada database yang datanya disimpan di volume tanpa container aktif.

Akar masalah yang lebih permanen biasanya ada di log container yang tidak dibatasi. Tambahkan batas di /etc/docker/daemon.json:


{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "20m",
    "max-file": "3"
  }
}

Konfigurasi ini berlaku untuk container yang dibuat setelah daemon di-restart, jadi container lama perlu dibuat ulang agar ikut aturan baru.

Langkah 6: Bersihkan Cache Paket dan Sisa Instalasi

Dua perintah ini aman dan biasanya mengembalikan beberapa ratus MB sampai beberapa GB:


sudo apt-get clean
sudo apt-get autoremove --purge

apt-get clean mengosongkan cache paket .deb di /var/cache/apt/archives, sementara autoremove --purge membuang paket dependensi yang sudah tidak dibutuhkan beserta konfigurasinya. Di Ubuntu, kernel lama juga sering menumpuk; apt-get autoremove biasanya sudah menanganinya, tapi kita bisa memeriksa dengan dpkg --list | grep linux-image.

Jangan lupa memeriksa direktori yang sering jadi tempat parkir file besar: /var/backups, folder backup manual di /root, file dump database .sql yang terlupa, dan image atau arsip .tar.gz hasil eksperimen. Ini bukan sampah sistem, jadi hapus hanya setelah kita yakin salinannya ada di tempat lain.

Langkah 7: Pasang Pengaman supaya Tidak Terulang

Setelah ruang kembali lega, pekerjaan belum selesai. Tanpa pengaman, disk akan penuh lagi dalam hitungan minggu — dan biasanya pada jam yang paling tidak nyaman.

Yang paling murah adalah pemeriksaan berkala lewat cron yang mengirim peringatan saat pemakaian melewati ambang tertentu, misalnya 85 persen. Kalau kita sudah memakai Healthchecks untuk memantau cron job, pola yang sama bisa dipakai: kirim ping hanya ketika kapasitas masih aman, sehingga alarm berbunyi justru saat ping-nya berhenti datang.

Tiga kebiasaan lain yang layak dibakukan:

Batas ukuran log di semua lapisan — journald, Docker, dan logrotate untuk aplikasi kita sendiri.
Retensi backup yang jelas — simpan 7 harian dan 4 mingguan, sisanya dibuang otomatis, dan simpan di luar VPS.
Pantau tren, bukan hanya angka sesaat. Kenaikan 2 persen per hari jauh lebih penting daripada posisi 78 persen hari ini, karena yang pertama memberi kita waktu seminggu untuk bertindak.

Kesimpulan

Disk VPS penuh jarang disebabkan satu file raksasa yang dramatis. Lebih sering dia adalah hasil penjumlahan dari log yang tidak diputar, image Docker yang menua, dan file terhapus yang masih dipegang proses. Karena itu urutan kerjanya selalu sama: ukur dengan df, telusuri dengan du atau ncdu, periksa inode dan file terhapus, lalu baru bersihkan — dari yang paling aman ke yang paling berisiko.

Kalau hari ini kita sempat mencatat satu hal dari artikel ini, catat yang ini: jangan pernah menghapus apa pun sebelum tahu direktori mana yang menghabiskan ruang dan proses mana yang memakainya. Setelah kebiasaan itu terbentuk, disk penuh berubah dari bencana jadi sekadar tugas rumah tangga server yang selesai dalam sepuluh menit.