Paylaşımlı Hosting’de inode Limitine Takılmamak İçin Uygulamalı Temizlik Rehberi

Paylaşımlı Hosting’de inode Limiti Nedir, Neden Bu Kadar Kritik?

Paylaşımlı hosting kullananların büyük kısmı, disk kotasını dolmadan önce inode limiti uyarısıyla tanışıyor. Diskte hâlâ onlarca GB boş alan varken kontrol panelinde kırmızıya dönen bir sayaç, sık sık gelen uyarı mailleri ve zaman zaman çalışmayan e-posta kutuları… Eğer siz de bu tabloya yabancı değilseniz, aslında sorun kapasiteden çok dosya sayısının kontrolsüz büyümesidir.

inode basitçe, Linux dosya sisteminde her bir dosya veya klasörü temsil eden kayıt demektir. Yani bir hosting hesabınızda 200.000 inode limiti varsa, kabaca 200.000 dosya + klasör barındırabilirsiniz. Boyutu 1 KB olan bir log dosyası da, 5 GB’lık bir yedek arşivi de inode tarafında 1 adet olarak sayılır. Bu yüzden özellikle küçük, çok sayıda dosya üreten uygulamalarda inode, diske göre çok daha önce tıkanır.

DCHost olarak sahada gördüğümüz tipik senaryo şu: WordPress siteler, gereksiz eklenti ve cache klasörleriyle doluyor; FTP ile sürükle-bırak yapılan yedek klasörleri web dizininde tutuluyor; e-posta kutuları hiç temizlenmiyor ve bir bakmışsınız, CPANEL veya DirectAdmin tarafında inode limiti %100. Site çalışsa bile yedek oluşturma, e-posta alma, hatta bazı durumlarda WordPress güncellemesi bile sorunlu hale geliyor.

Bu rehberde, paylaşımlı hosting hesabınızda inode limitine takılmamak için adım adım dosya yönetimi ve temizlik stratejisi anlatacağız. Hedefimiz, panikle rastgele silme yapmak yerine, neyin nereden temizleneceğini, nelerin asla silinmemesi gerektiğini ve hangi noktada bir üst seviye (örneğin DCHost VPS) pakete geçmenin daha mantıklı hale geldiğini netleştirmek.

inode Limiti ve Paylaşımlı Hosting İlişkisini Doğru Anlamak

Önce kısaca zemini netleştirelim. Eğer kavramsal kısım size tanıdık geliyorsa, bu bölümü hızlıca geçebilirsiniz.

inode Tam Olarak Neyi Sayar?

Linux tabanlı paylaşımlı hosting ortamında inode:

• Her dosya (PHP, HTML, CSS, JS, JPG, PNG vb.)
• Her klasör
• Çoğu zaman sembolik link gibi özel dosya türlerini

ayrı birer kayıt olarak temsil eder. Dolayısıyla:

• 50.000 küçük log dosyası = 50.000 inode
• Tek bir 10 GB yedek arşivi = 1 inode

inode limiti dolduğunda genellikle şu etkileri görürsünüz:

• Yeni dosya/klasör oluşturulamaz (WordPress güncellemeleri, eklenti yükleme sorun çıkarır).
• PHP oturum (session) dosyaları yazılamadığı için beklenmedik hatalar oluşabilir.
• Yeni e-posta kutuya kaydedilemez, mailler geri dönebilir.
• Kontrol paneli tarafında otomatik yedek alma görevleri başarısız olur.

Paylaşımlı Hosting Mimarisi Neden inode Limiti Kullanır?

Paylaşımlı hosting paketlerinde bir fiziksel sunucuyu onlarca, hatta yüzlerce kullanıcıyla paylaşırsınız. Bu yapı, paylaşımlı hosting nedir yazımızda mimari açıdan detaylı anlatılıyor. Disk alanını sınırlamak genellikle yeterli olmaz; çünkü bir hesabın milyonlarca minik dosya oluşturması, aynı diski paylaşan tüm kullananların performansını çökertir.

