Apa Itu Inode & Cara Mengatasi Inode Exhaustion di Server

Pendahuluan

Beberapa waktu lalu saya dapat emergency call dari client: “Semua website mati! cPanel tidak bisa diakses, bahkan SSH juga timeout!” Begitu saya cek dari sisi server, situasinya lebih parah dari yang saya bayangkan — inode usage sudah 100%. Bukan disk space yang penuh, tapi jumlah inode yang sudah habis. Dan ketika inode habis, kamu tidak bisa membuat file baru — termasuk file log, file session, file temporary, bahkan file konfigurasi yang dibutuhkan oleh web server dan service lainnya.

Yang bikin situasi makin kritis, client ini host 40+ website di satu shared hosting. Satu website yang tidak terawat — dengan error_log yang terus bertambah tanpa rotasi — sudah cukup untuk menghabiskan seluruh inode quota server. Dalam waktu kurang dari 6 jam, semua website di server tersebut down total.

Dari pengalaman itu, saya belajar satu hal: inode exhaustion itu lebih berbahaya dari disk space penuh. Karena ketika disk space penuh, kamu masih bisa menghapus file lama untuk buat ruang. Tapi ketika inode habis, bahkan menghapus file pun tidak bisa — karena proses hapus juga membutuhkan inode. Satu-satunya cara adalah menemukan direktori mana yang paling banyak menahan inode, lalu menguranginya secara agresif.

Apa Itu Inode?

Sebelum masuk ke troubleshooting, penting untuk memahami apa itu inode dan kenapa inode bisa habis.

Inode Adalah “Identitas” Setiap File

Di Linux/Unix, setiap file dan direktori punya nomor unik yang disebut inode. Inode menyimpan informasi tentang file: siapa pemiliknya, kapan dibuat, kapan terakhir diakses, ukurannya, dan di mana blok data-nya berada di disk. Nama file yang kamu lihat di ls sebenarnya hanyalah “label” yang menunjuk ke inode tertentu.

Analoginya sederhana: bayangkan sebuah gedung apartemen. Setiap unit apartemen punya nomor (itu inode-nya). Nama pemilik (nama file) bisa berubah, tapi nomor unit (inode) tetap sama. Ketika gedang sudah kehabisan nomor unit, meskipun masih ada ruang kosong di koridor, kamu tidak bisa menambah unit baru.

Inode vs Disk Space

Banyak yang salah paham bahwa “disk space penuh” dan “inode habis” itu sama. Tidak. Keduanya masalah yang berbeda:

• Disk space penuh — ukuran total file sudah mencapai batas kapasitas disk. File besar seperti video, backup, atau database yang memakan space.
• Inode habis — jumlah file sudah mencapai batas, meskipun ukuran total file masih kecil. Ribuan file kecil (log, cache, session, temporary) bisa menghabiskan inode tanpa memakan banyak space.

Contoh konkret: satu file log berukuran 1GB hanya menggunakan 1 inode. Tapi 1 juta file log berukuran 1KB masing-masing menggunakan 1 juta inode. Inilah kenapa server cPanel yang menghost banyak website sangat rentan terhadap inode exhaustion — setiap website bisa menghasilkan ratusan file kecil per hari (log, cache, session).

Quota Inode di Hosting cPanel

Di hosting cPanel, setiap akun biasanya diberi quota inode tertentu — misalnya 250.000 atau 500.000 inode. Quota ini ditentukan oleh penyedia hosting dan bisa dicek dari cPanel → Quota Usage. Ketika jumlah inode mencapai batas quota, kamu tidak bisa membuat file baru sampai mengurangi jumlah file yang ada.

Gejala Inode Exhaustion

Inode exhaustion punya gejala yang sangat khas dan bisa dikenali dengan mudah jika kamu tahu apa yang harus dicari:

• Error “No space left on device” meskipun disk space masih ada — ini gejala paling klasik. df -h menunjukkan disk space masih 50% kosong, tapi kamu tidak bisa membuat file baru.
• cPanel/WHM tidak bisa diakses — cPanel membutuhkan file temporary untuk beroperasi. Ketika inode habis, cPanel tidak bisa membuat file temporary dan akhirnya crash.
• Web server (Apache/Nginx) mati — web server membutuhkan file log dan file temporary. Tanpa inode, web server tidak bisa menulis log dan akhirnya berhenti.
• MySQL/MariaDB mati — database server membutuhkan file temporary untuk query dan sorting. Ketika inode habis, operasi database gagal.
• Email tidak bisa dikirim/diterima — mail server membutuhkan file queue dan log. Tanpa inode, email stuck di queue dan akhirnya dibuang.
• SSH timeout atau tidak bisa login — beberapa sistem membutuhkan file temporary untuk autentikasi SSH. Ketika inode habis, SSH juga terpengaruh.
• Error “Too many links” di direktori — direktori dengan jumlah file sangat banyak bisa mencapai batas link, yang juga berhubungan dengan inode.

