cPanel Disk Kullanımı Yanlış Görünüyor Sorunu Nasıl Çözülür?

cPanel disk kullanımı yanlış görünüyor sorunu; cPanel’deki kullanılan alanın SSH ile görülen du çıktısından, WHM kota bilgisinden veya dosya sistemindeki boş alandan farklı olmasıdır. Bu fark, yalnızca bir ekran yenileme problemi değildir: e-posta kutuları, inode sınırı, eski kota kayıtları, silinmiş fakat süreçlerce hâlâ açık tutulan dosyalar ya da farklı bir dosya sistemi üzerinde duran veriler buna neden olabilir. Önce farkın hangi iki ölçüm arasında oluştuğunu belirlemek, ardından salt-okunur komutlarla alanın gerçek kaynağını bulmak gerekir. Bu rehber, cPanel disk kullanımı yanlış görünüyor durumunu paylaşımlı hosting, reseller ve root erişimli cPanel/WHM sunucularında güvenli biçimde teşhis etmeye odaklanır.

Belirti ve kapsam: Hangi değer birbiriyle uyuşmuyor?

Teşhise başlamadan önce karşılaştırdığınız ekranları not edin. Çünkü cPanel, WHM, Linux kota araçları ve df/du komutları aynı kavramı ölçmeyebilir.

Karşılaştırılan değerler	Muhtemel açıklama	İlk kontrol
cPanel Disk Usage yüksek, du düşük	Kota bilgisi eski, farklı dizin/mount noktası, veritabanı veya posta verisi	Ev dizini, posta dizini ve kota durumu
df dolu, du düşük	Silinmiş ancak açık dosya, inode tüketimi veya dosya sistemine ait başka veri	lsof +L1, df -i
cPanel alanı normal, yeni dosya/e-posta yazılamıyor	Inode limiti, gerçek kota limiti veya dosya sistemi doluluğu	Inode ve kota kontrolü
WHM ile cPanel farklı gösteriyor	Kota taraması/kayıtları güncel değil veya ölçüm kapsamı farklı	WHM kota ve dosya sistemi doğrulaması

Önemli ayrım: df bir dosya sisteminin toplam doluluğunu gösterir. du seçtiğiniz dizin ağacındaki erişilebilir dosyaları toplar. cPanel/WHM ise hesap kotası, e-posta, veritabanı yerleşimi ve sunucu yapılandırmasına göre farklı bir kapsam gösterebilir. Bu nedenle tek bir komut sonucuna bakarak “cPanel hatalı” sonucuna varmayın.

Hızlı teşhis özeti

• Önce etkilenen cPanel kullanıcısını ve farkın görüldüğü ekranları belirleyin.
• Dosya sistemi alanını ve inode kullanımını df ile kontrol edin.
• Kullanıcının ev dizinini, posta verisini ve büyük dosyalarını du ile ayırın.
• Root erişimi varsa kullanıcının kota kaydını inceleyin.
• df yüksek, du düşükse silinmiş-açık dosyaları araştırın.
• Yalnızca neden doğrulandıktan sonra kota onarımı, servis yeniden başlatma veya veri temizliği yapın.

cPanel disk kullanımı yanlış görünüyor: Olası nedenler

E-posta kutuları ve çöp klasörleri

cPanel hesaplarında e-posta verisi çoğunlukla kullanıcının ev dizini altındaki mail yapısında tutulur. Özellikle IMAP hesaplarında cur, new ve .Trash klasörleri büyüyebilir. Kullanıcı Dosya Yöneticisi’nde yalnızca public_html dizinine bakarsa, toplam kullanımın neden yüksek olduğunu göremez.

Inode sınırının dolması

Diskte gigabayt düzeyinde boş alan olsa bile çok sayıda küçük dosya inode tüketebilir. Önbellek dosyaları, oturum kayıtları, yedek arşivleri ve e-posta mesajları bu duruma sık neden olur. Inode sorunu, “disk dolu” benzeri yazma hataları oluşturabilir; ancak kullanılan GB değeri beklenenden düşük görünür.

Silinmiş fakat hâlâ açık tutulan dosyalar

Bir günlük dosyası veya geçici dosya silindiğinde, onu açık tutan PHP, web sunucusu, kuyruk ya da başka bir süreç varsa alan hemen serbest kalmayabilir. Dosya dizinde görünmez ve du ile hesaplanmaz; buna karşın df alanı dolu göstermeye devam eder. Süreci güvenle yeniden başlatmak veya sonlandırmak, dosyanın gerçekten serbest bırakılmasını sağlar.

Kota kayıtlarının dosya sistemiyle eşleşmemesi

Sunucu kesintisi, disk taşıma işlemi, dosya sistemi sorunu veya kota altyapısındaki uyumsuzluk sonrasında WHM/cPanel kota bilgisi güncel olmayabilir. Bu senaryoda kullanıcı gerçekte boş alanı olduğu hâlde kota aşımı uyarısı alabilir veya tersi yaşanabilir. Kota onarımı root yetkisi ve bakım planlaması gerektirir.

