Disk Kullanımını İnceleme (df, du ve ncdu)

Bir sunucuda gece yarısı gelen "disk doldu" uyarısı, sistem yöneticisinin en sevmediği mesajlardan biridir. Web sunucusu yeni dosya yazamaz olur, veritabanı işlemleri yarıda kalır, e-posta kuyruğu şişer ve bazen SSH oturumu bile açılmaz hâle gelir çünkü kabuk geçici dosya yazacak yer bulamaz. İşin can sıkıcı yanı, panik anında çoğu kişinin diski nereye harcadığını bilmeden gelişigüzel dosya silmeye başlamasıdır. Oysa Linux, diskin nasıl dolduğunu adım adım ortaya çıkaran son derece keskin araçlarla gelir: df, du ve interaktif ncdu. Bu üç aracı doğru sırayla kullandığınızda birkaç dakika içinde "hangi bölüm dolu, o bölümde hangi dizin şişmiş, o dizinde hangi dosya suçlu" sorularının hepsini yanıtlarsınız.

Bu rehberde amacımız yalnızca komutların bayraklarını sıralamak değil; gerçek bir olayı çözer gibi düşünmenizi sağlamak. Önce df ile hangi dosya sisteminin dolduğunu tespit edeceğiz, ardından du ile o dosya sistemi içinde büyük dizinlere ineceğiz, sonra ncdu ile görsel olarak en büyük dosyaların üzerine gideceğiz. Yol boyunca inode tükenmesi, silinmiş ama hâlâ açık tutulan dosyalar, gizli log birikimi gibi klasik tuzaklara da değineceğiz. İster paylaşımlı bir hosting hesabında, ister kendi VDS sunucunuzda çalışın, buradaki mantık aynı şekilde işler.

Disk Doluluğunun İlk Fotoğrafı: df -h#

Bir disk sorununda atılacak ilk komut neredeyse her zaman df (disk free) olmalıdır. Bu komut her bağlı (mount edilmiş) dosya sistemi için toplam alanı, kullanılan alanı, boşta kalan alanı ve doluluk yüzdesini gösterir. -h bayrağı (human readable) değerleri byte yerine MB/GB gibi okunabilir birimlere çevirir.

df -h

Tipik bir çıktı şuna benzer:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   38G  1.9G  96% /
tmpfs           2.0G     0  2.0G   0% /dev/shm
/dev/vdb1       100G   45G   50G  48% /home

Buradaki en kritik sütun Use% ve Mounted on ikilisidir. Yukarıdaki örnekte kök dizin (/) yüzde 96 dolu, ama /home rahat durumda. Bu, sorunun /home altında değil, kök bölümde yani büyük ihtimalle /var, /tmp veya /usr gibi sistem dizinlerinde olduğunu söyler. Yanlış bölümü kurcalayarak zaman kaybetmemek için bu ilk adım altın değerindedir.

Sık kullanacağınız birkaç varyasyon vardır. Belirli bir dizinin hangi dosya sistemine düştüğünü öğrenmek için doğrudan yolu argüman verebilirsiniz:

df -h /var/www

Dosya sistemlerinin tipini de görmek isterseniz (ext4, xfs, overlay gibi) -T ekleyin. Bu, özellikle Docker kullanılan sunucularda overlay katmanlarını ayırt etmek için işe yarar:

df -hT

Bir noktaya dikkat: tmpfs gibi bellekte tutulan dosya sistemleri diskten yer yemez; onları eleyip gerçek blok cihazlarına (/dev/vda1 gibi) odaklanmak analizinizi hızlandırır.

Boyut Görünse de Yer Yoksa: inode Tükenmesi#

Bazen df -h diskte bol boş alan gösterir ama sistem yine de "No space left on device" hatası verir. Bu, klasik ama kafa karıştırıcı bir durumdur ve nedeni neredeyse her zaman inode tükenmesidir. Her dosya ve dizin, boyutu ne olursa olsun bir inode kaydı tüketir. Milyonlarca küçük dosya (örneğin PHP oturum dosyaları, mail kuyruğu, önbellek parçacıkları) diski byte olarak doldurmadan inode havuzunu bitirebilir.

