Linux'ta Disk Alanı Tespiti ve Temizleme Rehberi

Gece 2’de çalan telefon, hepimizin korkulu rüyasıdır. “Disk doldu, uygulama çöktü” mesajı aldığında ne yapacağını bilmek, iyi bir sistem yöneticisini ortalamadan ayıran şeydir. Disk alanı yönetimi kulağa basit gelse de pratikte onlarca farklı senaryo, onlarca farklı sebep ve onlarca farklı çözüm yolu var. Bu yazıda baştan sona gerçek dünya deneyimleriyle disk alanı sorunlarını nasıl tespit edip temizleyeceğini anlatacağım.

Durumu Hızla Anlamak: İlk Adımlar

Bir sunucuya bağlandığında ilk yapman gereken şey genel durumu görmek. Paniklemeden, sakin bir şekilde aşağıdaki komutları sırayla çalıştır.

df -hT

Bu komut tüm mount noktalarını, dosya sistemi tiplerini ve doluluk oranlarını gösterir. Çıktıda %100 veya %95 üzeri gördüğün her satır potansiyel sorun demektir. -T parametresi dosya sistemi tipini gösterir, tmpfs gibi sanal dosya sistemlerini gerçek disklerden ayırt etmeni sağlar.

df -hi

Burada inode kullanımına bakıyoruz. Çok sık karşılaşılan ve çok az akla gelen bir sorun var: disk alanı olmasına rağmen inode dolduğunda da dosya yazamazsın. Küçük boyutlu milyonlarca dosya oluşturan uygulamalar (mail sunucuları, önbellek sistemleri) inode’u bitirebilir. Eğer IUse% sütununda %100 görüyorsan sorun inode dolması demektir.

lsblk -f

Bu komut disk bölümleme yapısını ağaç şeklinde gösterir. Hangi diskin nereye mount edildiğini, UUID bilgilerini ve dosya sistemi tipini tek bakışta görebilirsin.

Yer Kaplayanı Bulmak: du ile Derinlemesine Analiz

df genel durumu gösterir, ama asıl iş du ile başlar. Hangi dizin ne kadar yer kaplıyor, bunu bulmadan temizlik yapamazsın.