Bu yüzden hosting sağlayıcıları (biz de dahil), adil kullanım için:

• Disk kotası (örneğin 10 GB)
• inode kotası (örneğin 150.000–300.000)

gibi iki ayrı limit uygular. Disk kotanız dolmadan inode limitinize ulaşmanız gayet normal ve sık görülen bir durumdur.

inode Kullanımınızı Nasıl Görürsünüz?

Temizliğe başlamadan önce, önce nerede durduğunuzu ölçmeniz gerekiyor. Kontrol paneline göre adımlar ufak farklılıklar gösterebilir ama genel mantık aynı.

cPanel Üzerinden inode Kullanımını Kontrol Etmek

cPanel kullanan DCHost müşterilerimiz için yol haritası genelde şöyledir:

1. cPanel hesabınıza giriş yapın.
2. Ana sayfada genelde sol altta ya da üstte bulunan İstatistikler / Statistics bölümünde “Inodes” veya “Dosya Kullanımı” satırını bulun.
3. Burada kullanılan inode sayısı / toplam limit şeklinde bir değer göreceksiniz, örneğin 145.000 / 200.000.
4. cPanel > Disk Kullanımı ekranından klasör klasör hangi dizinin ne kadar yer kapladığını görebilir, dosya sayısı hakkında fikir edinebilirsiniz.

Detaylı cPanel yedek ve dosya yönetimi akışını merak ediyorsanız, önce cPanel’de tüm siteyi yedekleme ve geri yükleme rehberi yazımıza göz atmanızı öneririz. inode temizliğine başlamadan önce mutlaka sağlam bir yedeğiniz olmalı.

DirectAdmin Üzerinden inode Kullanımını Kontrol Etmek

DirectAdmin kullanıcılarında inode sayısı genellikle:

• Ana sayfa istatistikler bölümünde “inode” veya “Files” başlığı altında
• Ya da Account Manager > Disk Usage ekranında

görülebilir. Ayrıca File Manager üzerinden belirli klasörlerdeki dosya sayısını da görebilirsiniz.

SSH Erişimi Olanlar İçin Hızlı inode Analizi

Paylaşımlı hosting paketinde SSH erişiminiz varsa (her zaman açık olmayabilir), basit komutlarla hangi klasörün kaç inode tükettiğini görebilirsiniz:

cd /home/kullaniciadi
find . | wc -l   # Toplam inode sayısı (kabaca)

# Klasör bazlı özet için (biraz zaman alabilir):
for i in *; do echo "$(find "$i" | wc -l)  $i"; done | sort -n

Bu çıktılar, hangi klasörleri önce ele almanız gerektiğini çok net gösterir.

inode’ları Sessizce Tüketen Yaygın Kaynaklar

Onlarca hesabı incelediğimizde, inode’ların büyük kısmını genellikle aynı tür dosyaların şişirdiğini görüyoruz. Yani sorun çoğu zaman tekil bir klasörde değil, birkaç benzer alışkanlıkta saklı.

1. Cache (Önbellek) Klasörleri

WordPress, Joomla, Laravel tabanlı paneller ve çeşitli cache eklentileri, sayfaları hızlandırmak için dinamik içeriği statik dosyalara dönüştürür. Bu dosyalar çoğu zaman:

• wp-content/cache/
• wp-content/uploads/cache/
• storage/framework/cache/ (Laravel)

gibi klasörlerde birikir. Tek tek baktığınızda küçük dosyalardır, ama binlerce dosya inode limitinizi hızla tüketir.

2. Log Dosyaları

Hata logları, erişim logları veya eklentilerin oluşturduğu özel loglar, özellikle bozuk bir eklenti ya da saldırı denemesi sırasında hızla şişebilir:

• logs/ klasörleri
• error_log dosyalarının çoğalması
• Uygulama içi debug logları

Log’lar boyut olarak da sorun çıkarır ama asıl problem, her gün onlarca yeni dosya üretilmesidir.

3. E-posta Kutuları ve Spam Klasörleri