inode kullanımını görmek için df'in -i bayrağını kullanın:

df -i

Filesystem      Inodes  IUsed  IFree IUse% Mounted on
/dev/vda1      2621440 2620100   1340  100% /

Yukarıda IUse% yüzde 100'de; disk boyutu boş olsa bile yeni dosya oluşturulamaz. Suçlu dizini bulmak için hangi klasörde kaç dosya olduğunu saydırabilirsiniz:

for dir in /var/*; do echo "$(find "$dir" -xdev 2>/dev/null | wc -l) $dir"; done | sort -n

Bu genellikle /var/spool/, /var/lib/php/sessions/ veya bir uygulamanın önbellek dizinini işaret eder. inode konusu başlı başına derin bir alandır; kota yönetimiyle birlikte nasıl ele alınacağını ayrıntılı anlattığımız disk kotası ve inode rehberimizden yararlanabilirsiniz. Bu adımı atlamayın, çünkü inode sorununu byte bazlı temizlik yaparak asla çözemezsiniz.

Klasör Boyutunu Ölçmek: du -sh#

df size hangi bölümün dolu olduğunu söyler ama o bölümün içinde suçlunun kim olduğunu söylemez. Burada devreye du (disk usage) girer. du bir dizin ağacını tarayıp içindeki dosyaların toplam boyutunu hesaplar. En sık kullanacağınız kalıp -sh bayrak ikilisidir: -s özet (summary, alt dizinleri tek tek değil toplam olarak göster), -h okunabilir birim.

Belirli bir dizinin toplam boyutunu öğrenmek için:

du -sh /var/www

Tek bir klasör yerine, bir dizinin altındaki tüm alt klasörlerin boyutunu ayrı ayrı görmek istediğinizde joker karakter kullanın:

du -sh /var/*

1.2G    /var/cache
88M     /var/lib
14G     /var/log
2.1G    /var/spool

Bu çıktı bir sistem yöneticisi için altın madenidir: /var/log tek başına 14 GB yemiş. Çoğu zaman gerçek suçlu budur, çünkü döndürülmeyen (rotate edilmeyen) log dosyaları sessizce büyür.

du çalıştırırken bilinmesi gereken birkaç önemli davranış vardır. Varsayılan olarak du bağlı diğer dosya sistemlerine de geçer; analizinizi tek bir dosya sistemiyle sınırlamak için -x (aynı dosya sistemi) bayrağını ekleyin. Ayrıca izin hatalarını gözden gizlemek için stderr çıktısını yönlendirmek işleri temiz tutar:

du -shx /var/* 2>/dev/null

-s yerine --max-depth=1 kullanmak, bir dizinin hem toplamını hem de bir alt seviyesini aynı anda görmek için pratiktir ve büyük ağaçlarda gezinirken çok işinize yarar.

En Büyükleri Sıralamak: du ile sort Kombinasyonu#

du -sh /var/* çıktısı okunabilir ama sıralı değildir; gözünüzle en büyüğü aramak zorunda kalırsınız. İşte burada du ile sort komutunu birleştirmek analizi otomatikleştirir. Ancak -h ile üretilen "14G", "88M" gibi değerler alfabetik sıralandığında yanıltıcı olur (çünkü "9M" metinsel olarak "14G"den büyük görünür). İki temiz çözüm vardır.

Modern sort sürümlerinde -h bayrağı okunabilir birimleri doğru sıralar:

du -shx /var/* 2>/dev/null | sort -rh

Bu, en büyüğü en üstte olacak şekilde bölümleri sıralar. -r ters (büyükten küçüğe), -h ise "1.2G > 88M" karşılaştırmasını doğru yapar.

Tüm sistemde en büyük on dizini bulmak için klasik bir kalıp şudur:

du -ahx / 2>/dev/null | sort -rh | head -n 20

Burada -a dosyaları da dahil eder, böylece tek başına devasa bir log dosyası veya yedek arşivi de listeye girer. Bu komut büyük bir diskte biraz zaman alabilir; işlemi bir dizinle sınırlarsanız (/var gibi) çok daha hızlı sonuç alırsınız.

En büyük tekil dosyaları doğrudan avlamak istediğinizde find daha keskindir. Örneğin 500 MB üzerindeki tüm dosyaları boyutlarıyla listelemek için:

find / -xdev -type f -size +500M -exec ls -lh {} \; 2>/dev/null | awk '{ print $5, $9 }'

-xdev bayrağı find'in başka dosya sistemlerine dalmasını engeller, bu da /proc ve /sys gibi sanal dizinlerde boşuna dolaşmayı önler. Bu tür tek satırlık komutları sık kullanıyorsanız, çeşitli hesaplama ve dönüştürme işleri için çevrimiçi araçlarımıza da göz atabilirsiniz.

İnteraktif Görsel Analiz: ncdu#

df ve du mükemmel araçlardır ama büyük ve karmaşık bir ağaçta elle gezinmek yorucu olabilir. ncdu (NCurses Disk Usage) tam da bu boşluğu doldurur: terminal içinde çalışan, ok tuşlarıyla dizinlerin içine girip çıkabileceğiniz, her klasörün boyutunu bir çubuk grafikle gösteren interaktif bir arayüz sunar. Bir kez alıştığınızda disk analizi yapmanın en hızlı yolu hâline gelir.

Çoğu dağıtımda paket deposundan kolayca kurulur:

# Debian / Ubuntu
apt install ncdu

# RHEL / AlmaLinux / Rocky
dnf install ncdu

Kullanımı son derece basittir. Analiz etmek istediğiniz dizini argüman verirsiniz; ncdu bir kez tarar ve sonucu sıralı olarak sunar:

ncdu /var

Tarama bittiğinde büyükten küçüğe sıralı bir liste görürsünüz. Ok tuşlarıyla bir dizinin üzerine gelip Enter'a basarak içine girer, sol ok veya .. ile bir üst seviyeye çıkarsınız. En kullanışlı kısayollar şunlardır: bir dosya veya dizini d tuşuyla doğrudan arayüzden silebilir, n ile isme göre, s ile boyuta göre sıralayabilir, g ile yüzde/çubuk gösterimini değiştirebilir ve ? ile yardım ekranını açabilirsiniz.

Uzaktaki bir sunucuda kök dizini tararken diğer dosya sistemlerine geçmesini engellemek iyi bir alışkanlıktır:

ncdu -x /

Bir profesyonel ipucu: çok büyük bir sunucuda ncdu taramasını sonradan incelemek üzere dosyaya kaydedip başka bir makinede açabilirsiniz. Bu, üretim sunucusundaki yükü azaltır:

# Sunucuda tara ve kaydet
ncdu -o disk-tarama.json -x /

# İncelerken geri yükle
ncdu -f disk-tarama.json

ncdu özellikle "yer bir yerde ama bulamıyorum" durumlarında paha biçilmezdir; gözle en büyük dalın peşinden inerek suçluyu birkaç Enter'da bulursunuz.

Sinsi Suçlular: Loglar, Silinmiş Açık Dosyalar ve Gizli Birikimler#

Disk dolduğunda en sık karşılaşılan senaryolardan biri kontrolsüz büyüyen log dosyalarıdır. Bir uygulamanın hata ayıklama modunda unutulması ya da logrotate yapılandırmasının bir servisi kapsamaması, /var/log altında tek bir dosyanın onlarca gigabayta ulaşmasına yol açabilir. Öncelikle en büyük logları bulun:

du -ah /var/log 2>/dev/null | sort -rh | head -n 15

Systemd tabanlı sistemlerde journal loglarının şişmesi de yaygındır. Mevcut journal boyutunu görmek ve makul bir sınıra çekmek için:

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

İkinci sinsi durum, silinmiş ama hâlâ açık tutulan dosyalardır. Bir süreç bir log dosyasına yazarken siz o dosyayı rm ile silerseniz, süreç dosyayı kapatana kadar disk alanı geri gelmez; df diski dolu gösterirken du toplamı çok daha düşük çıkar. Bu paradoksu şu komutla teşhis edersiniz:

lsof +L1 2>/dev/null | grep deleted

Çözüm genellikle ilgili servisi yeniden başlatmaktır (systemctl restart nginx gibi), böylece açık tutulan tanımlayıcı serbest kalır ve alan anında geri döner.

Üçüncü olarak gizli dosya ve dizinleri unutmayın. du -sh * komutu nokta ile başlayan gizli öğeleri (.cache, .npm, .local gibi) atlar. Bir kullanıcının ev dizininde asıl şişkinlik çoğu zaman bu gizli klasörlerdedir. Hepsini kapsayan doğru komut şudur:

du -sh /home/kullanici/{,.[!.],..?}* 2>/dev/null | sort -rh

Web sunucularında ayrıca uygulama önbellekleri (Laravel storage/logs, WordPress wp-content/cache, Magento var/) hızla büyür. Sitenizin taşınması veya düzenli temizliği söz konusuysa site taşıma ve WordPress bakım hizmetlerimiz bu tür birikimleri profesyonelce yönetir. Düzenli yedekleme yapıyorsanız, eski yedek arşivlerinin de sunucu üzerinde birikip diski doldurmadığından emin olun.

Kalıcı Çözüm: İzleme, Otomasyon ve Kapasite Planı#

Diski elle temizlemek yangını söndürür ama tekrar çıkmasını engellemez. Kalıcı çözüm, dolmayı daha eşiğe gelmeden fark etmektir. En basit önlem, önemli bölümlerin doluluğunu belirli aralıklarla kontrol edip belirli bir yüzdeyi aşınca uyarı gönderen küçük bir betiktir:

#!/usr/bin/env bash
ESIK=85
df -P | awk 'NR>1 {gsub("%","",$5); print $5, $6}' | while read yuzde mount; do
  if [ "$yuzde" -ge "$ESIK" ]; then
    echo "UYARI: $mount bölümü %$yuzde dolu" | mail -s "Disk uyarisi" root
  fi
done

Bu betiği cron ile örneğin her 30 dakikada bir çalıştırarak dolma tehlikesini daha zaman varken yakalarsınız:

*/30 * * * * /usr/local/bin/disk-kontrol.sh

