Disk dolu hatası: Güvenli silinecek dosyalar ve kurtarma adımları

Disk dolu (disk full / out of space) hatası geldiğinde web siteniz, e-posta servisi veya veritabanınız yazmaya devam edemez. Sonuç olarak “500 Internal Server Error”, e-posta kuyruklarında takılma ya da veritabanı (MySQL/MariaDB) kilitlenmesi gibi etkiler görülebilir. Bu yazıda, önce sorunun kaynağını net bulmayı; sonra güvenli sayılabilecek dosyaları silmeyi; en sonda da tekrar yaşanmaması için kalıcı önlem almayı öğreneceksiniz.

Aşağıdaki adımlar Linux tabanlı VDS/VPS/dedicated sunucular ve çoğu kontrol paneli (DirectAdmin, Plesk, cPanel) için uygundur. Paylaşımlı hostingte ise aynı mantıkla, yalnızca sağlayıcının sunduğu temizlik araçlarını kullanın.

Disk dolu hatasının kaynağını “tahmin ederek” değil ölçerek bulun

“Şu klasörü sil” demek doğru değildir; önce hangi bölümün dolduğunu anlamak gerekir. Çünkü disk doluluğu bazen /home, bazen /var, bazen de sadece logların olduğu partition’da ortaya çıkar.

Hızlı kontrol komutları

SSH ile bağlanıp aşağıdaki kontrolleri sırayla yapın.

Dosya sistemi doluluk oranları:
df -h
En büyük dizinler (örnek):
sudo du -xh /var | sort -h | tail -n 20
Hangi dizinlerde en çok dosya var (inode riski):
df -ih

Not: Disk “GB” olarak dolmadan da inode (dosya sayısı) sınırı dolabilir. Bu durumda df -ih kritik olur.

/var, /home, /tmp ayrımı

Genelde en sık problem üreten alanlar şunlardır: - /var: loglar (ör. /var/log), paket cache’i, geçici dosyalar - /home: web siteleri, kullanıcı klasörleri, WordPress yedekleri - /tmp: uygulama ve sistem geçici dosyaları - /var/lib: veritabanı dosyaları (en kritik alan)

Bu ayrım, “hangi dosya silinir, hangisi kesin silinmez” kararını doğrudan etkiler.

Güvenli silinebilecek dosyalar: Önce geçici ve türev içerikler

Disk dolu hatasında en güvenli temizlik genellikle “yeniden üretilebilen” dosyalardır. Silmeden önce hedefi netleştirin: Amaç veri kaybı yaratmadan alan açmaktır.

1) Paket yöneticisi cache’i (apt/yum/dnf)

Sunucu güncellemeleri sırasında indirilen paketler yeniden indirilerek tekrar kurulabilir. Bu nedenle cache genellikle güvenlidir.

Debian/Ubuntu:
sudo apt-get clean
sudo apt-get autoclean
RHEL/CentOS/Rocky:
sudo dnf clean all
veya sudo yum clean all

Ne zaman risk olur? - Disk doluluğu çok ani ve servisler çalışmıyorsa, temizlemeden önce temel servislerin çalıştığından emin olun.

2) Log rotasyonu sonrası kalmış büyük loglar

Log dosyaları normalde logrotate ile döner. Ancak rotasyon ayarlı değilse veya rotasyon başarısızsa /var/log şişer.

