Disk Doldu Sorunları: Yer Açma ve Önleme Rehberi

Sabah 3’te telefonun çalması ve “site çöktü” mesajı almak… Her sysadmin’in korkulu rüyası. Sunucuya bağlanıyorsun, df -h yazıyorsun ve görüyorsun: %100 dolu disk. Panik yapmaya gerek yok, bu sorun hem çözülebilir hem de önlenebilir. Bu yazıda disk doldu sorunlarını nasıl hızlıca çözeceğini, yeri nereden açacağını ve bir daha bu duruma düşmemek için neler yapabileceğini detaylıca anlatacağım.

Durumu Anlamak: Nerede Ne Kadar Yer Var?

İlk adım her zaman mevcut durumu anlamaktır. Panikle dosya silmeye başlamak yerine önce durumu değerlendirmek gerekir.

# Tüm mount noktalarının kullanımını göster
df -h

# Sadece gerçek disk bölümlerini göster (tmpfs, devtmpfs hariç)
df -hT | grep -v tmpfs

# Inode kullanımını kontrol et (bu çok önemli, unutulur!)
df -i

df -h çıktısında /var veya / partisyonunun %100 dolu olduğunu gördüğünde asıl soru şu: “Hangi dosyalar bu alanı yiyor?” İşte burada du komutu devreye giriyor.

# En çok yer kaplayan dizinleri bul (kök dizinden başla)
du -sh /* 2>/dev/null | sort -rh | head -20

# /var dizini şüpheliyse oraya odaklan
du -sh /var/* 2>/dev/null | sort -rh | head -10

# Daha derine in
du -sh /var/log/* 2>/dev/null | sort -rh | head -10

Burada dikkat etmen gereken önemli bir nokta var: Inode dolması. Bazen df -h çıktısında yer var gibi görünse de sistem dosya oluşturamıyor olabilir. Bu durumda df -i komutunun çıktısına bakman gerekir. Eğer inode kullanımı %100’e yakınsa, küçük çok sayıda dosya (örneğin mail spool dosyaları, PHP session dosyaları) sorun yaratıyor olabilir.

Hızlı Yer Açma: Acil Müdahale

Sistem çalışmıyorsa önce biraz nefes alacak kadar alan açman gerekir. İşte hızlı çözümler:

Log Dosyaları Temizliği

Log dosyaları genellikle birinci suçludur. Özellikle /var/log dizini kontrol edilmelidir.

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

# Eski ve sıkıştırılmış log dosyalarını sil (dikkatli ol!)
find /var/log -name "*.gz" -mtime +30 -delete
find /var/log -name "*.1" -mtime +7 -delete

# Aktif log dosyasını silmeden içini boşalt (bu kritik!)
# Dosyayı silersen servis hata verebilir
> /var/log/nginx/access.log
# veya
truncate -s 0 /var/log/nginx/access.log

Önemli uyarı: Aktif olarak yazılan bir log dosyasını rm ile silersen, servis dosyayı hâlâ açık tuttuğu için disk alanı serbest kalmaz. Bu yüzden ya truncate kullanman ya da servisi yeniden başlatman gerekir.

Silinen Ama Hâlâ Açık Olan Dosyalar

Bu durum çok sık karşılaşılan ve insanların atladığı bir tuzaktır. Bir dosyayı sildin ama disk alanı serbest kalmadı mı? Muhtemelen bir servis o dosyayı hâlâ açık tutuyor.

# Silinen ama hâlâ açık olan dosyaları listele
lsof | grep deleted

# Sadece büyük olanları göster
lsof | grep deleted | awk '{print $7, $1, $2}' | sort -rn | head -20

Çözüm: İlgili servisi yeniden başlatmak. Örneğin bir web sunucusu eski log dosyasını tutuyorsa:

systemctl restart nginx
# veya
systemctl restart apache2

Servis yeniden başladıktan sonra eski dosya gerçekten diskten silinir ve alan serbest kalır.

Package Manager Önbelleği

# Ubuntu/Debian sistemlerde
apt-get clean
apt-get autoclean
apt-get autoremove

# RHEL/CentOS/Rocky Linux sistemlerde
yum clean all
# veya
dnf clean all

# Önbellek boyutunu kontrol et
du -sh /var/cache/apt/
du -sh /var/cache/yum/

Journal Logları

Systemd kullanan modern Linux sistemlerde journal logları beklenmedik boyutlara ulaşabilir.

# Mevcut journal boyutunu gör
journalctl --disk-usage

# Belirli süreden eski logları sil
journalctl --vacuum-time=7d

# Belirli boyuta kısıtla
journalctl --vacuum-size=500M

Gerçek Dünya Senaryosu: /var/log/syslog 50GB Olmuş

Bu senaryo ile karşılaşmadım demiyorum, tam tersine birden fazla kez yaşadım. Genellikle sebebi şudur: Bir uygulama döngüsel olarak hata üretiyor ve her saniye binlerce satır log yazıyor.

# Dosyanın ne zaman ve ne kadar büyüdüğünü anlamak için
ls -lh /var/log/syslog
tail -100 /var/log/syslog | less

# Hangi servis bu kadar log üretiyor?
tail -1000 /var/log/syslog | awk '{print $5}' | sort | uniq -c | sort -rn | head -10

Çoğunlukla kernel mesajları, bir donanım hatası veya yanlış yapılandırılmış bir daemon bu duruma yol açar. Kaynağı bulduktan sonra hem log dosyasını temizler hem de asıl sorunu çözersin.

# Temizlik
truncate -s 0 /var/log/syslog

# Logrotate'i manuel tetikle
logrotate -f /etc/logrotate.conf

Docker Kullanıyorsan: Gizli Yer Kaplayıcılar

Docker kullanan sistemlerde disk alanının nereye gittiğini bulmak başlı başına bir maceradır.

# Docker'ın ne kadar yer kapladığını gör
docker system df

# Kullanılmayan container, image, volume ve network'leri temizle
docker system prune -a

# Sadece durmuş container'ları temizle
docker container prune

# Kullanılmayan image'ları temizle
docker image prune -a

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

Docker log dosyaları da büyük bir sorun olabilir. Container’lar varsayılan olarak sınırsız log yazabilir.

# Bir container'ın log boyutunu kontrol et
docker inspect container_adi | grep LogPath
du -sh $(docker inspect container_adi | grep LogPath | awk -F'"' '{print $4}')

Docker daemon ayarlarında log boyutunu sınırlamak için /etc/docker/daemon.json dosyasına şunu ekleyebilirsin:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  }
}

Büyük Dosya Avcılığı

Sistematik olarak büyük dosyaları bulmak için:

# 100MB'dan büyük dosyaları bul
find / -type f -size +100M -exec du -sh {} ; 2>/dev/null | sort -rh

# 1GB'dan büyük dosyaları bul ve listele
find / -xdev -type f -size +1G 2>/dev/null | xargs du -sh | sort -rh

# Belirli bir dizinde büyük dosyaları bul
find /home -type f -size +50M -printf "%s %pn" 2>/dev/null | sort -rn | head -20

-xdev parametresi özellikle önemlidir: Mevcut filesystem sınırları dışına çıkmaz, yani NFS mount’larına veya diğer partisyonlara taşmaz. Bu hem güvenlik hem de performans açısından iyidir.

Core Dump Dosyaları

Çöken uygulamalar core dump dosyası bırakır ve bunlar çok yer kaplayabilir.

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

# Systemd-coredump kullanıyorsan
coredumpctl list
journalctl --vacuum-size=100M

# Core dump'ların nereye yazıldığını kontrol et
cat /proc/sys/kernel/core_pattern

# /var/lib/systemd/coredump temizle
rm -rf /var/lib/systemd/coredump/*

Önleme Stratejileri

Acil durumu atlattıktan sonra asıl iş başlıyor: Bir daha bu duruma düşmemek.

Disk Kullanımı İzleme

İzleme olmadan önleme olmaz. En basit yöntemle başlayalım:

# Basit bir cron job ile disk kullanımını izle
# /etc/cron.d/disk-monitor dosyası oluştur
*/15 * * * * root df -h | awk 'NR>1 {gsub(/%/,""); if($5>85) print $0}' | mail -s "Disk Uyarisi: $(hostname)" [email protected]