Log kaynaklı dolmalara karşı logrotate yapılandırmanızın tüm servisleri kapsadığından emin olun. Örneğin özel bir uygulamanın logu için /etc/logrotate.d/uygulamam altına şuna benzer bir kural eklemek büyümenin önüne geçer:

/var/log/uygulamam/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    copytruncate
}

Bazen sorun temizlikle değil, gerçekten yetersiz kapasiteyle ilgilidir. Sitenizin verisi büyüdüyse ya da yeni servisler eklendiyse, sürekli temizlik yerine daha geniş bir diske geçmek daha mantıklıdır. Ölçeklenebilir sanal sunucu ve VDS planlarımız disk alanını esnek biçimde büyütmenize izin verir; yönetim yükünü üstlenmek istemezseniz sunucu yönetimi hizmetimizle disk izleme ve kapasite planlamasını bizim ekibimiz yürütür. Yeterli belleği olmayan sunucularda geçici baskıyı azaltmak için swap alanı oluşturma rehberimize de göz atabilirsiniz; ancak swap'ın diskte yer kapladığını ve bir disk-dolu çözümü olmadığını unutmayın.

Sıkça Sorulan Sorular#

df neden boş alan gösteriyor ama disk yine de dolu diyor?#

Bu durumun iki tipik nedeni vardır. Ya inode havuzu tükenmiştir (byte boş olsa da yeni dosya kaydı açılamaz), bunu df -i ile doğrularsınız; ya da bir süreç silinmiş bir dosyayı hâlâ açık tutmaktadır. İkinci durumda df alanı dolu, du toplamı ise düşük görünür. lsof +L1 | grep deleted komutuyla suçlu süreci bulup yeniden başlatarak alanı geri kazanırsınız.

