VPS Disk Dolu: Alan, Inode ve Açık Dosya Teşhisi

Önce hata veren yolun dosya sistemini bulun

disk_path='/var'
df -hT "$disk_path"
df -i "$disk_path"

/var yerine uygulamanın gerçekten yazdığı dizini seçin. /, /var, /srv, ayrı bir veri diski veya container içindeki yol farklı depolamalara karşılık gelebilir. Başka bir dosya sisteminde alan açmak, dolu olan hedefe yer kazandırmaz. df çıktısında aygıtı, türü ve bağlama noktasını birlikte okuyun.

Hata metnini de kaydedin. Kullanıcı veya proje kotası, salt okunur hâle gelen dosya sistemi ve I/O hatası birbirinden farklı sorunlardır. Dosya sistemi hatası nedeniyle yazma engellenmişse rastgele temizlik bir onarım yöntemi değildir. Önce kayıttaki neden ve depolamanın durumu doğrulanmalıdır.

Kapasiteyi yalnız gigabayt olarak düşünmeyin

Inode, dosya sistemi nesnelerini temsil eden yapılardır. Küçük dosyaların sayısı sınıra ulaştığında büyük bir dosyayı silmek yeterli sayıda inode açmayabilir. Her dosya sistemi inode yönetimini aynı biçimde yapmaz; çıktıyı kullanılan dosya sistemiyle birlikte değerlendirin. Blok ve inode doluluklarını ayrı izleyin.

Büyük veya çok dosyalı dizini aşamalı bulun

du -x -h --max-depth=1 /var/log
du --inodes -x --max-depth=1 /var/log

Bu örneği hatanın görüldüğü dosya sistemindeki ilgili dizine uyarlayın. -x başka dosya sistemlerine geçişi sınırlar. İlk komut alanı, ikinci komut inode kullanımını gösterir. Sonuçtaki büyük alt dizini daha dar bir kapsamla inceleyin; tüm sunucuyu tekrar tekrar taramak yoğun bir sistemde sorunu artırabilir.

Erişim reddi veya okuma hatası varsa çıktı eksik olabilir. Hataları görünmez yapıp küçük toplamı kesin sonuç kabul etmeyin. du erişebildiği dizin ağacını, df ise dosya sisteminin alan hesabını bildirir. Sparse dosyalar, paylaşılmış bloklar, snapshotlar, metadata ve ayrılmış alan gibi özellikler bu iki hesabı farklılaştırabilir.

Silinmiş ama açık dosyaları kontrol edin

sudo lsof -nP +L1

lsof +L1, bağlantı sayısı birden küçük açık dosyaları seçer; bunlar adı kaldırılmış dosyalar olabilir. Liste büyük bir logun uygulama tarafından hâlâ açık tutulduğunu gösteriyorsa, adını yeniden silmeye çalışmak alan kazandırmaz. Süreç dosyayı açık tuttuğu sürece depolama blokları serbest kalmayabilir.

PID, dosya türü, aygıt ve dosya sahibini doğrulayın. Her açık silinmiş dosya gereksiz log değildir. Servisin belgelenmiş log yeniden açma veya rotasyon yöntemini araştırın; gerekirse kesinti ve veri tutarlılığı planıyla müdahale edin. Süreç dosya tanıtıcısının içeriğini körlemesine sıfırlamayın. Bu çıktı teşhis içindir, otomatik kapatma listesi değildir.

Temizlenebilecek veriyi saklama kuralıyla ayırın

journalctl --disk-usage

journalctl çıktısı etkin ve arşivlenmiş günlükleri birlikte sayar. Systemd’nin vacuum işlemleri arşivlenmiş dosyaları hedeflediğinden, toplam rapor ile geri kazanılabilecek alan birebir aynı olmayabilir. Silmeye geçmeden önce hangi zaman aralığının olay incelemesi veya saklama ihtiyacı için gerekli olduğunu belirleyin.

Uygulama logları için rotasyon, saklama ve yeniden açma davranışını birlikte düzeltin. Yalnız bugünkü büyük dosyayı kaldırmak büyüme nedenini çözmez. Dağıtımın paket önbelleği gibi yeniden edinilebilen veriler, veritabanı dosyalarıyla aynı kategoride değerlendirilmemelidir; yine de geri dönüşte gerekli paketlere erişiminizi doğrulayın.

Veritabanı ve container alanını kendi araçlarıyla ele alın

docker system df -v

Bu komut mevcut Docker yetkisi gerektirir ve alan kullanımını raporlar. Image, container ve volume verisini ayrı okuyun. Kullanılmıyor olarak görünen bir volume geri dönüş veya bağımsız uygulama verisi taşıyabilir. Bir temizleme aracının reclaimable etiketi, verinin işletme açısından gereksiz olduğunu kanıtlamaz.

Veritabanı veri dosyalarını, WAL veya binlog dosyalarını dosya yöneticisinden rastgele silmeyin. Bunlar kurtarma ve replikasyon zincirinin parçası olabilir. Veritabanının desteklediği saklama ve bakım yöntemini izleyin. Bazı bakım işlemleri ek geçici alan gerektirir; tamamen dolu diskte büyük bir bakım başlatmadan önce gereken çalışma alanını planlayın.

Temizlik yetmiyorsa büyümeyi ve genişletmeyi planlayın

Veri meşru biçimde büyüyorsa sürekli arşiv silmek yerine kapasiteyi veya veri yerleşimini değiştirmeniz gerekebilir. Günlük büyümeyi, en büyük yüklemeyi, veritabanı geçici dosyalarını ve yedek hazırlığını hesaba katın. Bağımsız yedeği aynı VPS diskinde tutmak, disk kaybına karşı ayrı kopya sağlamaz.

VPS paketindeki disk kapasitesinin artırılması, konuk içindeki bölüm ve dosya sisteminin otomatik büyüdüğü anlamına gelmez. Sağlayıcının desteklediği işlem sırasını, dosya sistemi yöntemini ve kesinti gereksinimini doğrulayın. Disk veya bölüm değişikliğinden önce geri yüklenebilir yedek ve kurtarma erişimi hazır olmalıdır. Bu rehber bölüm değiştirme komutu önermez.

Alanı, uygulamayı ve büyüme nedenini yeniden kontrol edin

Planlı müdahale sonrasında aynı yol için df ve inode ölçümünü tekrar değerlendirin. Uygulamanın hata kayıtları, bekleyen işler ve yazma ihtiyacını da kontrol edin. Alan açılmış olması daha önce başarısız olan siparişin, yüklemenin veya kuyruk işinin otomatik tamamlandığını göstermez; uygulamanın güvenli tekrar deneme yöntemini izleyin.

• Blok alanı ve inode için ayrı uyarılar tanımlayın.
• Büyüme hızını en yoğun iş ve yedek penceresiyle karşılaştırın.
• Log ve önbellek saklama kurallarının gerçekten uygulandığını izleyin.
• Müdahalede hangi dosya türünden ne kadar alan kazanıldığını kaydedin.

Herkese uygun tek bir doluluk yüzdesi yoktur. Büyük geçici işlem yapan bir uygulamanın daha geniş çalışma payına ihtiyacı olabilir. Hedef, yalnız uyarıyı susturmak değil, beklenen büyümeyi karşılayacak alanı ve işletim sürecini oluşturmaktır.