Linux Sunucularda Disk Doluluğu: Güvenli Tanılama ve Alan Açma Rehberi

Son Güncelleme: Eylül 2026

Linux sunucularda disk doluluğu, yalnızca yeni dosya kaydedilememesi anlamına gelmez; web uygulamalarının hata vermesine, veritabanı işlemlerinin durmasına ve yedekleme işlerinin başarısız olmasına da yol açabilir. Bu rehber, doluluğun kaynağını güvenli biçimde tespit etme, hangi verilerin temizlenebileceğine karar verme ve sorunun tekrarını önleme adımlarını açıklar.

İçindekiler

• Disk Doluluğunun Belirtileri ve İlk Müdahale
• Dolu Dosya Sistemini Belirleme
• Büyük Dizin ve Dosyaları Bulma
• df ve du Sonuçları Neden Farklı Olabilir?
• Güvenli Alan Açma Yöntemleri
• Hosting ve Uygulama Sunucularında Özel Senaryolar
• Disk Doluluğunu Önlemek İçin Kalıcı Önlemler
• Örnek Müdahale Akışı
• Sıkça Sorulan Sorular
• Sonuç

Disk Doluluğunun Belirtileri ve İlk Müdahale

Disk alanı tükenen bir Linux sunucusunda uygulama günlüklerine (log), geçici dosyalara veya veritabanına yeni veri yazılamayabilir. Kullanıcı açısından bu durum başarısız dosya yüklemeleri, çalışmayan yönetim paneli, tamamlanmayan siparişler ya da aralıklı sunucu hataları olarak görülebilir. Belirtiler tek başına kesin tanı değildir: izin hatası, dosya sistemi arızası veya salt okunur bağlama da benzer sonuçlar üretebilir.

İlk hedef, aceleyle dosya silmek değil, hangi dosya sisteminin dolduğunu ve yazma işlemlerinin neden etkilendiğini belirlemektir. Özellikle üretim ortamında rastgele temizlik, birkaç gigabayt yer kazandırırken çalışan hizmetin verilerini geri dönüşsüz biçimde kaybettirebilir. Değişiklik öncesinde mümkünse güncel yedeği, uygulamanın hangi dizinleri kullandığını ve planlanan işlemin geri alma yolunu doğrulayın.

• Yazma hatalarını not edin: Hatanın başladığı saat ve etkilenen hizmetler, büyüyen dosyayı bulmayı kolaylaştırır.
• Hizmet önceliğini belirleyin: Veritabanı ve kullanıcı verileri, geçici önbelleklerden farklı risk taşır.
• Yedek durumunu kontrol edin: Dolu diske alınmaya çalışılan yeni bir yerel yedek sorunu ağırlaştırabilir.

Dolu Dosya Sistemini Belirleme

İlk ölçüm için df komutu kullanılır. Bu araç dosya sistemi (filesystem) düzeyindeki toplam, kullanılan ve kullanılabilir alanı gösterir. İnsan tarafından okunabilir birimlerle çıktıyı inceleyin; ardından dosya sayısıyla ilgili ayrı bir sınır olup olmadığını görmek için inode (dosya sistemi kayıt birimi) kullanımına bakın.

df -hT
df -i

Çıktıda /, /var veya uygulama verilerinin tutulduğu başka bir bağlama noktası (mount point) yüksek kullanım gösterebilir. Bir bölüm doluyken başka bir bölümde boş alan bulunması, sorunlu bölüme yazmaya çalışan uygulamayı kurtarmaz. Bu nedenle yalnızca toplam disk kapasitesine bakarak karar vermeyin. df -i çıktısında inode kullanımı sınıra dayanmışsa boş kapasite görünmesine rağmen yeni dosya oluşturulamayabilir; bu durumda çok sayıda küçük dosya üreten iş akışlarını araştırın.