Daha gelişmiş bir script:

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

THRESHOLD=80
ALERT_EMAIL="[email protected]"
HOSTNAME=$(hostname)

df -H | grep -vE '^Filesystem|tmpfs|cdrom|udev' | awk '{print $5 " " $1 " " $6}' | while read output; do
    usage=$(echo $output | awk '{print $1}' | tr -d '%')
    filesystem=$(echo $output | awk '{print $2}')
    mountpoint=$(echo $output | awk '{print $3}')

    if [ "$usage" -ge "$THRESHOLD" ]; then
        echo "UYARI: $HOSTNAME sunucusunda $mountpoint ($filesystem) %$usage dolu!" | 
        mail -s "DISK UYARISI - $HOSTNAME" $ALERT_EMAIL
    fi
done

Bu script’i crontab’a ekle:

# Her saat başı çalıştır
0 * * * * /usr/local/bin/disk-check.sh

Logrotate Yapılandırması

Logrotate düzgün yapılandırılırsa log dosyaları hiçbir zaman kontrolden çıkmaz.

# /etc/logrotate.d/myapp dosyası oluştur
/var/log/myapp/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        systemctl reload myapp > /dev/null 2>&1 || true
    endscript
}

Logrotate ayarlarını test etmek için:

# Dry run - ne yapacağını göster
logrotate -d /etc/logrotate.conf

# Zorla çalıştır
logrotate -f /etc/logrotate.d/myapp

Systemd Journal Kalıcı Sınırlama

# /etc/systemd/journald.conf dosyasını düzenle
# SystemMaxUse: Toplam maksimum boyut
# SystemKeepFree: Diskte minimum boş alan
# MaxRetentionSec: Maksimum saklama süresi

sudo sed -i 's/#SystemMaxUse=/SystemMaxUse=2G/' /etc/systemd/journald.conf
sudo sed -i 's/#SystemKeepFree=/SystemKeepFree=1G/' /etc/systemd/journald.conf

