'docker system prune -a' çalıştırmak güvenli mi?

Durdurulmuş container'ları, kullanılmayan ağları, sahipsiz build önbelleğini ve çalışan hiçbir container'ın kullanmadığı her image'ı siler. --volumes eklemedikçe verileriniz kalır. --volumes ile kullanılmayan volume'lar da silinir — ve durdurulmuş bir veritabanı container'ının volume'u kullanılmıyor sayılır. Emin değilseniz bu bayrağı kullanmayın.

Büyük bir log dosyasını sildim ama df hâlâ diski dolu gösteriyor. Neden?

Çalışan bir süreç dosyayı hâlâ açık tutuyor, bu yüzden çekirdek alanı bırakmıyor. 'lsof +L1' ile bulun ve o servisi yeniden başlatın. Bir dahaki sefere aktif bir logu silmek yerine 'truncate -s 0 dosya' ile boşaltın.

Ne kadar boş alan bırakmalıyım?

En az %10–15. Veritabanları, paket güncellemeleri ve Docker indirmeleri geçici alana ihtiyaç duyar ve %100 dolu bir disk, yazma sırasında bir veritabanını bozabilir.

Yeniden kurulum yapmadan disk ekleyebilir miyim?

Evet. Daha büyük bir plana geçmek diski yerinde büyütür ve verilerinizi korur — Nano 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB. Yükseltme sunucuyu bir kez yeniden başlatır.

Küçük bir VPS'i genellikle ne doldurur?

Deneyimimize göre: Docker image'ları ve build önbelleği, systemd journal'ı, kimsenin döndürmediği uygulama logları ve /root içinde unutulmuş veritabanı dökümleri ya da yedek arşivleri.

VPS'te hiçbir şeyi bozmadan disk alanı nasıl boşaltılır

VPS diskiniz mi doldu? du ve ncdu ile yeri neyin kapladığını bulun, sonra apt önbelleğini, journal'ı, Docker artıklarını ve logları veri kaybetmeden temizleyin.

"No space left on device" hiçbir zaman uygun bir anda gelmez. Veritabanı yazma kabul etmeyi bırakır, apt bir güncellemeyi bitiremez ve Docker tam da şu an ihtiyacınız olan image'ı indirmeyi reddeder. İyi haber şu: küçük bir VPS'te suçlu neredeyse her zaman beş şeyden biridir ve onu iki dakikada bulursunuz.

1. Durum ne kadar kötü?

df -h /
df -i /

İlk satır kullanılan alanı gösterir. İkincisi inode'ları gösterir — alan normal görünürken inode'lar %100'e ulaştıysa milyonlarca minik dosyanız vardır (oturum dosyaları, bir posta kuyruğu, bir önbellek dizini). Farklı sorun, aynı belirti.

2. Büyük olanı bulun

Ağacı yukarıdan tarayın ve boyuta göre sıralayın:

du -xh / --max-depth=1 2>/dev/null | sort -h | tail -15

-x tek bir dosya sisteminde kalır, böylece /proc içine dalmaz. Ardından en büyük olanın içine inin. Etkileşimli gezinmek için ncdu çok daha rahattır:

apt install -y ncdu
ncdu -x /

Gezinmek için ok tuşları, silmek için d. Sonuncusunda dikkatli olun.

3. Hızlı kazanımlar

Bunlar her Ubuntu veya Debian sunucusunda güvenlidir:

apt clean
apt autoremove --purge -y
journalctl --disk-usage
journalctl --vacuum-size=200M

apt autoremove eski çekirdekleri de temizler. İnsanları şaşırtan systemd journal'ıdır — kendi haline bırakılırsa birkaç gigabayta kadar büyüyebilir. Kalıcı olarak sınırlamak için /etc/systemd/journald.conf içinde SystemMaxUse=200M ayarlayın ve systemctl restart systemd-journald çalıştırın.

4. Docker artıkları

Docker kullanıyorsanız önce buraya bakın. Eski image'lar ve build önbelleği her deploy'da birikir:

docker system df
docker image prune -a
docker builder prune

docker image prune -a, çalışan hiçbir container'ın kullanmadığı image'ları siler. Genelde istediğiniz budur ama bir sonraki deploy onları yeniden indirir.

Tehlikeli olan docker system prune -a --volumes. Volume'lar verilerinizi tutar ve durdurulmuş bir container'a bağlı volume kullanılmıyor sayılır. İnsanlar veritabanlarını böyle kaybeder. Bunu bir forum cevabından kopyalayıp yapıştırmayın.

Diğer gizli alan yiyici container logları. Onları /etc/docker/daemon.json içinde sınırlayın:

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" }
}

Ardından Docker'ı yeniden başlatın. Sınır yalnızca sonradan oluşturulan container'lara uygulanır, bu yüzden gürültülü olanları docker compose up -d --force-recreate ile yeniden oluşturun.

5. Loglar ve unutulmuş dosyalar

Diskin herhangi bir yerindeki büyük dosyaları bulun:

find / -xdev -type f -size +500M -exec ls -lh {} + 2>/dev/null
find /var/log -type f -size +100M -exec ls -lh {} + 2>/dev/null

Her zamanki bulgular: /root içinde altı ay önceden kalma bir backup.tar.gz, birinin indirmeyi düşündüğü bir veritabanı dökümü, hiç döndürülmeyen bir uygulama logu.

Bir servisin hâlâ yazdığı bir logu rm ile silmeyin — boşaltın:

truncate -s 0 /var/log/myapp/app.log

Birini zaten sildiyseniz ve alan geri gelmediyse, bir süreç onu hâlâ açık tutuyordur:

lsof +L1

Orada listelenen servisi yeniden başlatın, alan geri gelir.

Temizlik yetmediğinde

Bazen veri gerçekten gereklidir — büyüyen bir veritabanı, kullanıcı yüklemeleri, bir model dosyası. O zaman dürüst çözüm daha fazla disktir. Plan yükseltmesi diski yerinde büyütür ve her şeyi korur: Nano 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB. Sunucu bir kez yeniden başlar. Ayrıntılar plan belgelerinde.

Sessizce alan yiyen bir şey daha: swap dosyası. Swap rehberimizi izlediyseniz o 1–2 GB bilerek ayrılmıştır. Ve en büyük tüketici Docker ise Docker kurulum rehberi ile Compose stack rehberi image kalabalığını nasıl kontrol altında tutacağınızı gösterir.

Bütün bunları önleyen alışkanlık: journal'ı ve Docker loglarını ilk gün sınırlayın. İki satır yapılandırma, ve "disk doldu" neredeyse hiç yaşanmaz.