Mevcut log boyutları:
sudo du -sh /var/log/* 2>/dev/null | sort -h

Güvenli yaklaşım: - Önce rotasyonun çalıştığını teyit edin: sudo logrotate -f /etc/logrotate.conf (dosya yolu sunucunuza göre değişebilir) - Hâlâ devasa loglar varsa, yalnızca gereksiz eski dosyaları hedefleyin.

Örnek güvenli hedefler (duruma göre): - Sıkışmış .gz (sıkıştırılmış) arşiv loglar - Çok eski log .log.1, .log.2 gibi döndürülmüş dosyalar

Riskli yaklaşım: - Çalışan servisin “halen yazdığı” logu keyfi silmek. Bunun için servisi durdurmadan logları rastgele kaldırmayın.

3) Geçici dosyalar: /tmp ve uygulama temp klasörleri

Geçici dosyalar yeniden oluşur. Ancak çalışan süreçlerin kullandığı dosyalar varsa sorun çıkarabilir.

/tmp temizliği:
sudo rm -rf /tmp/*

Güvenli hale getirmek için pratik kural: - Temizlikten sonra servisleri yeniden başlatın (asıl sebep disk full ise bu zaten gerekli olabilir).

4) WordPress/uygulama cache’leri (cache sadece performans içindir)

Eğer sunucuda WordPress varsa ve disk doluluğu özellikle /home içinde yaşanıyorsa, cache eklentileri (ör. page cache, object cache) veya manuel “tmp” klasörleri büyümüş olabilir.

Güvenli hedefler: - WordPress cache klasörleri (ör. wp-content/cache/) - Güncellenmeyen temp klasörleri

Silme öncesi kontrol: - Cache boyutu nedir? - sudo du -sh /var/www/ORNEK/web/wordpress/wp-content/cache/* 2>/dev/null

Cache’i silmek veri kaybı üretmez; sadece bir süre daha yavaş açılma veya ilk isteklerde yeniden üretim etkisi olabilir.

5) Kullanılmayan yedek (backup) dosyaları

Yedekler “en faydalı” ama disk dolu olduğunda “en sık suçlu” dosyalardır. Güvenli yaklaşım şudur: Yedek stratejinizi korurken sadece artık gerekmeyenleri silmek.

Güvenli kontrol adımları: 1. Yedekler nerede tutuluyor? - /home kullanıcılarda veya /var/backups içinde olabilir 2. Yedekler gerçekten saklanmalı mı? - 30/60/90 günlük saklama kuralı yoksa fazlası silinir 3. Yedekler başka yere kopyalandı mı? - Örneğin S3/harici depolama/başka sunucuya taşındıysa yerel kopya kaldırılabilir

Kritik uyarı: Veritabanı dump’ları (örn. .sql) “tek kopya” ise silmeyin.

Kesin silmeyin: Disk dolu olsa bile veri kaybı çıkaran dosyalar

Aşağıdaki klasörler genellikle “çekirdek veri” içerir. Yanlış silme; geri dönülemez veri kaybı ve servislerin tamamen durmasına yol açabilir.

/var/lib/mysql veya /var/lib/mariadb (veritabanı datadir)
/etc altındaki servis konfigürasyonları
Web uygulamasının “gerçek içerik” klasörleri (ör. /var/www/... altında wp-content dışında rastgele)
Sistem imajları ve imza dosyaları (ör. /boot / lib içinde)
SSH anahtarları (ör. ~/.ssh içeriği) ve kontrol panel sistem dosyaları

Bu alanlarda “alan açmak” için ancak özel ve kontrollü prosedürler gerekir (veritabanı purge/retention, doğru arşivleme, snapshot yönetimi gibi).

Silme yerine tercih edilecek kurtarma stratejileri

Disk doluluğu bir kere aşıldığında servisler yazamaz. Bu durumda silme ile uğraşmadan önce şunları deneyin.

1) Disk doluluk eşiğini düşürmeden servis yazmasını durdurun

Eğer sistem sürekli log basıyorsa disk daha da hızla dolar. Şu hedeflenir: - Hızlı alan kazan: sürekli yazan akışı durdur

Örnek pratik: - Aşırı log üreten servisi bulmak için: - sudo journalctl --disk-usage - sudo journalctl -n 200 --no-pager - journald logları aşırı şişiyorsa (systemd sistemlerde) doğru yapılandırma yapılır. Doğru yaklaşım için sağlayıcı dokümantasyonu da kullanılmalıdır.

2) Veritabanı için retention (en güvenli veri temizliği)

Eğer disk, MySQL/MariaDB datadir yüzünden doluyorsa rastgele .ibd veya log dosyası silmeyin. Bunun yerine tablo bazında purge/retention uygulayın.

Uygulama log tabloları (örn. audit/log) için eski kayıtları silin
Geçici tablo/staging verilerini temizleyin

MySQL’de sık görülen acil durum: binlog ve relaylog birikmesi. Bu durumda sürüm ve replika durumuna göre doğru komutlar seçilir.

3) E-posta kuyrukları büyüyünce

Mail sunucusu kullanıyorsanız disk /var/spool/mail ve benzeri dizinlerden dolabilir. SMTP queue’lar birikir. - Kuyruk içinde “takılan” mesajları düzgün şekilde teslim etmeyi veya temizlemeyi gerekir. - Bu işlemler servis etkiler. En doğrusu önce queue boyutlarını ölçmek ve sağlayıcının e-posta rehberini takip etmektir.

Sık görülen senaryolar: Hangi dosya çoğunlukla dolu olur?

Aşağıdaki tabloda “doluluk nerede” sorusuna göre temizlik planı özetlenmiştir.

Dolan alan	En olası dosyalar	Güvenli temizlik yaklaşımı	Kesin riskli yaklaşım
/var/log	dönen/eski loglar, journald şişmesi	logrotate kontrolü, eski `.gz` loglar	çalışan logu rastgele silmek
/tmp	geçici dosyalar, temp chunk’ları	`/tmp` temizliği	çalışan süreçlerin temp dosyalarını yanlış zamanda silmek
/home (web)	cache, eklenti temp, eski yedekler	`wp-content/cache` ve gereksiz backup arşivleri	tek kopya içerik/DB dump silmek
/var/backups	eski snapshot/dump’lar	saklama süresi dolanları silme	yedek stratejisinden emin olmadan toplu silme
/var/lib/mysql	datadir, binlog/relaylog	veritabanı retention ve purge (kontrollü)	datadir’e el sürmek

Temizlikten sonra doğrulama: “Alan açıldı mı ve servisler yazabiliyor mu?”

Dosyaları sildikten sonra sadece df -h ile yetinmeyin. En azından temel uygulama yazma kontrolü gerekir.

Kontrol listesi

Disk doluluk oranı düştü mü?
df -h
Uygulama logları yeniden yazabiliyor mu?
Örnek: tail -n 50 /var/log/<servis>.log
Web uygulaması/WordPress açılıyor mu?
Veritabanı yazma yapıyor mu?
Basit bir insert/test veya uygulama üzerinden kontrol
Sistem yeniden başlatma gerekiyorsa yapılmış mı?

Tekrar etmesini engelle: Rutin izleme ve saklama politikası

Disk doluluğu tekrarlıyorsa “bir kez silmek” kalıcı çözüm değildir. Aşağıdaki önlemleri uygulayın.

1) İzleme: disk doluluğunu e-posta/uyarı ile takip edin

df -h çıktısında eşiği belirleyin (örn. %80 uyarı, %90 acil aksiyon)
Kontrol panel kullanıyorsanız panellerde “disk usage” uyarıları bulunabilir

2) Log rotasyonunu düzgün ayarlayın

/etc/logrotate.conf ve ilgili dosyaları kontrol edin
Log dosyalarının “boyut” temelli rotasyon yaptığından emin olun

3) Yedek saklama süresi kuralı

Örnek (pratik ve uygulanabilir): - 7 günlük günlük yedek - 4 haftalık haftalık yedek - 12 aylık aylık yedek

Bu kural yoksa, yedekler bir noktada kaçınılmaz olarak disk doldurur.

4) Cache ve geçici dosyalar için otomasyon

Cache temizliği için cron job kullanılabilir (uygulama uyumluysa)
/tmp temizliği için periyodik temizlik sağlayın

Sonuç: Disk dolu hatasında doğru sırayı izleyin

Disk dolu hatasında en hızlı ve güvenli yaklaşım şu sıradır: önce df -h ve du ile sorunun kaynağını ölçün, sonra geçici dosyalar, cache, eskimiş loglar ve saklama süresi dolan yedekleri hedefleyin. Veritabanı datadir’i veya gerçek içerik klasörleri üzerinde rastgele silme yapmayın. Son olarak disk doluluğunu tekrarlamaması için izleme eşiği ve log/yedek saklama kuralları kurun. Bu adımları uygularsanız hem hızlı kurtarırsınız hem de veri kaybı riskini minimuma indirirsiniz.