Bir sunucu aniden %100 disk doluluğuna ulaştığında yaptığın ilk iş derin bir nefes almak olmalı — panik fayda etmez. Yıllardır altyapı yönetirken birkaç kez sabah mesaisi yerine bir disk temizliğiyle başladım; o günlerden öğrendiğim pratik yöntemleri burada, adım adım ve uygulanabilir biçimde paylaşıyorum. Amacım: hem anlık müdahale hem de tekrarını engelleyecek otomasyon ve izleme önerileri vermek.
Disk Doluluğunu Hızlı Tespit
İlk 2 komutla durumu hemen netleştiriyorum:
df -h
# ve inode durumu için
df -i
Bu iki çıktıyla hangi mount point’in dolduğunu ve inode sıkıntısı olup olmadığını görürsün. Ardından büyüğe doğru gitmek için:
du -hsx /* 2>/dev/null | sort -rh | head -20
# veya belli bir dizin için
du -sh /var/* | sort -rh | head -30
Eğer uygulama logları veya beklenmedik büyük yedekler sorunsa bu komutlar hemen gösterir.
Inode (i-node) Sorunları: Neden ve Hızlı Çözüm
Bazen disk alanı boş görünürken inode’lar tükenir; küçük, sayısız dosya yaratan loglama, cache veya hatalı bir uygulama en sık suçludur. Inode tükendiğinde yeni dosya yaratılamaz — hizmetler hata verir.
Inode yoğunluğunu görmek için:
df -i
# inode bazında hangi dizin çok dosya barındırıyor kontrolü
for d in /var /tmp /home /srv; do echo "--> $d"; find $d -xdev -printf '.' | wc -c; echo; done
Çözüm adımı: büyük küçük dosyaları tespit edip gereksiz olanları silmek veya arşivlemek. Örnek: 30 günden eski küçük log dosyalarını silmek için:
find /var/log -type f -mtime +30 -name '*.log' -print -delete
Kısa Vadeli Müdahale: Hızlı Kurtarma Checklist
- 1) Hangi mount dolu? df -h ile tespit et.
- 2) En çok yer kaplayan 10 klasörü bulun: du -sh /path/* | sort -rh | head
- 3) Lsof ile silinmiş ama açık dosyaları bul: lsof +L1 — çokça yer kaplayan süreçleri restart et (ör. logrotate tetikle).
- 4) journalctl ile büyük journal dosyalarını küçült:
journalctl --vacuum-size=200Mveya--vacuum-time=7d. - 5) Acil olarak gereksiz büyük dosyaları /tmp veya uygulama temp dizinlerinden taşı/temizle.
Kalıcı Önlemler: Rotasyon, Quota, LVM ve İyi Alışkanlıklar
Geçici silmeler çözüm değil; tekrarını önlemek için şu düzenlemeleri öneriyorum:
- Logrotate kurallarıyla log dosyalarını günlük/haftalık döndür ve sıkı sıkıya boyut limiti koy. Örnek snippet:
/var/log/myapp/*.log {
daily
rotate 14
compress
missingok
notifempty
maxsize 50M
create 0640 myapp myapp
sharedscripts
postrotate
systemctl reload myapp.service >/dev/null 2>&1 || true
endscript
}
- Dosya sayısı sorunu için kullanıcı veya proje bazlı quota uygula (Linux:
edquota, xfs/quota araçları). - LVM thin pool veya ayrı volume stratejisi kullan. /var, /home, /srv gibi kritik dizinleri ayrı logical volume olarak ayırmak rollback ve genişletmeyi kolaylaştırır.
- journalctl politika ayarla: /etc/systemd/journald.conf içinde
SystemMaxUse=200Mgibi sınırlar koy. - Yedek politikalarını kontrol et: uygulama kendi içinde sık yedek oluşturuyor mu? Otomatik snapshot’lar diski şişirebilir—rotate ve purge mekanizması şart.
İzleme ve Alarm Taktikleri
Disk uyarıları çok gürültülü olur ama doğru eşiklerle işe yarar. Ben şu yaklaşımı kullanıyorum:
- Prometheus ile node exporter üzerinden kullanılabilir oranı izle: örnek alert ifadesi (PromQL):
(node_filesystem_avail_bytes / node_filesystem_size_bytes) < 0.10 and node_filesystem_readonly == 0
- Uyarıyı 5 dakika penceresi ile değerlendir: anlık dalgalanmalar tetikleme yapmasın.
- Disk alanı uyarısı geldiğinde otomatik runbook tetikle: Slack/Teams’e link ve en sık yapılacak 5 adımı içeren kısa bir playbook gönder.
Otomasyon: Basit Temizleme Systemd Timer ve Script
Ben cron yerine systemd timer kullanmayı tercih ediyorum çünkü daha yönetilebilir. Örnek service + timer kombinasyonu:
# /etc/systemd/system/cleanup-temp.service
[Unit]
Description=Cleanup temp files
[Service]
Type=oneshot
ExecStart=/usr/local/bin/cleanup-temp.sh
# /etc/systemd/system/cleanup-temp.timer
[Unit]
Description=Run cleanup-temp daily
[Timer]
OnCalendar=daily
Persistent=true
[Install]
WantedBy=timers.target
cleanup-temp.sh örneği (dikkatle test etmeden prodta çalıştırma):
#!/bin/bash
set -euo pipefail
# eski geçici dosyaları sil
find /tmp -type f -mtime +7 -print -delete
# küçük sık dosya üreten dizinlerde inode temizliği
find /var/cache/myapp -type f -mtime +30 -print -delete
# bildirim - opsiyonel: slack webhook
Benim Deneyimimden Kısa Bir Not
Bir keresinde prod web sunucusunun /var dolduğu için tüm cron işler başarısız olmuştu. Sorunun kaynağı beklenmedik bir yedek script’inin her çalıştığında timestamp'li dizin oluşturarak arşivlemesiymiş. O günden sonra bu yedeği ayrı LV’ye taşıdım, rotasyon koydum ve 3 satırlık script ile günlük kontrol otomatik oldu — sabah 07'de çalan alarm sayısı sıfıra indi.
Sonuç — Kısa ve Uygulanabilir
Özetle: anlık müdahaleyi bilen, inode ve disk farklılıklarını ayırt eden; log rotasyonu, quota ve ayrı LV kullanımıyla kalıcı önlem alan; izleme ve otomatik playbook’ları olan altyapılar bu sınıfta hayatta kalır. Bir olay yaşadığında panikten kaçın; ölç, bul, geçici çöz, kalıcı düzelt, otomasyonu yaz — bu beş adımı uyguladıkça aynı alarmı tekrar görmezsin.