Cara Mencari dan Membersihkan Disk Server yang Penuh

Website tiba-tiba error, database menolak menulis, dan log berisi "No space left on device"? Hampir pasti disk server penuh. Kabar baiknya, penyebabnya biasanya bisa ditemukan dalam beberapa menit dengan urutan pemeriksaan yang tepat, dan tidak perlu langsung menambah kapasitas.

Yang perlu dihindari adalah menghapus file secara acak sambil panik. Ikuti urutan di bawah: pastikan dulu apa yang habis, temukan pemakan terbesar, baru bersihkan dengan cara yang aman.

Ruang atau inode, mana yang habis?

Disk bisa "penuh" dengan dua cara. Pertama, ruangnya habis. Kedua, jumlah inode habis, yaitu jatah jumlah file di sistem file. Gejalanya sama, solusinya berbeda.

df -h     # pemakaian ruang per partisi
df -i     # pemakaian inode per partisi

Bila df -h menunjukkan 100% di / atau /var, lanjut ke langkah pencarian folder besar. Bila df -h masih longgar tapi df -i 100%, berarti ada jutaan file kecil. Lompat ke bagian inode di bawah.

Langkah mencari dan membersihkan disk penuh

Langkah 1. Cari folder terbesar dengan du

sudo du -xh --max-depth=1 / 2>/dev/null | sort -h | tail -15

Opsi -x membuat du tetap di satu sistem file, sehingga tidak ikut menghitung disk lain yang di-mount. Setelah ketemu folder terbesar, misalnya /var, ulangi perintah untuk folder itu dan turun terus sampai sumbernya jelas.

Langkah 2. Atau jelajahi dengan ncdu

ncdu menampilkan hal yang sama secara interaktif, jauh lebih nyaman untuk menelusuri:

sudo apt install ncdu      # Debian/Ubuntu
sudo dnf install ncdu      # keluarga Red Hat, dari EPEL bila perlu
sudo ncdu -x /

Gunakan tombol panah untuk masuk folder. Tombol d menghapus, jadi pakai dengan hati-hati.

Langkah 3. Periksa file terhapus yang masih terbuka

Kasus klasik: kamu sudah menghapus file log besar, tapi df tidak berubah. Itu karena proses yang menulis log tersebut masih memegang file-nya. Ruang baru dibebaskan setelah proses menutup file.

sudo lsof +L1

Perintah ini menampilkan file dengan jumlah link 0, artinya sudah dihapus tapi masih terbuka. Solusinya adalah restart layanan yang memegangnya. Untuk lain kali, kosongkan file log yang aktif dengan truncate -s 0 nama.log alih-alih menghapusnya.

Langkah 4. Batasi journal systemd

Journal bisa tumbuh besar di server yang sudah lama berjalan.

journalctl --disk-usage
sudo journalctl --vacuum-size=500M

Agar tidak terulang, tetapkan batas di /etc/systemd/journald.conf:

[Journal]
SystemMaxUse=500M

Lalu sudo systemctl restart systemd-journald. Sesuaikan angkanya dengan ukuran disk dan berapa lama log perlu disimpan.

Langkah 5. Bersihkan sisa Docker

Di server yang sering build atau update container, image lama, container berhenti, dan cache build menumpuk.

docker system df
docker system prune

docker system prune menghapus container yang berhenti, network yang tidak dipakai, image tanpa tag, dan cache build. Ada dua opsi yang lebih agresif: -a ikut menghapus semua image yang tidak dipakai container, dan --volumes ikut menghapus volume yang tidak terpakai. Jangan pakai --volumes sebelum yakin, karena volume bisa berisi data database.

Log container juga sering terlupa. Cek ukuran file *-json.log di /var/lib/docker/containers/, lalu batasi lewat /etc/docker/daemon.json:

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

Pengaturan ini berlaku untuk container yang dibuat setelah Docker di-restart.

Langkah 6. Hapus paket dan kernel lama

sudo apt autoremove --purge
sudo apt clean

Di Ubuntu dan Debian, autoremove juga membuang kernel lama yang tidak lagi dibutuhkan, sambil menyisakan kernel yang sedang berjalan dan versi terbaru sebagai cadangan. Ini sering membebaskan ruang di /boot, yang biasanya partisinya kecil. Di keluarga Red Hat, jumlah kernel yang disimpan diatur lewat installonly_limit di /etc/dnf/dnf.conf.

Langkah 7. Pastikan logrotate bekerja

Log aplikasi yang tidak pernah dirotasi adalah penyebab paling umum disk penuh pelan-pelan. Buat aturan di /etc/logrotate.d/appku:

/var/log/appku/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    copytruncate
}

Uji dengan sudo logrotate -d /etc/logrotate.d/appku (mode simulasi). copytruncate berguna untuk aplikasi yang tidak bisa diberi sinyal untuk membuka ulang file log. Ini juga berlaku untuk log dari cron job yang kamu arahkan ke file.

Bagaimana kalau inode yang habis?

Inode habis berarti ada folder berisi file kecil dalam jumlah sangat besar. Penyebab umum: file sesi PHP yang tidak dibersihkan, cache aplikasi, antrean email, atau file sementara.

Cari folder dengan jumlah file terbanyak:

sudo du --inodes -x / 2>/dev/null | sort -n | tail -15

Setelah ketemu, hapus file lama di folder itu dengan find, misalnya file yang lebih tua dari 7 hari:

sudo find /var/lib/php/sessions -type f -mtime +7 -delete

Lalu cari tahu kenapa file itu tidak dibersihkan sendiri. Biasanya ada tugas pembersihan yang mati atau konfigurasi aplikasi yang keliru.

Ringkasan pemakan disk yang sering ditemui

Kalau setelah semua langkah disk memang terisi data yang sah, misalnya database dan unggahan pengguna yang terus bertambah, saatnya menambah kapasitas. Cara memperkirakan kebutuhannya dibahas di memilih spesifikasi VPS. Pasang juga peringatan pemakaian disk, misalnya di 80%, dengan alat seperti di pemantauan Uptime Kuma dan Grafana.

Saat disk penuh lagi, jalankan urutan ini:

• df -h dan df -i untuk tahu apa yang habis
• du atau ncdu untuk menemukan folder terbesar
• lsof +L1 untuk file terhapus yang masih terbuka
• Batasi journal dan log Docker
• apt autoremove --purge untuk paket dan kernel lama
• Pasang logrotate dan peringatan disk agar tidak terulang