Linux Sunucularda Inode Nedir? Hosting Disk Kullanımı ve Dosya Sayısı Yönetimi

Son Güncelleme: Eylül 2026

Inode, Linux dosya sistemlerinde dosyaların kimlik bilgilerini, izinlerini, sahipliğini ve disk üzerindeki konum bilgisini tutan temel veri yapısıdır. Özellikle hosting, VPS, VDS ve çok kullanıcılı sunucu ortamlarında inode sınırına ulaşmak, disk alanı boş görünse bile yeni dosya oluşturulamamasına yol açabilir.

Bu rehberde inode kavramını, inode kullanımının neden arttığını, Linux sunucularda nasıl kontrol edileceğini, güvenli temizlik yöntemlerini ve Corelux altyapısında doğru sunucu planlaması yaparken nelere dikkat edilmesi gerektiğini ayrıntılı şekilde inceleyeceğiz.

İçindekiler

• Inode Nedir?
• Inode Neden Dolar?
• Inode Kullanımı Nasıl Kontrol Edilir?
• Inode Sorunlarının Belirtileri
• Hosting ve Sunucu Planlamasında Inode Yönetimi
• Güvenli Inode Temizleme Yöntemleri
• Otomasyon ve İzleme Önerileri
• Inode Yönetiminde Güvenli Yedekleme
• Sıkça Sorulan Sorular
• Sonuç

Inode Nedir?

Inode, Linux ve Unix benzeri işletim sistemlerinde her dosya ve dizin için oluşturulan metadata yani üst veri kaydıdır. Bir dosyanın adı doğrudan inode içinde tutulmaz; dosya adı, dizin girdisi üzerinden inode numarasına bağlanır. Inode içinde dosyanın sahibi, grup bilgisi, izinleri, oluşturulma ve değiştirilme zamanları, dosya boyutu ve veri bloklarının konumu gibi bilgiler yer alır.

Basit bir örnekle anlatmak gerekirse, dosyanın içeriği kitabın sayfaları gibidir; inode ise o kitabın katalog kartıdır. Katalog kartı olmadan kitabın rafta nerede olduğu, kime ait olduğu veya hangi izinlerle erişilebildiği bilinemez. Bu nedenle Linux dosya sistemlerinde inode sayısı tükenirse, diskte yeterli boş alan olsa bile yeni dosya, dizin, önbellek dosyası veya oturum dosyası oluşturulamaz.

Inode ile disk alanı arasındaki fark

Disk alanı, dosya içeriklerinin kapladığı fiziksel veya sanal depolama kapasitesini ifade eder. Inode ise dosya sayısını temsil eden bir kaynak gibi düşünülebilir. Örneğin 20 GB disk alanına sahip bir hesapta milyonlarca küçük dosya bulunuyorsa, kullanılan disk alanı düşük olsa bile inode sınırı dolabilir. Tersine, tek bir büyük yedek dosyası yüksek disk alanı kullanır ancak yalnızca bir inode tüketir.

Hosting ortamlarında inode, genellikle görünmeyen ama performansı ve sürekliliği doğrudan etkileyen bir sınırdır. Özellikle WordPress, Laravel, e-ticaret yazılımları, e-posta kutuları, geçici dosya dizinleri ve cache sistemleri inode kullanımını hızlı şekilde artırabilir.

Inode Neden Dolar?

Inode kullanımının artmasının temel nedeni çok sayıda küçük dosyanın oluşmasıdır. Büyük dosyalar daha çok disk alanı tüketirken, küçük dosyalar genellikle inode tüketimini artırır. Bu durum özellikle dinamik web sitelerinde, CMS tabanlı projelerde ve yoğun trafik alan uygulamalarda sık görülür.

Yaygın inode tüketim kaynakları

• Önbellek dosyaları: WordPress cache eklentileri, sayfa önbelleği, nesne önbelleği ve tema derleme dosyaları binlerce küçük dosya oluşturabilir.
• E-posta kutuları: Maildir yapısında her e-posta ayrı bir dosya olarak saklandığı için yoğun posta trafiği inode tüketimini ciddi şekilde artırır.
• Log dosyaları: Hatalı yapılandırılmış uygulamalar sürekli yeni log dosyaları üretebilir veya eski logları silmeden saklayabilir.
• Oturum dosyaları: PHP session dosyaları temizlenmezse /tmp veya özel session dizinlerinde çok sayıda küçük dosya birikebilir.
• Görsel varyasyonları: WordPress gibi sistemler her yüklenen görsel için farklı boyutlarda kopyalar oluşturabilir.
• Node.js ve Composer bağımlılıkları: node_modules ve vendor dizinleri on binlerce dosya içerebilir.
• Yedekleme kalıntıları: Başarısız yedekleme işlemleri geçici klasörlerde çok sayıda parça dosya bırakabilir.