Konteyner (container), ayrı veri diski veya ağ üzerinden bağlanan depolama kullanan sunucularda hangi hizmetin hangi dosya sistemine yazdığını da eşleştirin. Örneğin web dosyaları kök bölümde, veritabanı verileri ayrı bir bölümde olabilir. Müdahaleyi etkilenmeyen bölüme uygulamak sonuç vermez. Doğru bağlama noktası, sonraki tüm tanılama adımlarının başlangıcıdır.

Büyük Dizin ve Dosyaları Bulma

Dolu bölüm belirlendikten sonra du ile dizin ağacındaki alan kullanımını inceleyin. Aşağıdaki örnekler kök dosya sistemi içindir; dolu bölüm başka bir yere bağlanmışsa komutlardaki yolu o bağlama noktasıyla değiştirin. -x seçeneği incelemeyi aynı dosya sistemiyle sınırlar; böylece başka bir bağlı diskin verileri sonuca karışmaz.

sudo du -xhd1 / 2>/dev/null
sudo du -xhd1 /var 2>/dev/null

Önce geniş alan kullanan üst dizini bulun, sonra yalnızca o dizinde ayrıntıya inin. Örneğin /var büyük görünüyorsa günlükleri, uygulama verilerini ve önbellekleri birbirinden ayırın. Bütün dosya sistemini sürekli taramak, özellikle yoğun sunucularda gereksiz disk okuması oluşturabilir. du sonucunu tek başına silme listesi olarak değerlendirmeyin: büyük bir veritabanı dosyası veya etkin sanal makine diski, kullanım bakımından dikkat çekse de güvenle kaldırılabilecek bir dosya değildir.

Büyük tekil dosyalar nasıl incelenir?

Şüpheli dizine indikten sonra dosyaların boyutlarını listeleyin; dosya adını, değiştirilme zamanını ve hangi hizmet tarafından üretildiğini birlikte yorumlayın. Özellikle arşiv, eski dağıtım paketi, başarısız dışa aktarma ve beklenmedik büyüklükteki günlük dosyaları araştırmaya değerdir. Dosyayı açan hizmeti veya uygulamanın saklama politikasını bilmeden silmeyin. Alan kullanımını gösteren araçlar dizin ağacını ve dosya sistemi genelini farklı düzeylerde ölçtüğünden, ileride görülebilecek tutarsızlıkları da not edin.

df ve du Sonuçları Neden Farklı Olabilir?

df dolu bir dosya sistemi gösterirken du ile toplanan görünür dizin boyutları daha küçük çıkabilir. Bu her zaman ölçüm hatası değildir. En önemli nedenlerden biri, bir dosyanın dizinden silinmesine rağmen onu kullanan işlemin (process) dosyayı açık tutmasıdır. Dosyanın adı artık dizinde görünmez; buna karşın işlem dosyayı serbest bırakana kadar kapladığı alan geri kazanılmayabilir.

Bu olasılığı incelemek için aşağıdaki komutu kullanın:

sudo lsof +L1

Çıktıdaki dosya yolunu, boyutunu ve işlem kimliğini değerlendirin. Ardından mümkünse ilgili hizmet için kontrollü bir günlük yeniden açma işlemi veya planlı yeniden başlatma uygulayın. Üretim veritabanını ya da kritik uygulamayı yalnızca alan kazanmak için aniden durdurmayın; önce işlem etkisini ve bakım penceresini belirleyin. df ile du arasındaki farkın başka nedenleri de olabileceğinden, tek bir açık dosya bulmayı bütün farkın açıklaması saymayın.

Silinen dosya neden hâlâ yer kaplar?

Linux'ta bir dosya adı dizinden kaldırıldığında, dosyayı açık tutan işlem mevcut dosya tanımlayıcısı (file descriptor) üzerinden veriye erişmeye devam edebilir. Bu davranış, çalışmakta olan hizmetin dosya silinmiş olsa bile neden yazmayı sürdürdüğünü açıklar. Güvenli çözüm, dosyayı oluşturan uygulamanın günlük yönetimini düzeltmek ve ilgili tanımlayıcının kontrollü biçimde kapanmasını sağlamaktır. Açık tanımlayıcıları körlemesine değiştirmek, veri bütünlüğü açısından riskli olabilir.

