Önce Etkiyi ve Geri Dönüş Noktasını Belirleyin

Disk doluluğunda ilk hedef hemen alan açmak değil, veri kaybını ve kontrolsüz kesintiyi önlemektir. Sorun; uygulama hatası, aşırı log üretimi, geçici dosyalar, veritabanı büyümesi, başarısız yedekleme veya inode tükenmesi nedeniyle oluşabilir. Müdahaleye başlamadan önce etkilenen servisleri, kullanıcı trafiğini ve mevcut geri dönüş seçeneklerini belirleyin.

• SSH erişiminin sürdüğünü ve kritik servislerin çalışıp çalışmadığını kontrol edin.
• Son başarılı yedeğin tarihini, kapsamını ve geri yüklenebilirliğini doğrulayın.
• Disk, inode ve mount durumunu değişiklik öncesinde kayıt altına alın.
• Mümkünse anlık görüntü veya ayrı bir yedek alın; bunun üretim diskinde ek doluluk oluşturup oluşturmayacağını hesaplayın.
• SSH oturumunu açık tutun ve konsol ya da kurtarma erişiminin kullanılabilir olduğunu doğrulayın.

Kök dosya sistemi tamamen dolduğunda servisler yeni log, PID veya geçici dosya oluşturamayabilir. Bu nedenle bir komutun başarılı görünmesi, uygulamanın sağlıklı olduğu anlamına gelmez. Kritik değişikliklerden önce kimin onay vereceğini ve gerektiğinde trafiğin nasıl geri alınacağını netleştirin.

Güvenli Teşhis: Disk Alanı ile İnodeları Ayırın

İlk olarak hangi dosya sistemi veya mount noktasının dolduğunu belirleyin. Ardından büyük dizinleri üstten alta doğru inceleyin. Rastgele dosya silmek yerine dosyanın sahibi olan servisi, saklama politikasını ve yeniden üretilebilir olup olmadığını tespit edin.



Komutları kullandığınız dağıtım ve shell ortamına göre doğrulayın. Silinmiş olmasına rağmen bir proses tarafından açık tutulan dosyalar da alan tüketebilir. Bu durumda açık dosyaları, ilgili prosesi ve dosya kapatıldığında alanın gerçekten serbest kalıp kalmayacağını inceleyin.

Büyük bir dosyanın log olduğunu düşünüyorsanız önce şu noktaları kontrol edin:

• Dosyanın hangi servis veya kullanıcı tarafından yazıldığı.
• Logrotate ya da benzeri döndürme politikasının çalışıp çalışmadığı.
• Uygulamanın hata veya debug seviyesinin beklenmedik biçimde yükselip yükselmediği.
• Dosyanın aktif kullanılıp kullanılmadığı ve silme işleminin servisi etkileyip etkilemeyeceği.

İnode doluluğunda dosyaların toplam boyutu normal görünebilir. Çok sayıda küçük önbellek, oturum, geçici dosya veya başarısız işlem artığı bu duruma yol açabilir. Teşhis sırasında hem dosya boyutunu hem dosya sayısını değerlendirin.

Temizlik ve Servis Müdahalesini Geri Alınabilir Yapın

Önceliği yeniden üretilebilen ve artık kullanılmayan verilere verin. Doğrulanmış eski log arşivleri, süresi dolmuş geçici dosyalar ve paket önbellekleri buna örnek olabilir. Kullanıcı yüklemeleri, veritabanı dosyaları, yapılandırmalar, Docker volume'ları ve yedekler yeniden üretilebilir kabul edilmemelidir.

• Silme veya taşıma öncesinde yol, sahip, boyut ve son değişiklik zamanını kaydedin.
• Aktif log dosyasını elle silmek yerine servisin güvenli log döndürme yöntemini kullanın.
• Veritabanı dosyalarını, volume'ları ve yedek dizinlerini manuel olarak temizlemeyin.
• Geçici temizlikten sonra servis durumunu, hata loglarını ve temel uygulama işlevlerini kontrol edin.
• Üretim verisini silmek yerine saklama süresini, kota politikasını ve otomatik temizliği düzeltin.

Bir arşivi başka bir dosya sistemine taşımak gerekiyorsa hedefte yeterli alan bulunduğunu ve aktarımın eksiksiz doğrulanacağını önceden belirleyin. Aktarım kesilirse kısmi dosyayı geçerli yedek kabul etmeyin; dosya boyutunu, sağlama değerini veya arşiv testini kontrol edin. Gerekirse önce kopyalayın, doğrulayın, ardından kaynak dosyayı silin.

Yedekleme, Geri Yükleme ve Kapanış Kontrolleri

Disk sorununun çözülmesi, yalnızca servislerin yeniden başlamasıyla doğrulanmış sayılmaz. Kontrollü biçimde giriş, dosya yükleme, veritabanına yazma, kuyruk işlemleri, zamanlanmış görevler ve dış API bağlantıları test edilmelidir. Testleri mümkünse düşük trafik döneminde ve izleme açıkken gerçekleştirin.

Geri dönüş planında en az şu bilgiler bulunmalıdır:

• Kullanılacak yedeğin tarihi, kapsamı ve saklandığı konum.
• Geri yüklemenin hangi ayrı ortama veya diske yapılacağı.
• DNS, yük dengeleyici veya trafik geçişinin nasıl geri alınacağı.
• Kabul edilebilir veri kaybı süresi ve olası eksik kayıtların kapsamı.
• İşlemi kimin onaylayacağı ve başarısızlıkta hangi adımların uygulanacağı.

Mümkünse yedeği önce ayrı bir ortamda geri yükleyin. Dosya sayısı, veritabanının açılması, uygulama sağlık kontrolleri ve örnek kullanıcı işlemleriyle doğrulama yapın. Geri yükleme tamamlandıktan sonra izinler, sahiplikler, SSL sertifikaları, cron görevleri ve ortam değişkenlerinin de doğru olduğunu kontrol edin.

Kapanış kaydına şu bilgileri ekleyin:

• Doluluğun kök nedeni ve ilk fark edildiği zaman.
• Çalıştırılan komutlar, değiştirilen ayarlar ve temizlenen verinin kapsamı.
• Yedek ile geri yükleme testinin sonucu.
• Tekrarı önlemek için yapılan logrotate, kapasite, kota, alarm veya otomatik temizlik değişiklikleri.

İzlemede disk kullanım yüzdesi ve inode kullanımının yanında yazma hızındaki olağandışı artışları da takip edin. Alarm üretmek tek başına yeterli değildir; alarm geldiğinde hangi servisin, kim tarafından, hangi sırayla ve hangi geri dönüş adımıyla inceleneceği runbook içinde açıkça yazılmalıdır.