Inode doluluğu genellikle aniden fark edilir çünkü kullanıcı disk alanını kontrol ettiğinde hâlâ boş alan olduğunu görebilir. Ancak sistem yeni dosya oluşturmak istediğinde inode kalmadığı için hata üretir. Bu durum web sitesinde resim yükleme hatası, oturum açılamaması, e-posta alamama veya uygulama güncellemesinin başarısız olması şeklinde ortaya çıkabilir.

Dosya sistemi oluşturulurken inode nasıl belirlenir?

Birçok Linux dosya sisteminde inode sayısı dosya sistemi oluşturulurken belirlenir. Örneğin ext4 dosya sistemi oluşturulurken blok boyutu, inode oranı ve toplam kapasiteye göre belirli sayıda inode ayrılır. Bu değer sonradan kolayca artırılamayabilir. Bu nedenle yüksek dosya sayısı beklenen projelerde sunucu kurulumu ve disk bölümleme aşamasında doğru planlama önemlidir.

Özellikle çok sayıda küçük dosya barındıran projeler için varsayılan disk yapılandırması her zaman en iyi seçenek olmayabilir. E-posta sunucuları, CDN cache alanları, obje tabanlı dosya depoları, log toplama sistemleri ve büyük WordPress çoklu site kurulumları inode açısından ayrıca değerlendirilmelidir.

Inode Kullanımı Nasıl Kontrol Edilir?

Linux sunucularda inode kullanımını kontrol etmenin en pratik yolu df komutunu -i parametresiyle kullanmaktır. Bu komut disk alanı yerine inode kapasitesini gösterir.

df -i

Örnek çıktı aşağıdaki gibi olabilir:

Filesystem       Inodes  IUsed   IFree IUse% Mounted on
/dev/vda1       1310720 987654  323066   76% /
tmpfs            128000    120  127880    1% /run

Burada IUse% değeri inode kullanım yüzdesini gösterir. Bu oran yüzde 80 seviyesini geçtiğinde takip edilmesi, yüzde 90 seviyesini geçtiğinde ise temizlik ve planlama yapılması önerilir. Yüzde 100 olduğunda sistem yeni dosya oluşturamayacağı için servislerde kesintiler oluşabilir.

Hangi dizin daha fazla inode tüketiyor?

Toplam inode kullanımını görmek çoğu zaman yeterli değildir. Sorunun hangi dizinden kaynaklandığını bulmak için dosya sayımı yapılmalıdır. Aşağıdaki komut kök dizin altındaki ilk seviye klasörlerin yaklaşık dosya sayılarını listeler:

