Disk Doldu Alarmı Geldiğinde İlk 10 Dakikada Ne Yapmalı?

Disk doldu uyarısı, sunucu yönetiminde etkisi en hızlı yayılan olaylardan biridir. Disk dolduğu anda veritabanı yazamaz hâle gelir, oturum dosyaları bozulur, yükleme işlemleri yarım kalır ve — en kötüsü — sistem kendi log'unu tutamadığı için ne olduğunu anlamanız da zorlaşır. Bu yazıda, alarm geldikten sonraki ilk on dakikada sırayla ne yapılacağını ele alıyoruz.

Adım 1: Hangi bölümün dolduğunu belirleyin

İlk komut her zaman aynıdır:

df -h

Buradaki kritik ayrım, dolan bölümün hangisi olduğudur. Kök bölümü (/) dolduysa sistem servisleri etkilenir ve acil müdahale gerekir. Yalnızca veri bölümü dolduysa etki daha sınırlıdır. /var ayrı bir bölümdeyse ve o dolduysa, sorun büyük olasılıkla log'lardır.

Adım 2: Alan boş görünüyorsa inode'lara bakın

Sık karşılaşılan ve kafa karıştıran bir durum: df -h boş alan gösteriyor ama sistem "disk dolu" hatası veriyor. Bu, inode tükenmesidir — yani dosya sayısı sınırına ulaşılmıştır. Genellikle çok sayıda küçük dosya üreten bir süreçten (önbellek dosyaları, oturum dosyaları, kuyruk dosyaları) kaynaklanır.

df -i

Kullanım oranı %100'e yakınsa teşhis konmuştur. Bu durumda yapılacak şey büyük dosya aramak değil, çok sayıda küçük dosya üreten dizini bulup temizlemektir.

Adım 3: En büyük dizinleri bulun

Tepeden aşağı inerek ilerlemek, tüm diski taramaktan çok daha hızlıdır:

du -h --max-depth=1 / 2>/dev/null | sort -hr | head -10

Çıkan en büyük dizine geçip aynı komutu tekrarlayın. Birkaç adımda kaynağa ulaşırsınız. En sık çıkan suçlular: /var/log (rotasyonu yapılmayan log'lar), /var/lib/mysql (ikili günlükler), /tmp, uygulama yükleme dizinleri ve Docker kullanılıyorsa /var/lib/docker.

Adım 4: Silinmiş ama serbest bırakılmamış dosyaları kontrol edin

Bu, en çok zaman kaybettiren tuzaktır. Büyük bir log dosyasını sildiniz, ama df hâlâ diskin dolu olduğunu gösteriyor. Sebep şudur: bir süreç o dosyayı hâlâ açık tutuyorsa, dosya silinse bile alan serbest bırakılmaz.

lsof +L1 | head -20

Bu komut, silinmiş ama hâlâ açık olan dosyaları listeler. Çözüm, ilgili süreci yeniden başlatmak veya log dosyasını silmek yerine içeriğini boşaltmaktır:

# Silmek yerine boşaltın — süreç dosyayı açık tutmaya devam edebilir
: > /var/log/uygulama/buyuk.log

Adım 5: Güvenli alan açma

Acil durumda hangi dosyaların silinmesi güvenlidir?

• Güvenli: Rotasyona uğramış eski log arşivleri (.gz uzantılı), paket yöneticisi önbelleği, uygulama derleme önbellekleri, eski Docker imajları ve kullanılmayan hacimler.
• Dikkatli olun: Veritabanının ikili günlükleri (binlog). Bunlar çoğaltma için gerekebilir; doğrudan dosya silmek yerine veritabanının kendi temizleme komutunu kullanın.
• Asla silmeyin: Veritabanı veri dosyaları, aktif yükleme dizinleri ve ne olduğunu bilmediğiniz hiçbir şey. Acil durumda tanımadığınız bir dosyayı silmek, disk dolmasından çok daha büyük bir olaya dönüşebilir.

Alan açtıktan sonra etkilenen servisleri kontrol edin: veritabanı yazamadığı için salt okunur moda geçmiş olabilir, uygulama sunucusu hata durumunda kalmış olabilir.

Kalıcı çözüm: bir daha olmaması için

Disk dolması neredeyse her zaman önlenebilir bir olaydır. Alarm sonrası yapılacak asıl iş, aynı olayın tekrarlanmasını engellemektir:

1. Log rotasyonunu doğrulayın. logrotate yapılandırmasının uygulama log'larını da kapsadığından ve gerçekten çalıştığından emin olun. Uygulamanın kendi yazdığı log dosyaları çoğu zaman rotasyon kapsamı dışında kalır.
2. Saklama süresi belirleyin. Yedekler, geçici dosyalar ve arşivler için otomatik temizleme kuralı yazın. "Bir gün lazım olur" diye biriken dosyalar, disk dolmasının en yaygın sebebidir.
3. Erken uyarı kurun. %90 doluluk uyarısı çok geçtir; %75'te uyaran bir eşik, müdahale için zaman bırakır. Ayrıca doluluk oranının artış hızını izlemek, "üç gün içinde dolacak" gibi öngörülü uyarılar üretir.
4. inode kullanımını da izleyin. Çoğu izleme kurulumu yalnızca alan izler; inode tükenmesi bu yüzden hep sürpriz olur.

Yeni bir sunucuyu ilk kurarken bu ayarların baştan yapılması en ucuz yoldur; kurulum kontrol listesi için Linux sunucu kurulumu yazımıza bakabilirsiniz. Log hacmini kaynağında azaltmak için log yazma rehberimiz, bulut ortamında saklama maliyetleri için bulut faturası yazımız ilgili okumalardır. Sistem yönetimi komutlarının ayrıntılı örnekleri için DigitalOcean topluluk rehberleri pratik bir kaynaktır.

Sonuç

Disk doldu alarmında en pahalı hata, sorunu teşhis etmeden rastgele dosya silmeye başlamaktır. Doğru sıra kısadır: hangi bölüm dolu, alan mı inode mu tükendi, en büyük dizin hangisi, silinmiş ama açık tutulan dosya var mı. Bu dört soru genellikle beş dakika içinde kaynağı gösterir. Asıl iş ise olaydan sonra başlar: rotasyon, saklama politikası ve erken uyarı kurulmadığı sürece aynı alarm birkaç ay içinde geri gelir. Sunucularınızda şu an df -i çıktısına bakın — çoğu ekip bu satırı ilk kez bir olay sırasında görür.