Disk alanı: nereye gidiyor

Diski neyin doldurduğunu nasıl bulursun, silinmiş ama açık bir dosya neden tehlikeli, neyi temizlemek güvenli ve paneldeki kullanım halkası neden yanlış gösterebilir.

23 Ağustos 2026 tarihinde güncellendi

Yer bitmesi, kendini her şey gibi gösterebilen bir kesintidir: veritabanı yazamaz, site hata döner, konteynerler yeniden başlar. Bir VDS diski giriş seviyesinde 40 GB'dan en üst seviyede 250 GB'a kadar uzanır ve neredeyse her zaman aynı şeylerle dolar.

İlk komutlar

df -h
df -i
sudo du -x -h -d1 / | sort -h | tail -15

df -i komutunu atlama: boş alanın olabilir ama inode'ların tükenmiş olabilir — o zaman gigabaytlarca boş alana rağmen “disk dolu” hatası alırsın. Suçlu genellikle milyonlarca küçük önbellek dosyasıdır.

Sonra en büyük dizine in:

sudo du -x -h -d1 /var | sort -h | tail
sudo du -x -h -d1 /var/lib | sort -h | tail

-x bayrağı sayımı tek bir dosya sisteminde tutar ve bağlı dizinlere taşmaz.

Yaygın suçlular

Ne	Nasıl kontrol edilir	Ne yapmalı
Konteyner günlükleri	`du -sh /var/lib/docker/containers//-json.log`	Boyutu sınırla, bkz. günlükler
İmajlar ve derleme önbelleği	`docker system df`	`docker image prune`, `docker builder prune`
Sistem günlüğü	`journalctl --disk-usage`	`journalctl --vacuum-size=200M`
`/boot` içindeki eski çekirdekler	`df -h /boot`	`apt autoremove --purge`
Paket önbelleği	`du -sh /var/cache/apt`	`apt clean`
Yerinde bırakılan kopyalar	`du -sh /backup`	Bunları sunucu dışına taşı, bkz. başka bir konum
Kullanıcı yüklemeleri	`du -sh /var/www/uploads`	Harici depolama ya da daha büyük bir disk

Hâlâ yer kaplayan silinmiş bir dosya

Klasik bir bilmece: du 5 GB gösterir, df 30 GB kullanıldığını gösterir. Bu, dosyanın silindiği ama bir sürecin onu hâlâ açık tuttuğu anlamına gelir ve yeniden başlatılana kadar alan serbest bırakılmaz.

sudo lsof +L1 | head -20

Çıktı süreçleri ve boyutları gösterecektir. Çözüm, suçluyu yeniden başlatmaktır:

sudo systemctl restart <service>
docker compose restart <service>

Kullanımda olan bir günlük dosyasını asla rm ile silerek yer açma. Doğru yol onu kırpmaktır: sudo truncate -s 0 /var/log/big.log. Silmek, alanı dolu bırakır ve ayrıca günlüğü kaybetmene neden olur.

Paneldeki kullanım halkası

“Genel Bakış” sekmesinde bir disk kullanım halkası vardır. Bu, konuk ajanı qemu-guest-agent üzerinden hesaplanır. Ajan kaldırılmışsa veya çalışmıyorsa veriler güncellenmez — panel kurulum komutunu gösterir. Makine içinde kontrol etmek için:

systemctl status qemu-guest-agent

Ajanın okumaları ile df -h uyuşmalıdır. Bir tutarsızlık çoğunlukla alanın bir kısmının ayrı bağlanmış bir bölümde kaplandığı anlamına gelir — bkz. bölümler ve dosya sistemleri.

Önleme

Temizlik ve uyarı içeren bir zamanlanmış görev kur:

#!/bin/bash
USED=$(df --output=pcent / | tail -1 | tr -dc '0-9')
if [ "$USED" -gt 85 ]; then
  journalctl --vacuum-size=200M
  apt clean
  docker image prune -f
  echo "Disk is ${USED}% full" | mail -s "VDS: low disk space" you@example.com
fi

%85 eşiği sana tepki vermek için alan bırakır. %100'ü bekleyemezsin: disk dolduğunda bazı servisler ne olduğuna dair bir günlük bile yazamaz.

Hiç yer yoksa

Hızlı önlemlerle birkaç gigabayt boşalt: journalctl --vacuum-size=100M, apt clean, docker builder prune -f.
Gerçek nedeni yukarıdaki komutlarla bul — yoksa her şey bir hafta içinde tekrarlanır.
Veriler gerçekten büyüdüyse, daha yüksek bir seviyeye geçerek diski büyütmen gerekir. Düşürme yoktur: disk küçültülemez.