Her e-posta bir dosyadır. Gelen kutusunu yıllarca hiç temizlemeyen, spam klasörünü sıfırlamayan kullanıcıların inode’larının ciddi bir kısmı e-posta dizinleri tarafından tüketilir. Özellikle yoğun form trafiği olan sitelerde, formların kopyası e-posta ile geliyorsa bu çok belirgin hale gelir.

4. Eski Yedekler ve Klon Siteler

Paylaşımlı hosting hesabı üzerinden “aman dursun” diyerek saklanan:

• cPanel tam yedekleri (full backup .tar.gz)
• Eski sürümler, staging kopyalar (eski/, v1/, test/ gibi alt dizinler)
• ZIP açılmış ama unutulmuş arşiv içerikleri

çoğu zaman inode yükünün önemli bir kısmını oluşturur. Özellikle staging veya test klasörleri, bir WordPress kurulumunu birebir kopyaladığınız için ana siteniz kadar inode tüketir.

5. Geliştirici Artıkları: node_modules, vendor, Git Depoları

Birçok geliştirici, localde çalışması gereken klasörleri doğrudan hosting hesabına yükler:

• node_modules klasörleri (binlerce küçük dosya)
• vendor klasörleri (Composer bağımlılıkları)
• .git klasörleri ve Git depo geçmişi

Bunlar, paylaşımlı hosting hesabı için inode kabusu yaratır. Bu tür bağımlılık klasörleri genellikle canlı ortamda gitmeye gerek bile olmayan dosyalardır.

6. Kötü Amaçlı Dosyalar ve Shell’ler

Hack’lenmiş bir sitede saldırganlar çoğu zaman yüzlerce, hatta binlerce küçük dosya yükler. Backdoor shell’ler, spam dosyaları, zararlı PHP scriptleri inode sayınızı bir anda zıplatabilir. Böyle şüpheli vakalarda, sadece temizlik değil, hacklenmiş PHP sitelerini temizleme rehberi doğrultusunda derinlemesine inceleme yapmak şarttır.

Adım Adım inode Temizlik Stratejisi

Şimdi gelelim asıl işe yarar kısma: Ne zaman, nereden, neyi temizlemeliyim? Burada paylaştığımız adımlar, DCHost tarafında günlük operasyonlarda uyguladığımız, işe yaradığı sahada defalarca kanıtlanmış bir akış.

1. Yedek Almadan Temizliğe Başlamayın

İlk kural: Yedek yoksa temizlik yok. Yanlışlıkla silinen bir klasörü geri getirmek, özellikle veritabanı veya kritik yapılandırma dosyaları söz konusuysa oldukça zahmetli, bazen imkansız olabilir.

Önerilen en pratik yol:

• cPanel kullanıyorsanız, cPanel’de site yedeği alma adımlarını izleyerek tam bir yedek oluşturun.
• DirectAdmin kullanıyorsanız, paneldeki backup özelliğiyle en azından home dizini + veritabanlarını içeren bir yedek alın.
• Yedeği mümkünse yerel bilgisayarınıza indirin. inode limitiniz zaten yüksekse, yedeği aynı hesabın içinde tutmak çok anlamlı olmayabilir.

DCHost altyapısında ayrıca otomatik yedekleme politikalarımız bulunuyor; ancak manuel, elinizin altında bir kopya bulundurmak, risk almamak açısından her zaman iyi fikirdir.

2. Öncelikli Klasörleri Haritalayın

Temizliği rastgele klasörlerden başlatmak yerine, hesabınızda en çok inode tüketen alanları önce kabaca belirleyin. Bunun için:

• cPanel/DirectAdmin disk kullanım raporlarına bakın.
• Varsa SSH ile find ve wc -l kullanarak klasör bazlı inode sayımı yapın.

Genelde aşağıdaki klasörleri yüksek şüpheli olarak işaretleyebilirsiniz:

• tmp/
• logs/ veya log/
• wp-content/cache/
• wp-content/uploads/ (özellikle cache ve otomatik oluşturulan küçük görseller)
• mail/ (e-posta kutuları)
• eski/, backup/, old/, v1/, test/ gibi isimler taşıyan alt dizinler

3. Güvenle Silinebilecek Alanlar

Genel bir kural olarak aşağıdaki tür klasör ve dosyalar (uygulamaya göre değişmekle birlikte) genellikle güvenle temizlenebilir. Yine de her zaman önce yedek alın.

Cache Klasörleri

WordPress tarafında:

• LiteSpeed Cache, W3 Total Cache, WP Super Cache vb. eklentilerin cache klasörleri
• wp-content/cache/, wp-content/cache/page/, wp-content/uploads/cache/

Bu klasörleri silmek siteyi bozmaz; sadece ilk isteklerde sayfalar biraz daha yavaş oluşturulur, sonrasında yeniden önbelleğe alınır. Eğer LiteSpeed kullanıyorsanız, LiteSpeed Cache ayar rehberimizde önbellek boyutunu ve süresini nasıl optimize edeceğinizi detaylı anlattık.

Geçici Dosyalar ve Oturumlar

/tmp benzeri geçici klasörler, sunucu tarafında otomatik temizleme politikalarına sahip olabilir; ancak kullanıcı bazlı uygulamalarda (örneğin belirli scriptlerin kendi tmp klasörü) elle temizlik gerekebilir. Oturum (session) dosyaları da zamanla birikir. Uygulamanızın süresi geçmiş oturumları otomatik temizlediğinden emin olun.

Eski Yedekler ve Klonlar

Web ortamında tutulan:

• Eski tam yedek dosyaları (backup-2022-xx-xx.tar.gz vb.)
• Kullanmadığınız staging/test klasörleri

en hızlı kazanım sağlayan alanlardır. Kullanmadığınız staging klasörlerini tamamen kaldırmak, tek seferde on binlerce inode tasarrufu sağlayabilir.

4. Dikkatli Olmanız Gereken Klasörler

Her şeyi silmek kolay; önemli olan doğru şeyi silmek. Aşağıdaki alanlarda temkinli olun:

• Uygulama çekirdeği (WordPress için wp-admin, wp-includes, Laravel için vendor vb.) – manuel silmeyin, güncelleme yöneticisini kullanın.
• Veritabanı dump dosyaları – gerekliyse yerelde saklayın, ama silmeden önce gerçekten ihtiyacınız olmadığından emin olun.
• Konfigürasyon dosyaları (wp-config.php, .env, configuration.php vb.) – asla silmeyin.

Eğer bir dosyanın ne işe yaradığından emin değilseniz, önce adını Google’da veya ilgili CMS’in belgelerinde aratın. Kararsızsanız DCHost destek ekibine danışmak, rastgele silmekten çok daha güvenlidir.

5. WordPress Özelinde inode Temizliği

Paylaşımlı hosting kullanıcılarının önemli bir kısmı WordPress çalıştırdığı için, burada ekstra birkaç not açmak faydalı.

• Gereksiz eklentileri kaldırın: Pasif eklentiler dizinde durdukça inode tüketir. Kullanmıyorsanız, sadece devre dışı bırakmak yerine tamamen silin.
• Görsel boyutlarını gözden geçirin: Her yeni yüklenen görsel, tema ve eklentilerin oluşturduğu thumbnail boyutlarıyla birlikte 10–20 farklı dosyaya dönüşebilir. Uzun vadede bu inanılmaz inode tüketir.
• Medya offload stratejisi: Çok medya ağırlıklı sitelerde, görselleri harici nesne depolama üzerine taşımak mantıklı olabilir. Bu konuda detaylı bir senaryo okumak isterseniz, object storage ile medya offload stratejisi yazımız sizde epey ışık yakacaktır.

Ayrıca uzun vadeli sağlık için, WordPress yedekleme stratejileri rehberimizde anlattığımız şekilde otomatik, döngüsel yedekleme ve saklama politikası kurmanız inode yönetimini de kolaylaştırır.