du ve df neden farklı sonuç veriyor?#

df çekirdeğin dosya sistemi seviyesindeki muhasebesini okur, du ise dizin ağacını gezerek dosya boyutlarını toplar. İkisi arasındaki fark genellikle silinmiş ama açık tutulan dosyalardan, du'nun okuyamadığı izin kısıtlı dizinlerden ya da başka bir dosya sisteminin bir alt dizine bağlı olmasından kaynaklanır. du -x ile tek dosya sistemine sınırlamak ve 2>/dev/null ile izin hatalarını görmek farkın kaynağını netleştirir.

ncdu paylaşımlı hosting hesabımda çalışır mı?#

Çoğu paylaşımlı hosting ortamında ncdu kurulu olmayabilir ve kurma yetkiniz de bulunmaz. Bu durumda kendi ev dizininizde du -sh */ .[!.]*/ | sort -rh komutuyla benzer bir analiz yapabilirsiniz. Kök seviyesine erişiminizin olduğu bir VDS veya sanal sunucuda ise ncdu'yu paket yöneticisiyle kurup tüm gücünden yararlanırsınız. Paylaşımlı hosting hesabınızın kotasını cPanel'in disk kullanımı ekranından da izleyebilirsiniz.

En büyük dosyaları tek komutla nasıl bulurum?#