for i in /*; do echo "$i"; find "$i" -xdev -printf '.' 2>/dev/null | wc -c; done

Daha okunabilir bir yöntem olarak belirli bir dizin altında dosya ve dizin sayısı kontrol edilebilir:

find /var/www -xdev | wc -l

En çok dosya içeren alt dizinleri bulmak için şu komut kullanılabilir:

du --inodes -d 2 /var/www 2>/dev/null | sort -nr | head -20

du --inodes parametresi, desteklenen sistemlerde dizinlerin inode kullanımını analiz etmeyi kolaylaştırır. Ancak bu komutun büyük dosya sistemlerinde yoğun çalışabileceği unutulmamalıdır. Üretim ortamlarında analiz komutlarını düşük trafik saatlerinde çalıştırmak daha güvenlidir.

cPanel ve kontrol panellerinde inode takibi

cPanel, Plesk veya benzeri kontrol panellerinde inode kullanımı genellikle hesap istatistikleri bölümünde görülebilir. Paylaşımlı hosting ortamlarında sağlayıcılar her hesap için inode limiti tanımlayabilir. Bu limit, platformun kararlı çalışması ve tek bir hesabın tüm sunucu kaynaklarını tüketmemesi için önemlidir.

Eğer web siteniz sık sık dosya yükleme hatası veriyor, e-posta alamıyor veya güncelleme sırasında başarısız oluyorsa kontrol panelinizde inode göstergesini incelemek iyi bir ilk adımdır. Corelux Linux Hosting hizmetlerinde doğru kullanım alışkanlıklarıyla inode tüketimi daha öngörülebilir hale getirilebilir.

Inode Sorunlarının Belirtileri

Inode tükenmesi çoğu zaman klasik disk doluluğu hatalarıyla karıştırılır. Ancak aradaki fark önemlidir: Disk alanı boş olabilir, fakat inode kalmadığı için sistem dosya oluşturamaz. Bu nedenle belirtileri doğru okumak hızlı müdahale için kritik öneme sahiptir.

Web sitesi tarafında görülen belirtiler

• Medya yükleme hatası: WordPress veya benzeri CMS sistemlerinde yeni görsel yüklenemez.
• Cache oluşturulamaması: Önbellek eklentileri geçici dosya yazamadığı için site yavaşlar veya hata verir.
• Güncelleme başarısızlığı: Tema, eklenti veya çekirdek yazılım güncellemeleri dosya oluşturamadığı için tamamlanamaz.
• Oturum sorunları: Kullanıcılar panele giriş yapamaz veya sepet bilgileri kaybolabilir.
• 500 hataları: Uygulama, geçici dosya veya log yazamadığında genel sunucu hatası üretebilir.

Sunucu ve servis tarafında görülen belirtiler

• E-posta teslim hataları: Mail sunucusu yeni ileti dosyası oluşturamadığı için gelen postaları reddedebilir.
• Log yazılamaması: Servisler olay kaydı oluşturamaz ve hata ayıklama zorlaşır.
• Paket yönetimi hataları: apt, dnf veya benzeri paket yöneticileri geçici dosya oluşturamadığı için çalışmayabilir.
• Veritabanı geçici dosya sorunları: Bazı işlemler geçici dosya alanına ihtiyaç duyduğundan performans düşebilir.
• Yedekleme başarısızlığı: Yedekleme yazılımı geçici indeks veya parça dosyası oluşturamadığı için işlem yarıda kalabilir.

Bu belirtilerden biri görüldüğünde yalnızca df -h çıktısına bakmak yeterli değildir. Mutlaka df -i ile inode durumu da kontrol edilmelidir. Böylece disk alanı ve dosya sayısı kaynaklı sorunlar birbirinden ayrıştırılabilir.

Hosting ve Sunucu Planlamasında Inode Yönetimi

Inode yönetimi yalnızca temizlik işlemi değildir; doğru planlama, uygun hizmet seçimi ve uygulama mimarisiyle birlikte düşünülmelidir. Küçük bir kurumsal web sitesi ile milyonlarca küçük ürün görseli barındıran bir e-ticaret sitesi aynı inode ihtiyacına sahip değildir.

Hangi hizmet türü ne zaman tercih edilmeli?

Paylaşımlı hosting ortamlarında inode limitleri platformun sağlıklı çalışması için gereklidir. Eğer projeniz sürekli olarak bu sınırlara yaklaşıyorsa, yalnızca geçici temizlik yapmak yerine kaynak yapısını gözden geçirmek daha doğru olur. Corelux Türkiye VDS Sunucu çözümleri, daha fazla kontrol ve özelleştirme ihtiyacı olan projeler için uygun bir alternatif olabilir.

Uygulama mimarisinde dikkat edilmesi gerekenler

• Dosya üretimini sınırlayın: Gereksiz thumbnail, geçici çıktı ve tekrar eden cache dosyalarını azaltın.
• Log rotasyonu uygulayın: Log dosyalarının hem boyut hem sayı açısından kontrol altında kalmasını sağlayın.
• Oturum yönetimini iyileştirin: Dosya tabanlı session yerine uygun senaryolarda Redis veya veritabanı tabanlı oturum saklama yöntemlerini değerlendirin.
• Medya stratejisi belirleyin: Büyük medya arşivlerinde klasör yapısını, görsel boyutlarını ve saklama süresini planlayın.
• Bağımlılıkları temiz tutun: Geliştirme ortamı dosyalarını üretim sunucusuna taşımayın.

Güvenli Inode Temizleme Yöntemleri

Inode temizliği yapılırken amaç rastgele dosya silmek değil, güvenli ve geri döndürülebilir bir temizlik süreci yürütmektir. Kritik sistem dosyalarının, aktif uygulama dosyalarının veya kullanıcı verilerinin silinmesi ciddi kesintilere neden olabilir. Bu nedenle önce analiz, ardından yedekleme ve son olarak kontrollü temizlik yapılmalıdır.

1. Geçici dosyaları analiz edin

Öncelikle /tmp, /var/tmp, uygulama cache dizinleri ve session dizinleri incelenmelidir. Eski geçici dosyalar belirli yaş kriterine göre temizlenebilir.

find /tmp -type f -mtime +7 -print

Bu komut yalnızca 7 günden eski dosyaları listeler. Silme işlemine geçmeden önce çıktıyı kontrol etmek önemlidir. Emin olduktan sonra kontrollü şekilde silme yapılabilir:

find /tmp -type f -mtime +7 -delete

2. Uygulama cache dizinlerini temizleyin

WordPress, Laravel, Magento veya özel yazılımlar kendi cache klasörlerini kullanabilir. Örneğin Laravel uygulamalarında framework cache dosyaları temizlenebilir:

php artisan cache:clear
php artisan view:clear
php artisan config:clear

WordPress tarafında ise cache eklentisinin yönetim paneli üzerinden temizlik yapmak daha güvenlidir. Dosya sistemi üzerinden doğrudan silme yapılacaksa yalnızca eklentinin oluşturduğu cache klasörleri hedeflenmelidir.

3. Eski logları ve arşivleri kontrol edin

Log dizinlerinde çok sayıda küçük dosya oluşabilir. Önce dosya sayısı kontrol edilmeli, ardından logrotate gibi araçlarla düzenli temizlik kurgulanmalıdır. Manuel silme yerine rotasyon politikası oluşturmak uzun vadede daha sağlıklıdır.

find /var/log -type f -name "*.gz" -mtime +30 -print

Bu komut 30 günden eski sıkıştırılmış log arşivlerini listeler. Üretim ortamında yasal kayıt gereksinimleri, güvenlik incelemeleri ve hata analizi ihtiyaçları dikkate alınmadan log silinmemelidir.

4. E-posta kutularını düzenleyin

Maildir yapısında her e-posta ayrı dosya olduğu için kullanılmayan posta kutuları, spam klasörleri ve eski iletiler inode tüketimini artırabilir. Kullanıcıların gereksiz e-postaları silmesi, spam klasörlerinin otomatik temizlenmesi ve büyük eklerin dış arşive alınması inode kullanımını azaltır.

5. Geliştirme dosyalarını üretimden kaldırın

.git, test çıktıları, yerel geliştirme cache dosyaları, eski dağıtım klasörleri ve kullanılmayan bağımlılıklar üretim ortamında gereksiz inode tüketebilir. Dağıtım sürecinde yalnızca çalışması gereken dosyaların sunucuya gönderilmesi önerilir.

find /var/www/example.com -type d -name ".git" -print

Bu komut web kök dizini altında .git klasörlerini listeler. Güvenlik açısından da bu klasörlerin web ortamında bulunmaması gerekir.

Otomasyon ve İzleme Önerileri

Inode yönetiminde en sağlıklı yaklaşım, sorun oluşmadan önce uyarı mekanizması kurmaktır. Böylece inode kullanımı kritik seviyeye ulaşmadan temizlik, kapasite artırımı veya yapılandırma değişikliği yapılabilir.

Basit inode kontrol betiği

Aşağıdaki örnek betik, kök dosya sistemi için inode kullanım yüzdesini kontrol eder. Belirlenen eşiğin üzerinde çıktı üretir. Gerçek ortamda bu betik e-posta, webhook veya izleme sistemi entegrasyonu ile genişletilebilir.

#!/bin/bash
LIMIT=85
USAGE=$(df -i / | awk 'NR==2 {gsub("%", "", $5); print $5}')

if [ "$USAGE" -ge "$LIMIT" ]; then
  echo "Uyarı: Inode kullanımı %$USAGE seviyesinde."
else
  echo "Inode kullanımı normal: %$USAGE"
fi

Bu betik cron ile düzenli çalıştırılabilir. Ancak otomatik temizlik betikleri dikkatli tasarlanmalıdır. Yanlış hedeflenen bir find -delete komutu, üretim verilerini silebilir. Bu nedenle otomatik silme yerine önce raporlama, ardından onaylı temizlik yaklaşımı tercih edilmelidir.

İzleme eşikleri nasıl belirlenmeli?

• Yüzde 70: Normal takip seviyesi olarak değerlendirilebilir.
• Yüzde 80: Artış hızı incelenmeli ve hangi dizinlerin büyüdüğü belirlenmelidir.
• Yüzde 90: Temizlik, arşivleme veya kapasite planlaması yapılmalıdır.
• Yüzde 95 ve üzeri: Kritik seviyedir; servis kesintisi riski yükselir.

İzleme yalnızca toplam inode yüzdesine odaklanmamalıdır. Belirli dizinlerdeki dosya sayısı, cache üretim hızı, e-posta kutusu büyümesi ve log rotasyonu durumu da takip edilmelidir. Böylece sorun tekrarlamadan kök neden ortadan kaldırılabilir.

Inode Yönetiminde Güvenli Yedekleme

Inode temizliği öncesinde yedek almak kritik öneme sahiptir. Ancak yedekleme stratejisi yanlış kurgulanırsa inode sorununu daha da büyütebilir. Özellikle aynı disk üzerinde çok sayıda küçük dosyadan oluşan yedekler tutuluyorsa hem disk alanı hem inode tüketimi artar.

Yedekleme yaparken dikkat edilmesi gerekenler

• Aynı diske yedek almaktan kaçının: Üretim diski üzerinde yedek tutmak hem kapasite hem inode açısından risklidir.
• Sıkıştırılmış arşiv kullanın: Çok sayıda küçük dosyayı tek arşivde toplamak inode tüketimini azaltabilir.
• Artımlı yedekleme planlayın: Her seferinde tam kopya almak yerine değişen dosyaları yedeklemek daha verimlidir.
• Yedek doğrulaması yapın: Silme işleminden önce yedeğin okunabilir ve geri yüklenebilir olduğundan emin olun.
• Saklama politikasını belirleyin: Eski yedeklerin ne kadar süre tutulacağı net olmalıdır.

Corelux Yedekleme Hizmeti, kritik verilerin daha güvenli saklanmasına yardımcı olabilir. Özellikle üretim sunucularında inode temizliği, taşıma, güncelleme veya disk yeniden yapılandırma işlemleri öncesinde yedekleme süreci ihmal edilmemelidir.

Arşivleme örneği

Belirli bir dizindeki eski logları tek bir sıkıştırılmış arşive almak inode tüketimini azaltabilir. Ancak arşiv oluşturulduktan sonra kaynak dosyalar silinmeden önce arşivin kontrol edilmesi gerekir.

tar -czf eski-loglar-2026.tar.gz /var/log/uygulama-eski/

Arşiv doğrulandıktan ve güvenli bir alana taşındıktan sonra eski dosyalar kontrollü biçimde temizlenebilir. Büyük sistemlerde bu süreç otomasyonla yapılabilir fakat mutlaka test ortamında denenmelidir.

Sıkça Sorulan Sorular

Sonuç

Inode yönetimi, Linux sunucularda yalnızca sistem yöneticilerinin değil, web sitesi sahiplerinin, geliştiricilerin ve e-ticaret yöneticilerinin de bilmesi gereken önemli bir konudur. Disk alanı yeterli olsa bile inode sınırına ulaşmak, dosya yükleme hatalarından e-posta kesintilerine kadar birçok soruna neden olabilir. Bu nedenle df -i ile düzenli kontrol yapmak, cache ve log politikalarını doğru kurgulamak, geçici dosyaları yönetmek ve yedekleme süreçlerini planlamak gerekir.

Küçük ve orta ölçekli projeler için Corelux Hosting çözümleri pratik bir başlangıç sunarken, daha fazla kontrol isteyen projelerde Sanal Sunucu ve yüksek kaynak ihtiyacı olan yapılarda Kiralık Sunucu seçenekleri değerlendirilebilir. Doğru altyapı, düzenli izleme ve güvenli yedekleme yaklaşımıyla inode kaynaklı kesintilerin büyük bölümü önceden engellenebilir.