Otomatik Temizlik ve Rutin Bakım Süreçleri

Bir kere temizlik yapmak, sizi geçici olarak inode krizinden kurtarır. Ancak asıl sürdürülebilir çözüm, periyodik bakım ve mümkünse otomasyon kurmaktır.

1. Aylık/Üç Aylık Manuel Bakım Listesi

En basit ve pratik yaklaşım, takvime küçük bir tekrar eden görev eklemek:

• Ayda 1 gün: Cache klasörlerini ve log dosyalarını kontrol edip temizleyin.
• 3 ayda 1 gün: E-posta kutularını, özellikle spam/junk klasörlerini boşaltın.
• Yılda 1–2 kez: Eski yedekleri ve staging/test klasörlerini gözden geçirin.

Bunu küçük işletmelerde genelde “web sitesi bakım günü” olarak konumlandırıyoruz. Özellikle e-ticaret sitelerinde bu rutin, sadece inode değil, performans ve güvenlik açısından da ciddi fayda sağlıyor.

2. Cron ile Otomatik Komutlar (Gelişmiş Kullanıcılar)

SSH ve komut satırına aşina olan kullanıcılar, bazı temizlik işlemlerini cron job ile otomatik hale getirebilir. Örneğin, 30 günden eski log dosyalarını silmek için:

find /home/kullaniciadi/logs -type f -mtime +30 -delete

Bunu cPanel veya DirectAdmin’de cron job olarak tanımlayabilirsiniz. Ancak yanlış bir find parametresi, istemeden önemli dosyaları da silebileceği için bu adımı dikkatle tasarlamak gerekiyor. Güvenli cron kurgusu hakkında daha geniş bir çerçeve için Linux crontab en iyi uygulamalar rehberi yazımıza göz atmanız faydalı olur.

3. E-posta İstemcisi Kurulumu ve Otomatik Arşiv

Sürekli webmail kullanan kullanıcılar, genellikle posta kutularını asla boşaltmaz; çünkü dolduğunu fark etmeleri zaman alır. IMAP destekli bir e-posta istemcisi (Outlook, Thunderbird vb.) ile:

• Belirli klasörleri yerel arşive taşıyabilir,
• Yıllara göre arşiv klasörleri oluşturabilir,
• Sunucudaki dosya sayısını azaltabilirsiniz.

Böylece sunucudaki inode yükü azalırken, eski e-postalarınız yerel bilgisayarınızda erişilebilir olmaya devam eder.

inode Limiti Sürekli Doluyorsa: Ne Zaman Üst Pakete veya VPS’e Geçmeli?

Bazen tüm temizlik ve optimizasyona rağmen, işin doğası gereği milyonlarca dosya üreten projelerle karşılaşıyoruz. Örneğin:

• Günde binlerce görsel yüklenen ilan siteleri
• Log ağırlıklı uygulamalar
• Bir hesabın altında onlarca WordPress sitesini barındıran ajans yapıları

Böyle durumlarda, paylaşımlı hosting hesabının inode limitine sürekli dayanıyorsanız, mesele artık sadece temizlik değildir; mimarinin yükseltilmesi gerekir.

1. Aynı Paylaşımlı Hosting Hesabında Sonsuza Kadar Yaşanmaz

inode krizinin yılda bir kez yaşanması ile ayda bir yaşanması aynı şey değil. Aşağıdaki sorulara dürüstçe “+” diyorsanız, bir üst seviye plana geçiş zamanı gelmiş olabilir:

• Son 6 ayda 3’ten fazla inode uyarısı aldınız mı?
• Temizlikten sonra bile boş inode oranınız %20’nin altına mı düşüyor?
• Tek bir hesapta 10’dan fazla site mi barındırıyorsunuz?

Bu durumda, DCHost tarafında daha geniş inode limitine sahip paketleri veya bir üst adım olarak VPS / dedicated çözümlerini değerlendirmek hem sizi hem de sitelerinizi rahatlatacaktır.

2. Paylaşımlı Hosting’den VPS’e Geçiş Senaryosu