Cara Cek Inode Usage

Command #1: Cek Inode Usage Server

Command pertama dan paling penting adalah mengecek berapa inode yang sudah terpakai dan berapa yang masih tersedia:

df -i

Contoh output saat normal:

Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda1       655360  452340  203020   69% /
tmpfs            40960       2   40958    1% /dev/shm

Contoh output saat inode habis:

Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda1       655360  655360      0  100% /
tmpfs            40960       2   40958    1% /dev/shm

Perhatikan kolom IFree dan IUse%. Ketika IFree = 0 dan IUse% = 100%, server kamu sudah kehabisan inode. Semua operasi pembuatan file akan gagal.

Command #2: Temukan Error Log Terbesar

Salah satu penyebab paling umum inode exhaustion di server cPanel adalah error_log yang tidak di-rotate. File error_log yang terus bertambah tanpa batas bisa menghabiskan ribuan inode. Berikut command untuk menemukan error_log terbesar:

find . -name 'error_log' -exec du -ch {} + | grep total

Mari kita bedah command ini:

Penjelasan Tiap Bagian

1. find . — Mulai pencarian dari direktori saat ini (.). Kamu bisa ganti dengan path spesifik seperti /home/username atau /home untuk pencarian lebih luas.

2. -name 'error_log' — Filter pencarian: hanya file dengan nama persis error_log. Ini menangkap file log error dari PHP, Apache, dan aplikasi lain yang menggunakan nama default ini.

3. -exec du -ch {} + — Untuk setiap file yang ditemukan, jalankan du -ch (disk usage, cumulative, human-readable). Flag -c menambahkan baris total di akhir, -h membuat output dalam format yang mudah dibaca (KB, MB, GB).

4. | grep total — Hanya tampilkan baris yang mengandung kata “total” — yaitu baris ringkasan yang menunjukkan total ukuran semua error_log yang ditemukan.

Contoh Output

find . -name 'error_log' -exec du -ch {} + | grep total
 4.2G    ./public_html/error_log
 1.8G    ./public_html/subdomain/error_log
 892M    ./public_html/blog/error_log
 127M    ./public_html/forum/error_log
 7.0G    total

Dari output ini, sudah sangat jelas: ada 7GB total error_log di server ini. File-file inilah yang menghabiskan inode. Perhatikan bahwa masing-masing error_log juga menambah jumlah inode — setiap file menempati 1 inode, dan di direktori yang sama, setiap subdirektori juga menempati 1 inode.

Command #3: Temukan Direktori Paling Banyak Menahan Inode

Selain error_log, ada banyak jenis file lain yang bisa menghabiskan inode. Untuk menemukan direktori mana yang paling banyak menahan inode, gunakan command ini:

find . -xdev -printf '%hn' | sort | uniq -c | sort -rn | head -10

Penjelasan:

• find . -xdev — Cari semua file di direktori saat ini, tapi jangan melangkahi filesystem lain (-xdev). Ini mencegah pencarian ke direktori mount lain seperti /proc atau /dev.
• -printf '%hn' — Untuk setiap file yang ditemukan, cetak nama direktori induknya (%h = head/path). Jadi kita mendapatkan list direktori, satu baris per file.
• | sort | uniq -c — Hitung jumlah kemunculan setiap direktori — yaitu jumlah file di direktori tersebut.
• | sort -rn | head -10 — Urutkan dari yang terbanyak dan tampilkan 10 teratas.

Contoh Output

  127845 /home/username/public_html/wp-content/cache
   89234 /home/username/public_html/wp-content/uploads
   45678 /home/username/public_html/tmp
   23456 /home/username/public_html/wp-content/plugins/akismet
   12345 /home/username/public_html/error_logs
    8901 /home/username/public_html/wp-content/uploads/2024
    5678 /home/username/public_html/wp-content/uploads/2023
    3456 /home/username/public_html/logs
    2345 /home/username/public_html/tmp/sessions
    1234 /home/username/public_html/cache

Dari output ini, direktori wp-content/cache menahan 127.845 inode — itu hampir setengah dari quota 250.000 inode! Ini adalah direktori caching WordPress yang tidak pernah dibersihkan.

Command #4: Cek Inode per File Type

Untuk memahami jenis file apa yang paling banyak menahan inode:

find . -xdev -type f | sed 's/.*.//' | sort | uniq -c | sort -rn | head -10

Penjelasan:

• find . -xdev -type f — Cari semua file (bukan direktori) di filesystem yang sama.
• sed 's/.*.//' — Ekstrak ekstensi file dari path. Misalnya /path/to/error.log menjadi log.
• sort | uniq -c | sort -rn | head -10 — Hitung dan urutkan berdasarkan jumlah terbanyak.

Contoh Output

  234567 log
  123456 php
   89012 txt
   56789 html
   34567 png
   23456 jpg
   12345 css
    8901 js
    5678 xml
    3456 json

File dengan ekstensi .log menempati urutan pertama dengan 234.567 file — ini sudah lebih dari quota inode 250.000. Mayoritas file log inilah yang menjadi penyebab utama inode exhaustion.

Cara Mengatasi Inode Exhaustion

⚠️ PERINGATAN KEAMANAN: Backup Sebelum Cleanup

Sebelum melakukan cleanup massal, WAJIB backup dulu file yang masih dibutuhkan. Cleanup inode yang salah bisa menghapus data penting yang tidak bisa dikembalikan.

# Backup database
mysqldump --all-databases > /tmp/all-databases-backup-$(date +%Y%m%d-%H%M).sql

# Backup file konfigurasi penting
cp -r /home/username/public_html/wp-config.php /tmp/
cp -r /home/username/public_html/.htaccess /tmp/

# Backup list file untuk referensi
find /home/username -type f > /tmp/all-files-list-$(date +%Y%m%d-%H%M).txt

Verifikasi backup berhasil:

ls -lh /tmp/all-databases-backup-*.sql
wc -l /tmp/all-files-list-*.txt

Solusi 1: Hapus Error Log yang Sudah Tidak Diperlukan

Ini solusi paling cepat dan efektif untuk inode exhaustion. Error_log yang besar dan tidak di-rotate adalah penyebab nomor satu:

# Cek dulu error_log mana yang paling besar
find /home/username -name 'error_log' -exec du -h {} + | sort -rh | head -10

# Hapus error_log yang sudah tidak diperlukan
# ⚠️ PASTIKAN error_log tersebut bukan log yang masih dibutuhkan untuk debugging
find /home/username -name 'error_log' -delete

⚠️ PENTING: Jangan hapus error_log jika kamu sedang debugging masalah tertentu. Hapus error_log hanya jika kamu sudah selesai debugging atau error_log tersebut memang sudah tidak dibutuhkan.

Solusi 2: Bersihkan Cache WordPress

Jika kamu menggunakan WordPress, direktori wp-content/cache bisa menahan ratusan ribu file cache yang sudah tidak relevan:

# Hapus semua file cache WordPress
find /home/username/public_html/wp-content/cache -type f -delete

# Atau hapus semua isi direktori cache
rm -rf /home/username/public_html/wp-content/cache/*

Verifikasi:

# Cek apakah inode sudah berkurang
df -i / | tail -1

# Cek apakah direktori cache masih ada
ls -la /home/username/public_html/wp-content/cache/

Solusi 3: Bersihkan File Temporary dan Session

File session PHP dan file temporary juga bisa menahan banyak inode:

# Hapus file session yang sudah lebih dari 7 hari
find /tmp -name "sess_*" -type f -mtime +7 -delete

# Hapus file temporary PHP yang sudah lama
find /tmp -name "*.tmp" -type f -mtime +7 -delete

# Hapus file cache yang tidak aktif
find /home/username/public_html/tmp -type f -mtime +30 -delete

Solusi 4: Bersihkan Backup dan Archive Lama

File backup yang sudah tidak dibutuhkan juga menahan inode:

# Cari file backup besar
find /home/username -name "*.bak" -o -name "*.backup" -o -name "*.tar.gz" -o -name "*.zip" | head -20

# Hapus backup lama (lebih dari 30 hari)
find /home/username -name "*.bak" -mtime +30 -delete
find /home/username -name "*.backup" -mtime +30 -delete
find /home/username -name "*.tar.gz" -mtime +30 -delete

Solusi 5: Bersihkan Cache cPanel dan WHM

cPanel dan WHM juga menyimpan file cache yang bisa menahan inode:

# Bersihkan cache cPanel
rm -rf /home/username/.cpanel/cache/*

# Bersihkan cacheea (jika ada)
rm -rf /home/username/.cpanel/ea4/cache/*

# Bersihkan log cPanel lama
find /home/username/logs -name "*.log" -mtime +30 -delete

Solusi 6: Konfigurasi Logrotate

Setelah berhasil mengatasi inode exhaustion, langkah selanjutnya adalah mencegah agar tidak terjadi lagi. Konfigurasi logrotate untuk semua file log:

# Buat konfigurasi logrotate untuk error_log
cat > /etc/logrotate.d/error_log << 'EOF'
/home/*/public_html/error_log {
    daily
    missingok
    rotate 7
    compress
    delaycompress
    notifempty
    create 644 nobody nobody
}
EOF