Tüm sistemde en büyük dosyaları listelemenin en pratik yolu find ile boyut filtresidir. Örneğin find / -xdev -type f -size +1G -exec ls -lh {} \; 2>/dev/null komutu 1 GB'den büyük tüm dosyaları gösterir. Dizin bazında sıralama için du -ahx / 2>/dev/null | sort -rh | head -n 20 kalıbı hem büyük klasörleri hem büyük tek dosyaları aynı listede verir. -xdev bayrağı sanal dosya sistemlerinde boşuna dolaşmayı önler.

Diski temizledim ama alan geri gelmedi, ne yapmalıyım?#

Genellikle sorumlu bir servisin sildiğiniz dosyayı hâlâ açık tutmasıdır. lsof +L1 | grep deleted çıktısında dosyayı tutan süreci bulun ve o servisi yeniden başlatın; alan anında serbest kalır. Ayrıca df sonuçlarının önbelleğe takılmadığından emin olmak için komutu birkaç saniye sonra tekrar çalıştırın. Silme işleminden sonra hâlâ dolu görünüyorsa, farklı bir dosya sisteminde (örneğin ayrı bir /var bölümünde) temizlik yapmış olabilirsiniz; önce df -h ile doğru bölümü doğrulayın.

Disk sürekli doluyorsa kalıcı çözüm nedir?#

Tekrarlayan dolmalar iki şeyden birini işaret eder: ya kontrolsüz büyüyen bir kaynak (log, önbellek, geçici dosya) vardır, ya da gerçek kapasiteniz iş yükünüzün altında kalmıştır. İlk durumda logrotate ve düzenli önbellek temizliği ile kaynağı dizginlersiniz. İkinci durumda daha büyük diskli bir plana geçmek doğru adımdır. Doluluk eşiğini izleyen bir cron betiği kurmak, sorunu daha kritik hâle gelmeden yakalamanızı sağlar; yönetimi bize bırakmak isterseniz sunucu yönetimi hizmetimiz bu izlemeyi sizin için üstlenir.

Kapanış#

Disk analizi aslında bir dedektiflik işidir ve doğru sırayla ilerlediğinizde son derece hızlıdır: df -h ile hangi bölümün dolduğunu belirleyin, df -i ile inode tükenmesini eleyin, du -shx ... | sort -rh ile suçlu dizine inin ve ncdu ile en büyük dosyanın üzerine gidin. Bu dört adımı bir refleks hâline getirdiğinizde, "disk doldu" alarmı artık bir kriz değil, birkaç dakikalık rutin bir bakım işine dönüşür. Silmeden önce mutlaka neyi sildiğinizi anlayın ve log gibi büyüyen kaynakları en baştan logrotate ile disipline edin.

Sunucunuzun disk yükünü kendiniz takip etmek yerine uzman bir ekibin izlemesini ve gerektiğinde kapasiteyi büyütmesini isterseniz, esnek diskli VDS ve sanal sunucu planlarımız ile tam kapsamlı sunucu yönetimi hizmetimiz tam size göre. Clou.TR altyapısında disk alanınızı büyütmek, yedeklemek ve izlemek birkaç tıkla mümkün; siz işinize odaklanın, altyapının sağlığını biz üstlenelim.