inode kaynaklı kısıtları tamamen ortadan kaldırmak istiyorsanız, bir sonraki doğal adım genelde DCHost üzerinde VPS veya dedicated sunucu tarafına geçmektir. Burada disk alanını ve inode sayısını kendi ihtiyacınıza göre ölçekleyebilir, sadece sizin projelerinize ayrılmış bir ortam kurabilirsiniz.

Bu geçiş sürecini adım adım, kesintisiz şekilde planlamak için hazırladığımız paylaşımlı hosting’den VPS’e sorunsuz geçiş rehberi yazısına mutlaka göz atın. DNS, yedek, taşıma ve test aşamalarını net bir kontrol listesiyle anlatıyoruz.

Güvenlik Boyutunu Unutmayın: inode Artışı Bazen Alarmdır

inode temizliği konuşurken, konuyu sadece depolama optimizasyonu gibi görmek eksik olur. Ani inode artışları, bazen ciddi bir güvenlik ihlalinin habercisi de olabilir.

Özellikle aşağıdaki belirtilere dikkat edin:

• Kısa sürede on binlerce yeni .php, .js veya rastgele isimli dosya oluşması
• wp-content/uploads/ içinde normalde olmaması gereken PHP dosyaları
• Garip isimli klasörler (tmp_akdj328/ gibi rastgele dizinler)

Bu durumda sadece dosya silmek yerine, önce güvenlik taraması yapmalısınız. Yukarıda link verdiğimiz hack’lenmiş PHP sitelerini temizleme rehberinde, backdoor tespiti ve güvenli taşıma tarafını adım adım anlattık. inode temizliği, güvenlik açısından da bir “sağlık kontrolü” fırsatı olarak görülmeli.

Sonuç ve Özet: inode Yönetimini Bir Kez Çözerseniz, Sürekli Rahatlarsınız

Paylaşımlı hosting’de inode limiti, ilk başta soyut ve sinir bozucu bir kısıtlama gibi görünebilir. Ancak neyi temsil ettiğini ve hangi dosyaların bu limiti tükettiğini anladığınız anda, aslında çok net yönetilebilir bir metriğe dönüşüyor. DCHost tarafında yüzlerce hesabın analizinde gördüğümüz ortak tablolar şunlar:

• inode krizlerinin %60+’ı cache klasörleri ve gereksiz loglardan kaynaklanıyor.
• %20–25’i e-posta kutuları ve yıllarca temizlenmeyen spam klasörleriyle ilişkili.
• Kalanı ise eski yedekler, test/staging kopyaları ve nadiren de olsa güvenlik ihlalleri.

Bu rehberde paylaştığımız adımları takip ederseniz:

• Önce güvenli bir yedek alıp temizlik riskinizi minimize edebilir,
• En çok inode tüketen klasörleri tespit edip, öncelikli alanlara odaklanabilir,
• Cache, log, eski yedek ve gereksiz eklentileri temizleyerek hızla rahatlayabilir,
• Sonrasında cron ve bakım rutinleriyle bu düzeni sürdürülebilir hale getirebilirsiniz.

Eğer tüm bunlara rağmen inode limitine sürekli dayanıyorsanız, bu artık altyapı mimarisini büyütme zamanının geldiğini gösterir. Böyle bir noktada, DCHost üzerindeki VPS, dedicated sunucu veya colocation seçeneklerimizi beraber değerlendirmek en doğru adım olacaktır. Projenizin tipine göre hangi çözüme geçmeniz gerektiğini birlikte planlayabilir, taşımayı minimum kesintiyle gerçekleştirebiliriz.

inode uyarılarıyla boğuşmak yerine, dosya yönetiminizi ve yedek stratejinizi bir kez sağlam kurduğunuzda, hem siteleriniz hem de siz uzun vadede çok daha rahat edeceksiniz. DCHost olarak bu sürecin her aşamasında yanınızdayız; ihtiyacınız olduğunda destek ekibimize sadece bir ticket kadar uzaksınız.