Untuk disk server penuh cara mengatasi yang aman: cari dulu apa yang memakan ruang dengan `du`, jangan langsung menghapus. Tersangka paling sering adalah log yang tidak dirotasi, cadangan lama yang menumpuk di server yang sama, dan berkas sementara aplikasi.
Disk penuh punya sifat yang membuatnya lebih merepotkan dari kelihatannya: gejalanya muncul di tempat lain. Basis data berhenti menerima penulisan, situs menampilkan kesalahan aneh, email tidak terkirim — dan tidak satu pun pesan errornya menyebut soal disk.
Yang berbahaya justru penanganannya. Menghapus berkas secara terburu-buru pada server yang panik adalah cara yang cukup andal untuk mengubah gangguan menjadi kehilangan data.
Pastikan dulu: ruang habis, atau inode habis
Ada dua cara disk menjadi penuh, dan penanganannya berbeda. Jalankan keduanya: `df -h` untuk ruang, `df -i` untuk inode.
Kehabisan inode di server terjadi ketika jumlah berkas mencapai batas meski ukurannya kecil. Penyebab khasnya satu direktori berisi ratusan ribu berkas — sesi PHP yang tidak pernah dibersihkan, cache yang menumpuk, atau antrean email yang gagal terkirim.
Gejalanya identik dengan disk penuh: aplikasi gagal menulis. Bedanya `df -h` menunjukkan ruang masih longgar, yang membuat orang mencari di tempat yang salah selama berjam-jam.
Cari file besar di linux dengan urutan yang benar
Cara paling efisien cari file besar di linux adalah menelusuri dari atas ke bawah, bukan mencari berkas besar di seluruh sistem sekaligus.
Mulai dari `du -h --max-depth=1 / | sort -hr | head`. Ini menunjukkan direktori tingkat pertama mana yang paling besar. Masuk ke yang terbesar, ulangi perintah yang sama di sana. Dalam tiga sampai empat langkah Anda biasanya sudah menemukan sumbernya.
Untuk inode, perintahnya berbeda: `find /var -xdev -type f | cut -d/ -f2-4 | sort | uniq -c | sort -nr | head` menghitung jumlah berkas per direktori, bukan ukurannya.
Tempat yang paling sering menjadi sumber: `/var/log` untuk log, `/var/lib/mysql` untuk data dan log biner basis data, `/var/backups` atau direktori cadangan buatan sendiri, `/tmp`, dan direktori cache aplikasi.
du dan df beda hasil: penjelasannya
Situasi du dan df beda hasil cukup sering membingungkan: `df` mengatakan disk 95 persen penuh, tetapi `du` yang menjumlahkan seluruh berkas hanya menemukan separuhnya.
Penyebab paling umum: ada berkas yang sudah dihapus tetapi masih dibuka oleh sebuah proses. Sistem belum membebaskan ruangnya karena proses itu masih memegangnya. Ini khas terjadi pada berkas log yang dihapus manual tanpa memberi tahu layanan yang menulisnya.
Cara memastikannya: `lsof +L1` menampilkan berkas terhapus yang masih terbuka. Perbaikannya bukan menghapus lagi, melainkan memuat ulang layanan yang memegangnya — dan ruangnya langsung kembali.
Penyebab lain yang lebih jarang: ruang yang dicadangkan untuk root pada sistem berkas ext4, biasanya lima persen. Itu sengaja disisakan supaya sistem tetap bisa beroperasi saat penuh.
Berkas terhapus tapi disk tetap penuh dan kasus serupa
Kondisi berkas terhapus tapi disk tetap penuh yang dijelaskan di atas adalah satu dari beberapa jebakan yang membuat pembersihan terasa tidak berhasil. Beberapa lain yang perlu diketahui:
- Snapshot sistem berkas — pada ZFS atau LVM, menghapus berkas tidak membebaskan ruang selama snapshot lama masih menyimpannya.
- Log biner MySQL — jangan dihapus manual, pakai `PURGE BINARY LOGS` supaya basis data tetap konsisten.
- Direktori yang ditumpangi mount lain — berkas di bawahnya tidak terlihat oleh `du` tetapi tetap memakan ruang.
- Cadangan yang ditulis ke disk yang sama dengan datanya, sehingga membersihkannya juga menghapus jaring pengaman Anda.
- Docker: image, container mati, dan volume tak terpakai bisa memakan puluhan gigabita. `docker system df` menunjukkan rinciannya.
Log rotate tidak jalan: penyebab paling sering nomor satu
Kalau ditemukan satu berkas log berukuran belasan gigabita, penyebabnya bukan trafik tinggi — penyebabnya log rotate tidak jalan.
Periksa dengan `logrotate -d /etc/logrotate.conf` yang menjalankannya dalam mode uji tanpa mengubah apa pun. Keluarannya menyebutkan berkas mana yang seharusnya dirotasi dan kenapa tidak.
Dua penyebab paling sering: berkas konfigurasi untuk aplikasi tertentu tidak pernah dibuat sehingga lognya tidak masuk cakupan, atau ada kesalahan pada salah satu konfigurasi yang menghentikan seluruh proses rotasi. Yang kedua ini jahat karena satu berkas rusak membuat semua log berhenti dirotasi.
Untuk aplikasi yang menulis log sendiri di luar `/var/log`, rotasinya perlu ditambahkan manual. Ini yang paling sering terlewat pada aplikasi buatan vendor.
Yang aman dihapus, dan yang jangan disentuh
Saat disk penuh dan layanan sedang mati, godaan untuk menghapus apa pun yang besar sangat kuat. Beberapa batas yang layak dipegang.
Aman: log lama yang sudah dikompres, cache paket sistem, image dan container Docker yang tidak dipakai, berkas di `/tmp` yang lebih tua dari beberapa hari, dan cadangan yang Anda tahu sudah punya salinan di tempat lain.
Jangan disentuh tanpa memahami akibatnya: apa pun di dalam direktori data basis data, log biner basis data, berkas sistem, dan cadangan yang tidak punya salinan lain. Untuk yang terakhir, pindahkan alih-alih menghapus — meski itu berarti menyalinnya ke tempat lain lebih dulu.
Kalau ruang sudah sangat kritis dan tidak ada yang aman dihapus, langkah tercepat biasanya menambah volume baru dan memindahkan satu direktori besar ke sana. Itu lebih lambat daripada menghapus, tapi tidak bisa membuat keadaan lebih buruk.
Mencegah dengan tiga hal yang jarang dikerjakan
Disk penuh hampir selalu bisa dicegah, dan pencegahannya tidak menuntut perangkat tambahan.
Pertama, peringatan berdasarkan tren, bukan hanya ambang. Peringatan pada 80 persen berguna, tetapi peringatan "disk akan penuh dalam tujuh hari pada laju sekarang" jauh lebih berguna karena memberi waktu bertindak tanpa terburu-buru.
Kedua, batas retensi yang tertulis untuk setiap hal yang tumbuh: log aplikasi, cadangan, arsip, log basis data. Tanpa angka yang disepakati, tidak ada yang berani menghapus apa pun — dan semuanya menumpuk.
Ketiga, pisahkan data yang tumbuh dari partisi sistem. Kalau log dan cadangan berada di volume tersendiri, disk yang penuh hanya menghentikan penulisan log — bukan membuat seluruh sistem operasi tidak bisa bekerja. Ini satu keputusan saat pemasangan yang menghemat banyak kepanikan kemudian.