Ev dizini dışındaki veriler ve farklı mount noktaları

MySQL/MariaDB veri dizini çoğu sunucuda /var/lib/mysql altında, yani hesabın ev dizininden ayrı bir dosya sisteminde bulunabilir. Benzer biçimde yedekleme alanları, bind mount noktaları veya özel uygulama dizinleri farklı hesaplama sonuçları doğurabilir. Veritabanı boyutunu doğrudan bir kullanıcı hesabına bağlamadan önce cPanel/WHM eşlemesini ve sunucu yerleşimini doğrulayın.

Log ve komutlarla güvenli teşhis

Aşağıdaki komutlar veri değiştirmez. SSH erişiminiz yoksa cPanel Dosya Yöneticisi’nden özellikle mail, gizli dosyalar ve uygulama yedekleri için inceleme yapın. Root gerektiren kontrolleri yalnızca sunucu yöneticisi uygulamalıdır.

1. Dosya sistemi alanı ve inode durumunu kontrol edin

Linux üzerinde, kullanıcının ev dizininin bulunduğu dosya sistemini kontrol edin. /home ayrı bir mount noktası değilse sonuç kök dosya sistemini gösterebilir; bu normaldir.

df -hT /home
df -i /home

Use% veya inode kullanım yüzdesi %100’e yakınsa, sorun yalnızca ilgili cPanel hesabından değil aynı dosya sistemini kullanan başka hesaplardan ya da sistem verilerinden de kaynaklanabilir.

2. Hesabın ev dizinindeki gerçek kullanımı ayırın

Aşağıdaki örnekte KULLANICI kısmını cPanel kullanıcı adıyla değiştirin. -x parametresi, bağlı başka dosya sistemlerine geçişi engeller.

du -xsh /home/KULLANICI
du -xhd1 /home/KULLANICI | sort -h
find /home/KULLANICI -xdev -type f -size +500M -printf '%s %p\n' | sort -n

İkinci komut hangi üst dizinin büyüdüğünü gösterir. Son komut, 500 MB üzerindeki dosyaları listeler. Çıktıda uygulama yedeği, hata günlüğü veya eski arşiv görürseniz hemen silmek yerine dosyanın gerekli olup olmadığını ve güncel bir yedeğin bulunduğunu doğrulayın.

3. E-posta kullanımını ayrıca inceleyin

du -xsh /home/KULLANICI/mail
du -xhd2 /home/KULLANICI/mail | sort -h

Bir posta kutusu veya .Trash gibi bir klasör öne çıkıyorsa, kullanıcıyla saklama politikasını doğrulayın. cPanel’de E-posta Disk Kullanımı ekranı uygunsa, iletileri klasör ve hesap bazında yönetmek daha kontrollü bir yöntemdir.

4. Root erişimiyle kota değerini karşılaştırın

Kota sistemi etkin Linux/cPanel sunucularında aşağıdaki komut hesabın blok ve inode kotasını gösterebilir:

quota -s KULLANICI

Komut “quota not enabled” benzeri bir sonuç verirse, sunucuda kota altyapısı etkin olmayabilir veya kullanılan dosya sistemi kota desteklemiyor olabilir. Bu durumda sonucu zorla değiştirmeye çalışmayın; önce WHM sunucu yapılandırmasını ve dosya sistemi tasarımını değerlendirin.

5. Silinmiş ve açık dosyaları bulun

Bu kontrol root yetkisi gerektirir. Özellikle df dolu iken hesap dizinlerinin du toplamı düşükse önemlidir.

lsof +L1

Çıktıda deleted olarak işaretlenen büyük dosyaları, ilgili PID ve süreç adıyla değerlendirin. Süreç bir web, veritabanı veya posta hizmetine aitse tüm sistemi etkilememek için rastgele kill -9 kullanmayın. Önce hangi uygulamanın dosyayı açık tuttuğunu belirleyin; ardından bakım penceresinde yalnızca ilgili hizmetin kontrollü yeniden başlatılmasını planlayın.

Güvenli adım adım çözüm

1. Veri silmeden önce yedek ve bakım penceresi oluşturun

Yedek arşivleri, e-posta mesajları, uygulama dosyaları veya veritabanlarıyla ilgili temizlik yapmadan önce geri dönüş planınız olmalıdır. Üretim sitelerinde bakım penceresi belirleyin. Veritabanı boyutu şüpheliyse doğrudan tablo dosyası silmeyin; tutarlı bir dump/yedek alın ve uygulama sahibinin onayını alın.

2. Gerçek alan tüketen veriyi kontrollü azaltın

Teşhis sonucu doğrulanmışsa en güvenli sıra şöyledir:

1. Artık gerekli olmayan, doğrulanmış eski uygulama yedeklerini kaldırın veya harici depoya taşıyın.
2. E-posta için Çöp, Spam ve gereksiz eski iletileri kullanıcı onayıyla temizleyin.
3. Uygulamanın ürettiği geçici dosya ve önbellekleri, uygulamanın kendi temizleme yöntemiyle yönetin.
4. Büyük günlük dosyalarında, günlük döndürme politikasını düzeltin; aktif günlük dosyasını silmek yerine ilgili servis ve logrotate yapılandırmasını gözden geçirin.

Bir dosya silindikten sonra df değeri değişmiyorsa, silinmiş-açık dosya senaryosuna geri dönün. Bu durumda alan ancak ilgili süreç dosya tanıtıcısını kapattığında serbest kalır.

3. Kota uyuşmazlığı doğrulandıysa cPanel kota onarımını çalıştırın

Yalnızca root erişiminiz varsa, kota özelliğinin desteklendiğini doğruladıysanız ve gerçek disk tüketimini incelediyseniz cPanel’in kota onarım betiğini kullanabilirsiniz. Bu işlem sunucudaki hesapların kota kayıtlarını yeniden oluşturabilir; yoğun veya çok hesaplı sistemlerde bakım penceresinde uygulanmalıdır.

/usr/local/cpanel/scripts/fixquotas

Betik tamamlandıktan sonra WHM’de hesap kota bilgisini ve kullanıcı tarafında cPanel Disk Usage ekranını yeniden kontrol edin. İşlem hata verirse aynı komutu tekrar tekrar çalıştırmak yerine hata çıktısını, dosya sistemi mount seçeneklerini ve kota desteğini inceleyin. Doğrudan quotacheck çalıştırmak ya da dosya sistemi üzerinde plansız onarım yapmak, özellikle üretim sunucularında uygun bir ilk çözüm değildir.

Çözümü doğrulama

Temizlik, süreç yönetimi veya kota onarımından sonra aynı ölçümleri tekrar alın:

df -hT /home
df -i /home
du -xsh /home/KULLANICI
quota -s KULLANICI

Ardından cPanel’de Disk Usage ekranını ve varsa WHM’de ilgili hesabın kota bilgisini karşılaştırın. Küçük farklar blok boyutu, dosya sistemi gecikmesi veya ölçüm kapsamından kaynaklanabilir. Buna karşılık GB düzeyinde kalıcı fark varsa; /home dışındaki depolama, veritabanı yerleşimi, bind mount noktaları ve silinmiş-açık dosyalar yeniden gözden geçirilmelidir.

Tekrarını önleme

• Hesap başına disk alanı ve inode kullanımını düzenli izleyin; yalnızca toplam GB uyarısına güvenmeyin.
• E-posta kutuları için kota ve saklama politikası belirleyin; Çöp ve Spam klasörlerini periyodik kontrol edin.
• Uygulama yedeklerini aynı hosting hesabında sınırsız biriktirmeyin; doğrulanmış harici yedekleme hedefi kullanın.
• Uygulama günlükleri ve önbellekler için döndürme/temizleme mekanizmasını uygulama gereksinimlerine göre yapılandırın.
• Sunucu taşınması veya dosya sistemi müdahalesinden sonra kota değerlerini doğrulayın.

Sonuç

cPanel disk kullanımı yanlış görünüyor sorunu çoğu zaman yanlış bir arayüz değerinden değil, farklı ölçüm yöntemlerinden veya görünmeyen alan tüketiminden kaynaklanır. Önce df, inode, kullanıcı dizini, e-posta alanı ve kota verisini karşılaştırın. df ile du arasındaki farkı özellikle silinmiş-açık dosyalar açısından inceleyin. Kota onarımını ise ancak gerçek kullanım doğrulandıktan, yedek ve bakım planı oluşturulduktan sonra uygulayın.

Sık sorulan sorular

cPanel’de alan dolu görünüyor ama Dosya Yöneticisi’nde büyük dosya yok. Neden?

E-posta klasörleri, gizli dosyalar, ev dizini dışındaki veriler veya silinmiş ancak açık dosyalar görünür dosya listesinden farklı sonuç oluşturabilir. Önce du, posta dizini ve gerekirse lsof +L1 çıktısını kontrol edin.

Disk alanı boş olduğu hâlde “Disk quota exceeded” hatası neden alınır?

Kullanıcı kotası veya inode limiti dolmuş olabilir. Dosya sistemi genelinde boş alan bulunması, hesabın kendi blok ya da inode kotasının boş olduğu anlamına gelmez.

fixquotas komutu veri siler mi?

Bu betiğin amacı kota kayıtlarını yeniden oluşturmaktır; dosya temizleme aracı değildir. Yine de hesap erişimini etkileyebilecek kota değişiklikleri yaratabileceğinden root yetkisiyle, bakım penceresinde ve önce mevcut durumu kaydederek çalıştırılmalıdır.

Silinen dosya neden diskte alan kaplamayı sürdürür?

Dosyayı kullanan bir süreç açık dosya tanıtıcısını kapatmadıysa Linux alanı serbest bırakmaz. İlgili süreci doğru biçimde yeniden başlatmak veya sonlandırmak sonrasında alan serbest kalır.