Disk doldu: neyin yediğini bulma ve güvenle temizleme

Disk dolduğunda belirtiler dağınık görünür: site 500 döner, veritabanı yazamaz, oyun sunucusu kayıt almaz, hatta SSH oturumu hiç açılmaz. Sebebi tek bir şeydir ve teşhisi iki komutla biter. Zor olan kısım temizliktir: yanlış dosyayı silmek, disk dolu kalmasından daha pahalıya gelir.

1. Yer mi bitti, inode mu?

df -h
df -i

Birinci komut kapasiteyi, ikincisi inode sayısını gösterir. İkisi ayrı biçimde tükenir ve ikisi de aynı hatayı üretir.

• df -h çıktısında kullanım %100'e dayanmışsa sorun kapasitedir.
• df -i çıktısında inode oranı doluysa boş yer görünür ama yeni dosya oluşturulamaz. Bunu tüketen şey genelde milyonlarca küçük dosyadır: oturum dosyaları, önbellek girdileri, kuyruk dosyaları.

Doğru bölüme baktığınızdan emin olun. /var veya /home ayrı bir bölümde olabilir; kök bölüm rahatken oradaki bir bölüm dolmuş olabilir.

2. Neyin yediğini yukarıdan aşağı bulun

du -xh --max-depth=1 / | sort -h

-x bayrağı dosya sistemi sınırını aşmamayı sağlar; /proc, /sys ve bağlı diskler sayıma girmez, yoksa sonuç anlamsız çıkar. Çıktının en altındaki en büyük dizine inip aynı komutu orada tekrarlayın. Üç dört adımda kaynak bulunur.

Tek tek büyük dosyaları aramak için:

find /var -xdev -type f -size +500M -exec ls -lh {} +

3. Sildiniz ama yer açılmadıysa

Klasik tuzak: devasa bir log dosyasını sildiniz, df hâlâ dolu gösteriyor. Sebebi şudur: bir süreç o dosyayı hâlâ açık tutuyorsa alan serbest bırakılmaz.

lsof +L1

Bu komut, silinmiş ama hâlâ açık olan dosyaları listeler. Çözüm, o dosyayı açık tutan servisi yeniden başlatmaktır. Aynı tuzağa düşmemek için aktif bir log dosyasını silmek yerine içeriğini boşaltın — truncate -s 0 dosya dosya tanıtıcısını geçerli bıraktığı için alan anında serbest kalır.

4. Önce neyin silinmesi güvenli

Temizliğe bu listeden başlayın. Buradakilerin hepsi ya yeniden üretilebilir ya da zaten geçici veridir.

• Paket yöneticisi önbelleği. Debian ve Ubuntu ailesinde apt clean indirilmiş kurulum paketlerini siler; hepsi gerektiğinde yeniden indirilir.
• Eski sistem günlükleri. journalctl --vacuum-time=7d veya journalctl --vacuum-size=200M yalnızca eski kayıtları düşürür, çalışan servisleri etkilemez.
• Döndürülmüş eski loglar. .gz ve .1 uzantılı arşiv logları güvenle silinebilir; aktif log dosyasına 3. adımdaki yöntemle dokunun.
• Kullanılmayan Docker katmanları. Önce docker system df ile ne kadar yer kapladığını görün, sonra docker image prune ile yalnızca etiketi kalmamış imajları silin.
• Kendi indirdiğiniz kurulum arşivleri ve eski sürüm dizinleri. Genelde en büyük ve en kolay kazançtır.

5. Neye dokunulmaz

Bu liste kısa ama pahalıdır.

• Veritabanı dizini. /var/lib/mysql altındaki hiçbir dosya elle silinmez — binary log dosyaları dahil. Binlog gerçekten yer yiyorsa çözümü PURGE BINARY LOGS ifadesidir, dosya silmek değil. Ayarların kalıcı hâli: MySQL performans ayarları
• Yedekleriniz. Yer açmak için yedek silmek, bir sonraki sorunu geri dönülemez hale getirir. Yedek diskte yer kaplıyorsa çözüm onu başka bir yere taşımaktır: sunucu yedekleme stratejisi
• Ne olduğunu bilmediğiniz hiçbir dizin. /var/lib altındaki dizinler çalışan servislerin verisidir.
• Geniş silme komutları. İnternette bulduğunuz özyinelemeli bir silme komutunu kopyalayıp yapıştırmayın; yanlış bir yol parçası tek satırda sistemi kullanılamaz hale getirir. Silmeden önce aynı yolu ls -lh ile görüntüleyin.

6. Sık rastlanan yiyiciler

Aynı birkaç kaynak dönüp duruyor: sınırlandırılmamış MySQL binary logları, SystemMaxUse ayarlanmamış systemd günlüğü, biriken oyun dünyası yedekleri ve çökme dökümleri, Docker imaj ve derleme önbelleği, uygulamanın oturum ve önbellek dizinleri. Sonuncusu genelde kapasiteyi değil inode'u bitirir.

7. Kalıcı çözüm

Tek seferlik temizlik aynı sorunu birkaç ay sonra geri getirir. Kalıcı hâli üç şeydir: logrotate kurallarını yazmak, systemd günlüğüne üst sınır koymak ve yedekleri sunucu dışında tutmak.

Bunlar yapıldığı hâlde disk düzenli doluyorsa sorun temizlikte değil boyutlandırmadadır. Büyüme kalıcıdır: veritabanı, loglar ve yedekler geri küçülmez. Disk küçültme veri kaybı riski taşıdığı için çoğu sağlayıcıda desteklenmez, yalnızca büyütme yapılır — bu yüzden bir sonraki adımı rahat bir payla seçmek doğru olur. Yeni disk boyutunun aylık tutara etkisini sunucu yapılandırıcıda görebilir, disk gecikmesinin kapasiteden ayrı bir konu olduğunu NVMe SSD nedir yazısında okuyabilirsiniz.

Ne zaman destek talebi açmalı

Üç durumda destek talebi açmak kendi başınıza uğraşmaktan hızlıdır:

• Disk o kadar doludur ki SSH oturumu hiç açılmıyor ve konsoldan da işlem yapılamıyor.
• df doluyken du toplamı belirgin biçimde daha az ve lsof +L1 de boş — bu, dosya sistemi tarafında bakılması gereken bir durumdur.
• Temizlik yapıldı ama disk gerçekten yetmiyor ve büyütülmesi gerekiyor.

Talebe df -h ile df -i çıktılarını ve hizmet numaranızı ekleyin. Disk büyütme işlemi sanal sunucu paketlerinde yeniden kurulum gerektirmeden yapılır; dolu bir diskin yol açtığı bağlantı sorunları da bu adımdan sonra kendiliğinden kapanır: sunucuma bağlanamıyorum