sudo systemctl restart systemd-journald

Tmpwatch / Tmpreaper ile Geçici Dosya Temizliği

# Ubuntu/Debian
apt-get install tmpreaper

# /etc/tmpreaper.conf
TMPREAPER_TIME=7d
TMPREAPER_DIRS='/tmp /var/tmp'

# Alternatif olarak find ile cron job
# /etc/cron.daily/clean-tmp
find /tmp -type f -atime +7 -delete
find /var/tmp -type f -atime +30 -delete

Gerçek Dünya Senaryosu: E-ticaret Sitesi ve Geceyarısı Krizi

Bir müşteri projesinde yaşanan olayı anlatayım. Geceyarısı / partisyonu %100 uyarısı geldi. Sisteme bağlandığımda PHP-FPM servisinin çalışmadığını ve sitenin tamamen down olduğunu gördüm.

İlk kontrol:

df -h
# /dev/sda1  50G   50G  0 100% /

du -sh /* 2>/dev/null | sort -rh | head -10
# 23G /var
# 12G /home
# 8G /usr

du -sh /var/* 2>/dev/null | sort -rh | head -5
# 22G /var/www

du -sh /var/www/* 2>/dev/null | sort -rh
# 22G /var/www/eticaret

Sorun /var/www/eticaret dizinindeydi. Daha derine inerek baktım:

du -sh /var/www/eticaret/* 2>/dev/null | sort -rh | head -5
# 21G /var/www/eticaret/storage/logs

Laravel uygulaması production’da debug modunda çalışıyor ve her exception’ı detaylıca logluyor, üstelik bir bug döngüsel olarak tetikleniyordu. Çözüm:

# Hızlı alan aç
truncate -s 0 /var/www/eticaret/storage/logs/laravel.log

# PHP-FPM'i yeniden başlat
systemctl restart php8.1-fpm

# Site tekrar ayağa kalktı, sonra asıl sorunu çöz
# .env dosyasında APP_DEBUG=false yap
# Hatalı kodu düzelt
# Logrotate yapılandır

Bu olaydan sonra o sunucuya üç şey ekledik:

• Disk izleme script’i (%75’te uyarı, %85’te kritik)
• Laravel için özel logrotate yapılandırması (günlük, 7 gün saklama, sıkıştırma)
• .env üzerinden debug modunun production’da otomatik kapalı olduğunun doğrulanması

LVM Kullanıyorsan: Dinamik Büyütme

Eğer LVM (Logical Volume Manager) kullanıyorsan, partisyonu büyütmek çok daha kolaydır.

# Mevcut LVM durumunu gör
vgdisplay
lvdisplay

# Boş alan varsa logical volume'ü büyüt
lvextend -L +10G /dev/mapper/ubuntu--vg-ubuntu--lv

# Filesystem'ı da büyüt (ext4 için)
resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv

# XFS için
xfs_growfs /

Bu yaklaşım özellikle sanal makinelerde disk diskten ekleyip anında büyütme imkânı verir.

Önleyici Tedbirler Özeti

Yaşanan sorunlardan çıkardığım dersleri maddeler hâlinde özetleyeyim:

• Monitoring zorunlu: Disk kullanımını mutlaka izle, %80’de uyar %90’da kritik alert gönder
• Logrotate her servis için ayarla: Kurduğun her uygulama için logrotate yapılandırması yap
• Journal boyutunu sınırla: /etc/systemd/journald.conf içinde SystemMaxUse değerini belirle
• Docker log limiti koy: daemon.json içinde log boyutunu sınırla
• Ayrı partisyon stratejisi: /var, /home, /tmp için ayrı partisyon kullan. Birisi dolduğunda diğerleri etkilenmesin
• Düzenli temizlik cron job’ları: Geçici dosyalar, eski core dump’lar, eski backup’lar için rutin temizlik tanımla
• LVM kullan: Mümkünse LVM ile esnek partition yönetimi sağla
• Kapasite planlaması yap: Aylık büyüme trendine bak, 3 ay öncesinden disk büyütme planla

Sonuç

Disk doldu sorunu teknik açıdan basit ama operasyonel açıdan ciddi bir problemdir. Sabah 3’teki panik anından sonra yapılması gereken şey sadece alanı açmak değil, neden dolduğunu anlamak ve bir daha aynı sorunu yaşamamak için sistem kurmaktır.

df, du, lsof, find komutlarını refleks hâline getirmek gerekir. Diskin neden dolduğunu 5 dakika içinde tespit edebilmek, saatlik kesintiler yaşamak ile hızlı toparlanmak arasındaki farktır. Monitoring ve logrotate yapılandırması ise bu tür acil durumların büyük çoğunluğunu ortadan kaldırır.

Bir sysadmin’in görevi sadece sorunları çözmek değil, sorunların oluşmasını engelleyen sistemleri kurmaktır. Disk yönetimi de bunun somut bir örneğidir: Doğru yapılandırılmış bir sistem, bu tip krizleri yaşamadan yıllarca sorunsuz çalışır.