Güvenli Alan Açma Yöntemleri

Alan açarken en iyi sıra, önce doğrulama, sonra sınırlı müdahale, en son yeniden ölçüm şeklindedir. Tüm günlükleri veya geçici dizinleri topluca silmek yerine, hangi verinin saklama süresinin dolduğunu ve hangi uygulamanın veriye ihtiyaç duyduğunu belirleyin.

Sistem günlüklerini kontrollü yönetme

systemd-journald kullanan sistemlerde önce günlüklerin kapladığı alanı görün. Kurumun saklama yükümlülüklerine uygunsa arşivlenmiş günlükler için boyut sınırı uygulayın:

sudo journalctl --disk-usage
sudo journalctl --vacuum-size=500M

--vacuum-size yalnızca arşivlenmiş günlük dosyaları üzerinde etkili olduğundan, ikinci komuttan sonra bildirilen toplam kullanım beklenen değerin üzerinde kalabilir. Ayrıca olay incelemesi gereken bir sunucuda günlükleri azaltmadan önce ilgili kayıtları güvenli bir yere aktarın. Tekrarlayan büyümenin kök nedeni düzeltilmezse boşalan alan yeniden dolacaktır.

Paket ve uygulama önbellekleri

Ubuntu veya Debian tabanlı, APT paket yöneticisi kullanan bir sistemde indirilen paket önbelleğinin temizlenmesi değerlendirilebilir. İşlemin uygulama dosyalarını değil paket önbelleğini hedeflediğini doğrulamak için önce dağıtımı ve paket yöneticisini kontrol edin:

sudo apt clean

Bu komut her Linux dağıtımı için geçerli değildir. Uygulama önbelleklerinde ise genel bir silme komutu önermek güvenli olmaz. Bazı uygulamalar önbelleği yeniden üretirken bazıları aynı dizinde kullanıcı yüklemeleri veya oturum verileri tutabilir. Temizlik öncesinde uygulamanın veri yerleşimini, dosya sahipliğini ve hizmet hesabını inceleyin.

Hosting ve Uygulama Sunucularında Özel Senaryolar

Hosting ortamında tek bir hesabın yedek arşivleri veya medya yüklemeleri paylaşılan depolama alanını hızla tüketebilir. Bu durumda alan açma kararı yalnızca sistem yöneticisinin değil, verinin sahibinin de onayını gerektirebilir. Hesap bazındaki kullanım, e-posta kutuları, erişim günlükleri ve web uygulamasının oluşturduğu geçici dosyalar ayrı ayrı incelenmelidir.

Sanal sunucuda ise işletim sisteminin gördüğü bölüm boyutu ile satın alınan depolama kapasitesi aynı sorunun iki ayrı katmanıdır. Disk kapasitesi artırılmış olsa bile bölümün veya dosya sisteminin genişletilmesi gerekebilir; bu işlem kullanılan bölümleme düzenine göre planlanmalıdır. Kapasite artışı, kontrolsüz büyüyen bir dosyanın nedenini ortadan kaldırmaz.

• WordPress medya sitesi: Büyük yüklemeleri, üretilen görsel kopyalarını ve yerel yedek arşivlerini birbirinden ayırın; ziyaretçilerin kullandığı medya dosyalarını topluca silmeyin.
• Veritabanı ağırlıklı uygulama: Etkin veritabanı dosyalarını, işlem günlüklerini ve dışa aktarma dosyalarını farklı risk düzeylerinde değerlendirin.
• Konteynerli dağıtım: Kullanılmayan imajlarla kalıcı veri birimlerini (volume) karıştırmayın; veri birimleri uygulamanın tek veri kopyasını içerebilir.
• Yerel yedekleme: Her yedek döngüsünün üretim diski üzerinde birikmesi, bir arıza anında hem uygulamayı hem kurtarma sürecini etkileyebilir.