du -sh /* 2>/dev/null | sort -rh | head -20

Bu komut kök dizindeki her klasörün boyutunu hesaplar, büyükten küçüğe sıralar ve ilk 20’yi gösterir. 2>/dev/null kısmı “Permission denied” hatalarını susturur. Çıktıda /var veya /home gibi bir dizin olağandışı büyük görünüyorsa oraya dalacağız.

Diyelim ki /var şüpheli göründü:

du -sh /var/* 2>/dev/null | sort -rh | head -20

Aynı mantıkla dalıyoruz. /var/log büyük çıktıysa:

du -sh /var/log/* 2>/dev/null | sort -rh | head -20

Bu şekilde suçluyu bulana kadar kazıyorsun. Gerçek bir deneyimden bahsedeyim: bir üretim sunucusunda /var/lib/docker 200 GB’ı aşmıştı. Docker imajları, durmuş konteynerler ve kullanılmayan volume’ler birikmiş, kimse fark etmemişti. Üç aylık ihmal, üç saatlik temizlik gerektirdi.

ncdu ile Görsel Analiz

Eğer sunucuda ncdu kuruluysa veya kurabileceksen, hayatın çok daha kolaylaşır:

# Kurulum
apt install ncdu   # Debian/Ubuntu
yum install ncdu   # RHEL/CentOS

# Çalıştırma
ncdu /

ncdu interaktif bir arayüz sunar. Ok tuşlarıyla gezebilir, d ile silme yapabilir, n ile isme göre, s ile boyuta göre sıralayabilirsin. Özellikle remote sunucularda SSH üzerinden çok kullanışlıdır.

Log Dosyaları: En Büyük Suçlu

Deneyimlerime göre disk dolmalarının %60’ından fazlasında log dosyaları suçludur. Uygulama hata ayıklaması için debug modu açılmış ve unutulmuş, logrotate düzgün yapılandırılmamış veya bir uygulama aynı hatayı saniyede yüzlerce kez logluyor olabilir.

# En büyük log dosyalarını bul
find /var/log -type f -name "*.log" -exec du -sh {} ; 2>/dev/null | sort -rh | head -20

# Son 1 saatte değişen log dosyalarını bul (aktif olarak büyüyenleri)
find /var/log -type f -name "*.log" -newer /tmp/timestamp_check 2>/dev/null

Aktif olarak büyüyen bir log dosyası bulduysan içine bakman gerekiyor:

tail -f /var/log/uygulama/error.log

Eğer aynı hata satırı sürekli tekrarlanıyorsa, önce uygulamadaki sorunu çöz, sonra log dosyasını temizle. Sıralamayı karıştırma, aksi halde log dolmaya devam eder.

Güvenli log temizleme şu şekilde yapılır. Dosyayı silmek yerine içini boşalt, çünkü çalışan bir process dosyayı tutuyorsa silmek disk alanını gerçekten boşaltmaz:

# Doğru yöntem: dosyayı truncate et
> /var/log/uygulama/error.log

# veya
truncate -s 0 /var/log/uygulama/error.log

# Yanlış yöntem (process dosyayı tutuyorsa boşaltmaz):
# rm /var/log/uygulama/error.log

Logrotate Kontrolü

Logrotate düzgün çalışıyor mu kontrol et:

# Logrotate durumunu gör
cat /var/lib/logrotate/status

# Manuel olarak çalıştır
logrotate -f /etc/logrotate.conf

# Spesifik bir konfigürasyonu test et
logrotate -d /etc/logrotate.d/nginx

Silinmiş ama Hala Yer Kaplayan Dosyalar

Bu durum birçok sysadmin’i şaşırtır. df disk doldu gösteriyor ama du ile toplayınca rakamlar tutmuyor. Bunun sebebi, çalışan bir process tarafından açık tutulan dosyaların silinmesi. Dosya dizinden kaldırılır ama process kapatılana kadar inode ve disk bloğu serbest bırakılmaz.

# Silinmiş ama hala açık tutulan dosyaları bul
lsof +L1 2>/dev/null

# Sadece büyük olanları göster
lsof +L1 2>/dev/null | awk 'NR>1 {print $7, $1, $2, $9}' | sort -rn | head -20

Çıktıda (deleted) ile işaretlenmiş büyük dosyalar görüyorsan, o process’i restart etmek disk alanını geri kazandırır:

# Process'i bul ve yeniden başlat
systemctl restart nginx
# veya
kill -HUP <PID>

Geçici Dosyalar ve Cache Temizliği

/tmp Dizini

# /tmp boyutunu kontrol et
du -sh /tmp

# 7 günden eski geçici dosyaları temizle
find /tmp -type f -atime +7 -delete
find /tmp -type d -empty -delete

Modern sistemlerde /tmp için systemd-tmpfiles kullanılır:

# Geçici dosya temizleme kurallarını çalıştır
systemd-tmpfiles --clean

# Konfigürasyonları gör
ls /etc/tmpfiles.d/
cat /usr/lib/tmpfiles.d/tmp.conf

Paket Yöneticisi Cache

Paket yöneticilerinin cache dizinleri zamanla ciddi boyutlara ulaşır.

# Debian/Ubuntu için
apt clean          # Cache'i tamamen temizle
apt autoclean      # Eski paket versiyonlarını sil
apt autoremove     # Kullanılmayan bağımlılıkları kaldır

# Cache boyutunu görmek için
du -sh /var/cache/apt/

# RHEL/CentOS/Rocky için
yum clean all
dnf clean all
du -sh /var/cache/yum/
du -sh /var/cache/dnf/

Bir müşteri ortamında /var/cache/apt dizini 8 GB’ı aşmıştı. Yıllardır apt clean çalıştırılmamıştı. Tek komutla 8 GB geri kazanıldı.

Docker: Gizli Disk Canavarı

Docker kullanan sistemlerde disk yönetimi ayrı bir uzmanlık gerektirir. Kullanılmayan imajlar, durmuş konteynerler ve anonim volume’ler hızla birikerek ciddi yer kaplar.

# Docker disk kullanım özeti
docker system df

# Ayrıntılı görünüm
docker system df -v

# Kullanılmayan her şeyi temizle (konteynerler, imajlar, ağlar, build cache)
docker system prune -a

# Sadece durmuş konteynerleri temizle
docker container prune

# Kullanılmayan imajları temizle
docker image prune -a

# Kullanılmayan volume'leri temizle (DİKKATLİ OL, veri kaybı olabilir)
docker volume prune

docker system prune -a komutunu çalıştırmadan önce hangi imajların kullanımda olduğunu kontrol et. Özellikle üretim ortamında bu komutu dikkatli kullanmalısın.

Büyük Dosyaları Sistematik Olarak Bulmak

Bazen log veya cache dışında beklenmedik yerlerde dev dosyalar olabilir. Core dump dosyaları, eski yedekler, geliştirici tarafından bırakılan test verileri bunların başında gelir.

# 100 MB'dan büyük tüm dosyaları bul
find / -type f -size +100M -exec ls -lh {} ; 2>/dev/null | sort -k5 -rh | head -30

# Hem boyutu hem konumu düzgün görüntüle
find / -type f -size +500M 2>/dev/null -exec du -sh {} ; | sort -rh

# Core dump dosyalarını bul
find / -name "core" -o -name "core.*" -type f 2>/dev/null | xargs du -sh 2>/dev/null

# Belirli bir süreden eski büyük dosyaları bul (30 günden eski, 50 MB'dan büyük)
find /home -type f -size +50M -mtime +30 2>/dev/null -exec ls -lh {} ;

/home Dizini ve Kullanıcı Kotaları

Çok kullanıcılı sistemlerde /home dizini beklenmedik biçimde dolabilir.

# Kullanıcı bazında disk kullanımı
du -sh /home/* 2>/dev/null | sort -rh

# Her kullanıcının en büyük dosyalarını bul
for user in $(ls /home); do
    echo "=== $user ==="
    find /home/$user -type f -size +100M 2>/dev/null -exec du -sh {} ;
done

# Quota kontrolü
quota -u kullanici_adi
repquota -a

Eski Kernel ve Sistem Dosyaları

Özellikle Ubuntu sistemlerinde eski kernel dosyaları /boot dizinini doldurabilir. Bu çok yaygın bir sorundur.

# Mevcut kernel'i göster
uname -r

# Kurulu tüm kernel'leri listele (Debian/Ubuntu)
dpkg --list | grep linux-image

# Kullanılmayan eski kernel'leri temizle
apt autoremove --purge

# /boot boyutunu kontrol et
df -h /boot
du -sh /boot/*

/boot disk dolduğunda sistem yeni kernel güncellemelerini uygulayamaz ve bu ciddi bir güvenlik riskidir. Bu durumu monitoring ile takip etmek önemlidir.

Yedek ve Arşiv Dosyaları

Sistem yöneticileri çoğu zaman yedekleri uygunsuz yerlere atar veya eski yedekleri silmeyi unutur.

# Sıkıştırılmış arşiv dosyalarını bul
find / -type f ( -name "*.tar.gz" -o -name "*.zip" -o -name "*.tar.bz2" -o -name "*.tgz" ) 2>/dev/null -exec du -sh {} ; | sort -rh | head -20

# SQL dump dosyalarını bul
find / -type f -name "*.sql" -o -name "*.sql.gz" 2>/dev/null | xargs du -sh 2>/dev/null | sort -rh | head -10

# Belirli bir günden eski yedekleri bul
find /backup -type f -mtime +90 2>/dev/null | xargs ls -lh | head -20

Proaktif Monitoring: Bir Daha Uyanma

Sorunu çözdükten sonra asıl önemli kısım tekrar yaşanmamasını sağlamak. İzleme olmadan yönetim olmaz.

Basit bir disk doluluk alarm scripti:

#!/bin/bash
# /usr/local/bin/disk-monitor.sh

ESIK=85
EMAIL="[email protected]"
HOSTNAME=$(hostname)

df -H | grep -vE '^Filesystem|tmpfs|cdrom|udev' | awk '{ print $5 " " $6 }' | while read output; do
    KULLANIM=$(echo $output | awk '{ print $1}' | cut -d'%' -f1)
    PARTITION=$(echo $output | awk '{ print $2 }')

    if [ $KULLANIM -ge $ESIK ]; then
        MESAJ="UYARI: $HOSTNAME sunucusunda $PARTITION bölümü %$KULLANIM doluluk oranına ulaştı!"
        echo "$MESAJ" | mail -s "Disk Doluluk Uyarısı - $HOSTNAME" $EMAIL
        logger -t disk-monitor "$MESAJ"
    fi
done

Bu scripti cron’a ekle:

# Her 30 dakikada bir çalıştır
*/30 * * * * /usr/local/bin/disk-monitor.sh

