Disk Dolu Hatası: Güvenli Silinecek Dosyalar ve Kontrol Planı

Disk dolu hatası ("Disk quota exceeded" veya dosya sistemi doldu uyarısı) genellikle e-posta teslimini, WordPress güncellemelerini, site yüklemelerini ve hatta SSH erişimini etkiler. Panik yerine dosyaları doğru kategorilere ayırmak gerekir: gerçekten güvenli temizlenebilenler ile kritik veri (veritabanı, web kökü, yedekler, yapılandırma) arasındaki sınır net olmalıdır. Bu rehberde, hangi dosyaların silinmesinin güvenli olduğunu tek tek anlattım; ardından disk alanını hızlı ölçüp kalıcı çözüm planını verdim.

1) Önce durumu net teşhis edin: Hangi disk, hangi dizin doluyor?

Disk dolu hatasında en sık yapılan hata, yanlış partition/dizini temizlemeye çalışmaktır. Aşağıdaki adımlar, “gerçekten hangi klasör şişiyor?” sorusunu 10 dakikada yanıtlar.

Hızlı kontrol komutları (Linux/VPS)

Erişiminiz varsa SSH ile şu kontrolleri yapın:

Disk kullanımını görmek:
df -h
Hangi dizinlerin büyüdüğünü görmek:
du -sh /home/* 2>/dev/null
du -sh /var/* 2>/dev/null
En büyük dosyaları bulmak:
sudo find / -xdev -type f -size +500M -printf "%s %p\\n" 2>/dev/null | sort -nr | head -20

Not: Hosting kontrol paneli (Plesk/cPanel/DirectAdmin) kullanıyorsanız, “Disk Usage / Disk Kullanımı” sayfası aynı bilgiyi çoğu zaman daha hızlı verir.

Önemli ayrım: “/” mi dolu, “/home” mı dolu?

/ (root) doluysa: sistem logları, geçici dosyalar ve güncelleme artıkları genelde sorumludur.
/home (kullanıcı alanı) doluysa: web root, kullanıcı cache’i, e-posta spool’ları ve sık yapılan yedekler şişer.
/var doluysa: loglar (log rotation kapalıysa), paket önbellekleri ve spool dizinleri öne çıkar.

Bu ayrımı yaptıktan sonra temizlik planı çok daha güvenli olur.

2) Güvenli silinebilen dosya türleri (net liste)

Aşağıdaki dosyalar doğru koşullarda genellikle güvenle temizlenebilir. “Güvenli” derken şu şartları kastediyorum: Dosyalar sistemin çalışması için sürekli gerekli değil, yeniden oluşturulabilir ya da başka bir yerde saklanıyor.

### A) Geçici dosyalar (tmp) ve cache

Silinmesi genellikle güvenli: - Uygulama ve sistem geçici dosyaları (ör. /tmp, /var/tmp) - Tarayıcı veya uygulama cache’i (site tarafı cache’i ile sunucu tarafı cache’i aynı şey değildir) - Paket yöneticisi önbelleği (ör. Debian/Ubuntu’da apt cache: /var/cache/apt/archives)

Örnek kontrol: - du -sh /tmp /var/tmp 2>/dev/null

Net risk: - Silme sırasında çalışan servislerin geçici klasörleri yeniden oluşturulur; çoğu durumda sorun olmaz.

### B) Loglar (log rotation doğru değilse)

Loglar ikiye ayrılır: - Güncel loglar: uygulamalar yazmayı sürdürür. Tam silmek yerine rotation ile yönetmek daha sağlıklıdır. - Arşiv/eskiler (rotated loglar): gzip’li eski loglar genellikle temizlenebilir.

Silinmesi genellikle güvenli: - *.gz uzantılı log arşivleri - Çok eski log dosyaları - Rotation sonrası oluşan log geçmişi

Silmeden önce net kontrol: - Log dosyaları hangi uygulamaya ait? (nginx, apache, php-fpm, mysql, postfix, dovecot) - Dosyalar aktif mi? lsof (kullanılıyor mu) kontrol edilebilir.

Örnek: - sudo lsof | grep /var/log | head

Eğer “logları tamamen silince servis duruyor” gibi bir durumla karşılaşırsanız, aktif loga dokunmamışsınız demektir. Tam silme yerine rotation politikası uygulamak kalıcı çözümdür.

### C) WordPress geçici dosyaları ve cache (site tarafı)

WordPress kullanıyorsanız disk doluluğu bazen eklenti cache’inden gelir: - Günlük/pahalı sorguların ürettiği geçici dosyalar - wp-content/cache/ (varsa) - Optimizasyon eklentilerinin oluşturduğu cache dizinleri - Transient (veritabanında) değilse dosya bazlı olanlar

Silinmesi genellikle güvenli: - wp-content/cache/ içindeki dosyalar (eklentiye göre)

Net risk: - İlk isteklerde site performansı kısa süre düşebilir; cache yeniden oluşur.

### D) Yedek (backup) dosyaları: Sadece “saklama politikası” varsa

Backup dosyaları disk tüketiminde en büyük kalem olabilir. Ancak “silmek güvenli” kararı en çok yedek türüne bağlıdır.

Silinmesi güvenli olan durum: - Backup’lar başka bir depoda (harici storage, başka sunucu, cloud) saklanıyorsa - Ya da kontrol panelinde zaten “yedek saklama” politikası kuruluyorsa - Dosyalar gerçekten eskiyse (ör. 30+ gün)

Silinmesi riskli olan durum: - Son yedek yoksa veya “en son restore edebileceğiniz” dosya tek kopyaysa - Kontrol paneli tarafından tutulan kritik yedekler otomatik silinmiyorsa

### E) Mail spool ve eski e-posta kuyruğu

Eğer sunucuda Postfix/Dovecot gibi servisler kullanılıyorsa, e-posta kuyrukları şişebilir.

Silinmesi güvenli olan durum: - Kuyruklar eski/işlenmemiş ama tekrar denemeye gerek yoksa - Panel üzerinden “mail queue temizleme” yapılabiliyorsa

Net risk: - Aktif kuyruk temizliği, teslim edilmeyi bekleyen mesajların kaybına yol açabilir.

Bu nedenle mail spool temizliği “hemen şimdi” kurtarma için yapılacak son çaredir; mümkünse önce kuyruk durumunu kontrol edin.

3) Silmemesi gereken dosyalar (kritik liste)

Disk dolu hatasında kullanıcılar çoğu zaman en kritik klasörleri yanlışlıkla temizler. Aşağıdakileri “otomatik silme” kapsamına almayın.

Veritabanı dosyaları (MySQL/MariaDB data dizini)
Bu dizinler genellikle /var/lib/mysql veya benzeri konumdadır.
Web sitesi içeriği (web root)
Örn. /var/www/, /home/<user>/public_html/ benzeri dizinler.
Kontrol panel yapılandırmaları ve scriptler
Plesk/cPanel/DirecAdmin ait konfigürasyon dosyaları.
SSH anahtarları ve kullanıcı home içeriği
/home/<user>/.ssh/ gibi dizinler.
Çalışan servislerin logu hariç aktif dosyalar
Aktif loga dokunmak yerine rotation kullanın.
Doğrulanmış son yedekler
Tek kopya yedek varsa veya “restore edilebilir” son backup durumu yoksa silmeyin.

Net kontrol kuralı: Eğer bir dosya “sahibi belli, yeniden oluşturulamaz, veri içeriyor” gibi görünüyorsa silmeden önce yedekleyin ve doğrulayın.

4) Disk doluluğunu “güvenli” şekilde azaltma: Pratik akış

Aşağıdaki akış, hem hızlı hem de hatasız ilerlemenizi sağlar.

4.1) Önce alan kazandırın (risk azaltan sıra)

cache/tmp temizliği: /tmp, cache dizinleri
eski log arşivleri: gzip’li loglar
eski backup dosyaları: yalnızca dış depoda kopya varsa
mail queue: yalnızca gerçekten kuyruk büyüdüyse ve alternatif yoksa

4.2) Temizlikten önce anlık “liste” alın

Komut/manuel silmeden önce şunları kaydedin (event sonrası neyi sildiğinizi bilirsiniz): - df -h - Büyük dizinlerin listesi: /home, /var, web root - Örnek: du -sh /home/* | sort -hr | head

4.3) Silme sonrası tekrar ölçün

df -h
Şişen dizin tekrar büyüyor mu? (ör. log yazımı devam ediyorsa tek seferlik temizlik yetmez)

5) Kalıcı çözüm: Log rotation, yedek politikası ve kota

Temizlik, sorunu geçici çözer; kalıcı çözüm setini kurmadan disk yine dolar. Bu bölümde “ne ayarlanmalı” sorusunu netleştiriyorum.

### A) Log rotation (log dosyaları sınırsız büyümesin)

Log rotation yoksa veya yanlışsa disk hemen dolar. Çözüm: - Logrotate ayarlarının etkin olduğundan emin olun. - Geri saklanan log sayısını belirleyin (ör. 7-14 gün).

Eğer altyapınız yönetilen hizmetse (managed), panelin “log rotation” veya “maintenance” ayarlarını kontrol edin.

### B) Yedek saklama süresi (retention)

Backup’lar için net bir retention belirleyin: - Günlük yedek: 7 gün - Haftalık yedek: 4 hafta - Aylık yedek: 6 ay (ihtiyaca göre)

En kritik kural: Disk üzerindeki yedekler “son yedek” olmamalı; bir dış depoya (cloud storage veya başka sunucu) kopya alınmalı.

### C) Disk quota (kota) ve yanlış kullanımın önlenmesi

Paylaşımlı veya kullanıcı bazlı yapıdaysa disk kotası şişmeyi engeller. - Kullanıcılar kendi log/cache’ini kontrol edemezse kota şarttır. - Kota varsa, disk doluluğu “tüm sunucu” yerine “kullanıcı” kaynaklı olur.

### D) Gereksiz paket önbelleği ve güncelleme artıkları

Sık görülen bir başka problem: paket önbelleği birikmesi. - Debian/Ubuntu’da apt cache temizliği yapılabilir.

Bu noktada kullandığınız dağıtımın paket yöneticisine göre hareket edin; yanlış klasöre müdahale etmeyin.

6) Kontrol panelinde (Plesk/cPanel/DirectAdmin) nereden müdahale edilir?

Komut satırı yerine panel kullanıyorsanız müdahale noktaları genellikle aynıdır:

Disk Kullanımı / Loglar / Cache yönetimi sayfaları
Mail Queue / E-posta Kuyruğu yönetimi
Yedekleme ekranında retention veya son backup konumu

Panelde silme seçenekleri “güvenli” olabilir; çünkü panel hangi dosyaların yeniden üretilebilir olduğunu bilir. Yine de şu kontrolü yapın: - Silmeden önce “dosya türü”nü doğrulayın (cache mi, yedek mi, aktif içerik mi?).

Sonuç: Şişen klasörü bulun, güvenli türleri temizleyin, rotation/retention kurun

Disk dolu hatasında hedefiniz önce siteyi çalışır hale getirmek, sonra tekrar etmeyi engellemektir. İlk adım olarak df -h ile dolan bölümü bulun; sonra en büyük dizinleri du ile tespit edin. Güvenli temizlikte öncelik tmp/cache ve eski log arşivleridir; backup yalnızca dış depoda kopya varsa ve retention planınız varsa silinir. Sonrasında mutlaka log rotation ve yedek saklama süresi (retention) yapılandırın; aksi halde aynı sorun birkaç gün içinde tekrar eder. Eğer isterseniz, kullandığınız kontrol panelini (Plesk/cPanel/DirectAdmin) ve dolan dizini (/home mi /var mı?) yazın; ben de size “hangi klasörden ne kadar temizleme” sırasını daha net bir kontrol listesiyle uyarlayayım.