Rutin Cek Akun Mendekati Disk Quota di WHM Sebelum Email Mulai Bounce

Ada satu pola tiket yang terus berulang di server shared hosting. Pelanggan bilang email ke domainnya bounce. Di hari yang sama, akun yang sama juga mengeluh upload gambar di WordPress gagal tanpa pesan jelas. Dua keluhan ini sering ditangani terpisah, padahal akar masalahnya biasanya satu: akun cPanel itu sudah mentok disk quota atau inode, dan tidak ada yang sadar sampai pelanggan komplain. Artikel ini disusun seperti post-mortem, tapi untuk pola umum yang sering muncul, bukan satu insiden tertentu. Tujuannya supaya kita bisa mengenali pola ini lebih cepat, lalu memindahkan pengecekan quota dari "reaktif saat ada tiket" menjadi rutinitas mingguan.

Dampak awal: dua keluhan yang kelihatannya tidak berhubungan

Gejala pertama biasanya datang dari sisi email. Pengirim dari luar menerima pesan bounce, atau email tidak kunjung masuk dan baru muncul bounce setelah beberapa jam. Pemilik domain sendiri sering tidak sadar, karena yang menerima bounce adalah orang lain. Gejala kedua muncul di website. Upload media gagal, plugin tidak bisa update, cache tidak bisa ditulis, atau muncul error yang menyebut "Disk quota exceeded" di error_log. Kadang login cPanel juga jadi aneh, karena cPanel butuh menulis file session dan file sementara di direktori home akun. Kalau dua tiket ini ditangani oleh dua orang berbeda, keduanya bisa menghabiskan waktu di jalur yang salah. Yang satu memeriksa SPF dan MX, yang lain memeriksa permission folder wp-content.

Jalur penelusuran yang sering salah arah

Untuk email bounce, refleks yang umum adalah mengecek DNS: MX record, SPF, mungkin reputasi IP. Itu wajar, tapi untuk email masuk yang gagal dikirim ke mailbox lokal, DNS biasanya sudah benar. Email sudah sampai ke server kita, lalu gagal saat Exim (mail server bawaan cPanel) mencoba menulisnya ke disk. Langkah yang lebih cepat adalah langsung melihat log Exim untuk domain itu, lalu mengecek quota akun pemiliknya. Di cPanel, log utama Exim ada di /var/log/exim_mainlog, dan exigrep membantu mengumpulkan semua baris yang berkaitan dengan satu pesan.

BASH

# Cari jejak pengiriman ke domain tertentu (read-only)
exigrep 'domainpelanggan.com' /var/log/exim_mainlog | tail -n 50

# Ringkasan quota semua user dalam format mudah dibaca
repquota -as

# Quota satu akun saja
quota -s -u namauser

Di log Exim, cari pesan yang menyebut quota atau kegagalan menulis file. Teks persisnya bisa berbeda tergantung konfigurasi, jadi jangan terpaku pada satu string. Yang penting adalah polanya: pengiriman lokal ditunda (defer) berulang kali, lalu setelah batas retry habis berubah menjadi bounce. Itu sebabnya pengirim sering baru dapat bounce beberapa jam kemudian. Di sisi website, error_log di folder situs biasanya sudah memberi petunjuk. Tapi tanpa melihat quota, orang sering mengira masalahnya permission atau bug plugin.

Titik terang: quota akun, bukan quota mailbox

Bagian ini yang paling sering membingungkan, baik untuk pelanggan maupun support baru. Di cPanel ada dua jenis batas yang berbeda. Pertama, quota mailbox, yaitu batas per akun email yang diatur pelanggan di menu Email Accounts. Kalau ini penuh, hanya mailbox itu yang menolak email. Kedua, quota disk akun cPanel, yaitu batas untuk seluruh user sistem. Semua file di /home/namauser dihitung di sini, termasuk website, database dump, backup, log, dan email di folder mail. Kalau quota ini penuh, semua mailbox di akun itu ikut gagal menerima email, meskipun quota mailbox masing-masing masih longgar. Website juga ikut tidak bisa menulis file. Lalu ada inode. Inode adalah entri di filesystem yang mewakili satu file atau folder, jadi limit inode sebenarnya adalah batas jumlah file. Akun bisa punya sisa ruang disk yang lumayan, tapi tetap tidak bisa membuat file baru karena jumlah file sudah mentok. Format maildir yang dipakai cPanel menyimpan setiap email sebagai satu file, jadi folder Trash dan spam yang tidak pernah dikosongkan bisa menghabiskan inode lebih cepat dari dugaan. Cache plugin WordPress dan file session PHP juga sering jadi penyumbang besar. Kalau repquota menunjukkan blok masih aman tapi kolom file (inode) mendekati batas, cari folder mana yang paling banyak isinya:

BASH

# Hitung jumlah inode per subfolder di home akun (read-only)
du --inodes -d 1 /home/namauser 2>/dev/null | sort -n | tail -n 15

# Lanjutkan ke folder yang paling besar, misalnya folder mail
du --inodes -d 2 /home/namauser/mail 2>/dev/null | sort -n | tail -n 15