# Crontab'a ekle
crontab -e

Eğer Prometheus veya Zabbix gibi bir monitoring sisteminiz varsa disk metriklerini oraya entegre etmek çok daha sağlıklıdır. node_exporter kullanıyorsan disk metrikleri zaten otomatik olarak toplanıyor demektir.

Dosya Sistemi Boyutunu Artırma

Temizlik yapıldı ama yetmiyorsa veya kalıcı çözüm gerekiyorsa dosya sistemi boyutunu artırman gerekebilir. LVM kullanıyorsan bu oldukça kolay:

# LVM durumunu göster
lvdisplay
vgdisplay

# Volume group'ta boş alan varsa logical volume'ü genişlet
lvextend -L +20G /dev/mapper/vg0-var

# Dosya sistemini yeniden boyutlandır (ext4 için)
resize2fs /dev/mapper/vg0-var

# XFS için (XFS küçültemezsin, sadece büyütebilirsin)
xfs_growfs /var

Bu işlemi canlı sistemde, unmount etmeden yapabilirsin. Ama yine de önemli adımlar öncesinde snapshot almayı unutma.

Sonuç

Disk yönetimi reaktif değil, proaktif bir iş olmalı. Sorun çıkınca koşturmak yerine düzenli monitoring, otomatik log rotasyonu ve periyodik temizlik prosedürleri hayatını çok kolaylaştırır.

Özetlemek gerekirse; df -hT ile genel durumu gör, du -sh ile suçluyu bul, log dosyalarını ve package cache’i temizle, silinmiş ama açık tutulan dosyaları kontrol et, Docker varsa düzenli olarak prune yap. Bunları bir checklist olarak haftaya bir çalıştırmanı öneririm.

Bir de şunu söyleyeyim: temizlemeden önce mutlaka ne sildiğini bil. “Hızlı temizlik” yaparken kritik bir veritabanı dosyasını veya konfigürasyonu silen sistem yöneticileri maalesef az değil. Şüphe ettiğin her şeyi önce bir yere yedekle, sonra sil. Disk alanı kurtarmak, kaybettiğin veriyi geri getirmekten her zaman daha kolaydır.

Dolup Taşan Disk Alanını Tespit Etme ve Temizleme