Atau kalau kamu menggunakan cPanel, bisa menggunakan fitur log rotation bawaan cPanel → cPanel → Metrics → Metrics → Errors.

Pro Tips: Pencegahan Inode Exhaustion

1. Monitor inode usage secara berkala — buat cron job untuk alert: 0 */6 * * * USAGE=$(df -i / | tail -1 | awk '{print $5}' | tr -d '%'); [ $USAGE -gt 80 ] && echo "ALERT: Inode usage at $USAGE%" | mail -s "Inode Alert" admin@domain.com
2. Gunakan logrotate untuk semua file log — pastikan semua log yang aktif ditulis sudah dikonfigurasi logrotate. Terutama error_log, access_log, dan file log aplikasi.
3. Bersihkan cache secara berkala — buat cron job untuk menghapus file cache yang sudah lama: 0 2 * * * find /home/*/public_html/wp-content/cache -type f -mtime +7 -delete
4. Batasi jumlah file per direktori — beberapa aplikasi seperti email atau file storage bisa menghasilkan ribuan file kecil. Pertimbangkan untuk membatasi jumlah file atau menggunakan alternatif penyimpanan.
5. Gunakan tmpfs untuk file temporary — mount /tmp sebagai tmpfs (RAM-based) untuk file temporary. File di tmpfs tidak menempati inode di filesystem utama.
6. Set quota inode per akun — jika kamu mengelola server cPanel, pertimbangkan untuk menetapkan quota inode per akun untuk mencegah satu akun menghabiskan semua inode server.
7. Audit file secara berkala — minimal sebulan sekali, cek direktori mana yang paling banyak menahan file dan bersihkan yang tidak diperlukan.

FAQ

Bagaimana cara menambah quota inode di server cPanel?

Quota inode biasanya ditentukan oleh penyedia hosting dan tidak bisa diubah sendiri oleh user. Jika kamu mengelola server sendiri (VPS/dedicated), kamu bisa menambah quota inode dengan membuat filesystem baru dan mount ke direktori yang membutuhkan lebih banyak inode. Tapi cara yang lebih baik adalah mengurangi jumlah file yang tidak perlu — karena menambah inode artinya menambah filesystem baru yang juga membutuhkan manajemen tambahan.

Apakah menghapus error_log aman?

Ya, menghapus error_log pada umumnya aman. Error_log hanya berisi informasi debugging dan error yang sudah terjadi. Setelah error diperbaiki, error_log lama tidak lagi dibutuhkan. Tapi pastikan kamu tidak sedang dalam proses debugging masalah tertentu — karena error_log mungkin berisi petunjuk yang dibutuhkan untuk menemukan root cause.

Kenapa df -h menunjukkan space masih kosong tapi tidak bisa buat file baru?

Karena masalahnya bukan di disk space, tapi di inode. df -h menampilkan penggunaan disk space (ukuran dalam bytes). Untuk mengecek inode, gunakan df -i. Jika df -i menunjukkan IUse% = 100%, maka inode sudah habis meskipun space masih kosong.

Berapa banyak inode yang aman untuk server cPanel?

Sebagai aturan umum, pertahankan inode usage di bawah 80%. Jika mendekati 90%, segera lakukan audit dan cleanup. Untuk server shared hosting dengan banyak akun, pertimbangkan untuk menetapkan per-akun quota inode (misalnya 250.000 per akun) untuk mencegah satu akun menghabiskan semua inode server.

Related Issues

• Cara Mendeteksi & Membebaskan Disk Space dari File Terhapus di Linux — file terhapus yang masih dipegang proses juga bisa menahan space dan inode
• Cara Troubleshoot Database Load Tinggi di MariaDB — database load tinggi bisa memicu banyak error yang menghasilkan error_log besar
• Cara Mengatasi Apache Slot Penuh (503 Service Unavailable) — Apache slot penuh sering terjadi bersamaan dengan inode exhaustion karena log yang terus bertambah

Kesimpulan

Inode exhaustion adalah masalah yang sering diabaikan sampai terjadi — dan ketika terjadi, dampaknya bisa sangat parah: semua website down, service mati, dan kamu bahkan tidak bisa menghapus file untuk recovery. Dengan df -i dan find . -name 'error_log' -exec du -ch {} + | grep total, kamu bisa mendeteksi masalah ini sebelum terlambat.

Yang terpenting, pencegahan selalu lebih baik daripada treatment. Konfigurasi logrotate, monitor inode usage secara berkala, dan bersihkan cache secara berkala. Jangan menunggu sampai inode habis dan semua website down — percaya deh, saya pernah ngalamin di tengah malam dan tidak mau ngalamin lagi.