Satu hal lagi: angka pemakaian disk di WHM List Accounts bisa tertinggal dari kondisi sebenarnya karena ada mekanisme cache. Kalau angka di WHM terlihat aman tapi gejalanya jelas quota, percayai output repquota atau quota di command line, karena itu membaca langsung dari sistem quota filesystem.

Mitigasi sementara supaya email masuk lagi

Prioritas pertama adalah membuat akun bisa menulis file lagi, supaya email yang masih di-defer sempat terkirim sebelum retry-nya habis. Cara tercepat biasanya menaikkan quota sementara lewat WHM di menu Quota Modification, tentu sesuai kebijakan paket dan setelah pelanggan diberi tahu. Ini bukan solusi, tapi memberi ruang napas. Setelah itu, bantu pelanggan mencari apa yang bisa dibersihkan. Kandidat yang umum adalah file backup lama di home directory (misalnya hasil backup manual atau file cpmove yang tertinggal), error_log yang membengkak, folder cache plugin, serta folder Trash dan spam di mailbox. Untuk file backup, pastikan dulu masih ada salinan lain yang valid sebelum dihapus. Kalau ragu soal kualitas backup, cara mengeceknya ada di artikel Cara Memastikan Backup WHM Benar-Benar Bisa Di-restore Sebelum Dibutuhkan. Penting: menghapus file di akun pelanggan tidak bisa dibatalkan. Konfirmasi dulu ke pemilik akun, terutama untuk email dan file backup. Jangan menghapus atas inisiatif sendiri hanya karena filenya terlihat besar. Setelah ruang tersedia, email yang masih ada di queue biasanya akan dicoba ulang otomatis sesuai jadwal retry Exim. Email yang sudah terlanjur bounce tidak akan kembali, jadi sampaikan ke pelanggan bahwa pengirim mungkin perlu mengirim ulang. Kalau angka quota terlihat tidak masuk akal setelah pembersihan, cPanel punya skrip /scripts/fixquotas untuk menghitung ulang quota. Skrip ini bisa cukup berat di server dengan banyak akun, jadi sebaiknya dijalankan di luar jam sibuk dan setelah membaca dokumentasinya untuk versi yang kamu pakai.

Perbaikan permanen: cek rutin, bukan menunggu tiket

Akar masalah di pola ini sebenarnya bukan quota yang penuh. Quota penuh itu wajar, akun memang tumbuh. Masalahnya adalah tidak ada yang melihat akun mendekati batas sampai sudah terlambat. Ada tiga lapis yang bisa dipasang. Lapis pertama adalah notifikasi bawaan. WHM punya pengaturan notifikasi di Contact Manager, termasuk peringatan saat akun mendekati batas disk. Cek apakah notifikasi ini aktif dan dikirim ke alamat yang benar-benar dibaca tim, bukan ke inbox root yang tidak pernah dibuka. Pelanggan juga bisa mengatur peringatan quota dari pengaturan kontak di cPanel mereka. Ambang dan opsi persisnya tergantung versi, jadi cek langsung di panel. Lapis kedua adalah cek mingguan dari command line. Notifikasi email gampang tenggelam, sedangkan daftar singkat yang dibaca rutin lebih sulit terlewat. Contoh di bawah menampilkan akun yang pemakaian bloknya sudah 80 persen atau lebih dari hard limit. Angka 80 hanya contoh, sesuaikan dengan kebiasaan tim.

BASH

# Read-only: akun dengan pemakaian blok >= 80% dari hard limit
# Output: namauser persen
repquota -a | awk '2 ~ /^[-+][-+]/ && 5 > 0 &&3 / 5 >= 0.8 { print1, int(3 * 100 /5) }' | sort -k2 -n -r

Filter ini sengaja hanya membaca kolom blok, karena posisi kolom inode bisa bergeser saat kolom grace terisi. Untuk inode, cek manual dengan repquota -as pada akun yang terlihat aneh, atau kembangkan skripnya setelah kamu memastikan format output di server sendiri. Hasilnya bisa dijadwalkan lewat cron dan dikirim ke kanal tim, tapi pastikan output-nya tetap pendek supaya benar-benar dibaca. Lapis ketiga adalah tindak lanjut yang jelas. Daftar akun hampir penuh tidak berguna kalau tidak ada yang menghubungi pelanggan. Biasanya cukup satu pesan proaktif: akun sudah mendekati batas, ini folder yang paling besar, ini pilihannya (bersihkan, atur retensi email, atau upgrade paket). Pelanggan umumnya lebih menerima pesan seperti ini dibanding penjelasan setelah email mereka bounce. Dari sisi support, kebiasaan kecil yang membantu adalah selalu mengecek quota akun di awal setiap tiket email bounce untuk domain yang dihosting di server sendiri, sebelum menyentuh DNS. Pengecekan ini cuma butuh beberapa detik dan sering langsung menjawab dua tiket sekaligus. Intinya, quota penuh adalah masalah yang bisa diprediksi. Pasang notifikasi yang benar-benar dibaca, jalankan repquota secara rutin, ingat bahwa inode bisa habis lebih dulu dari ruang disk, dan bedakan quota akun dari quota mailbox saat menjelaskan ke pelanggan. Dengan begitu, tiket bounce karena quota bisa berubah menjadi pesan proaktif yang dikirim sebelum ada yang komplain.