Disk Doluluğunu Önlemek İçin Kalıcı Önlemler

Tek seferlik temizlik sunucuyu çalışır duruma getirse de güvenilir işletim için izleme ve kapasite planlaması gerekir. Yalnızca kullanım yüzdesine alarm kurmak yeterli değildir: aynı yüzde, küçük ve büyük disklerde farklı miktarda kullanılabilir alan anlamına gelir. Kullanılan alanın artış hızı, boş kapasite, inode kullanımı ve hizmete özgü dizinlerin büyümesi birlikte izlenmelidir.

Örneğin bir uygulama günde birkaç gigabayt günlük üretiyorsa, bugünkü boş alan rahat görünse bile yoğun trafik döneminden önce müdahale gerekebilir. Alarm eşiklerini iş yükünün normal değişimine göre belirleyin; ani sıçramayı yakalayan uyarılar ile uzun vadeli büyüme eğilimini gösteren raporlar farklı amaçlara hizmet eder.

1. Günlük saklama politikası oluşturun: İşletim sistemi ve uygulama günlükleri için saklama süresi ile boyut sınırını ayrı ayrı tanımlayın.
2. Yedekleri ayrıştırın: Geri yükleme testinden geçmiş kopyaları uygun harici depolamada tutun; üretim diskindeki kopyaların yaşam döngüsünü yönetin.
3. Kapasite payı bırakın: Güncellemeler, geçici dosyalar ve beklenmedik trafik artışı için kullanılabilir alan planlayın.
4. Değişiklikleri kaydedin: Hangi dosyanın, neden ve kim tarafından temizlendiğini olay kaydına ekleyin.
5. Kök nedeni düzeltin: Hatalı bir döngü sürekli günlük yazıyorsa yalnızca günlüğü küçültmek kalıcı çözüm değildir.

Örnek Müdahale Akışı

Bir web uygulamasının dosya yükleyemediğini ve kök dosya sisteminin dolduğunu varsayalım. Önce df -hT ile dolu bağlama noktasını belirleyin; ardından df -i ile sorunun inode sınırı olup olmadığını ayırın. Kök bölüm doluysa du -xhd1 ile büyük üst dizini bulun. Örneğin /var öne çıkıyorsa aynı yöntemle onun alt dizinlerine inin.

Günlüklerin büyüdüğünü görürseniz önce büyümeye yol açan hataları inceleyin. Sistem günlüğü alanı yüksekse saklama gereksinimini kontrol edip desteklenen araçlarla sınırlı temizlik yapın. Buna karşılık görünür dosyalar beklenenden küçükse lsof +L1 ile silinmiş fakat açık dosyaları araştırın. Her müdahalenin ardından df -hT çıktısını yeniden kontrol edin ve dosya yükleme işlevini gerçek bir testle doğrulayın. Bu sıralama, yer açma işlemini hizmetin iyileşmesiyle karıştırmamanızı sağlar.

Sıkça Sorulan Sorular

Sonuç

Disk doluluğunda güvenli yaklaşım, önce dolu dosya sistemini belirlemek, sonra alanı tüketen veriyi tanımak ve yalnızca etkisi anlaşılan dosyalara müdahale etmektir. df, du ve gerektiğinde lsof farklı soruları yanıtlar; birlikte kullanıldıklarında gereksiz silme riskini azaltırlar. Kalıcı çözüm için günlük saklama, yedekleme ve kapasite izleme politikalarını da gözden geçirin.

İş yükünüzün depolama gereksinimi düzenli büyüyorsa Corelux Sanal Sunucu ve Kiralık Sunucu seçeneklerini kapasite ihtiyacınıza göre değerlendirebilirsiniz. Kurtarma planınızı güçlendirmek için Yedekleme Hizmeti seçeneklerini de inceleyin; yedekleme, disk temizliğinin değil, güvenli işletimin ayrı bir parçasıdır.