Sunucunuzda Disk Alanı Tükendiğinde: Önleme, Tespit ve Kurtarma

Diskin tamamen dolması, sunuculardaki en yıkıcı arızalardan biridir. Uygulama açısından ilerleyiş düşüşü yaşamadan, aniden gerçekleşir; her şey yolunda gidiyorken birdenbire sorun çıkmaya başlar. Ardından, ardışık olarak: günlük yazma işlemleri başarısız olur, veritabanı işlemleri iptal edilir, PHP oturumları kaydedilemez ve uygulamanız, gerçek sebebe işaret etmeyen karmaşık hatalarla çöker.

<p>Disk alanının tükenmesi, tamamen önlenebilir bir durumu temsil eder. Ancak, özellikle 25-40 GB SSD'leri olan bulut sunucularda, üretim kesintilerine yol açan en yaygın sebeplerden biri olmaya devam etmektedir.</p>

<p>Bu kılavuz, disk alanı yönetiminin üç aşamasını kapsamaktadır: dolmasını önlemek, dolmaya yakın olduğunu tespit etmek ve dolu olduğunda geri dönüşüm sağlamak.</p>

<h2>
    <a name="what-fills-up-your-disk" href="#what-fills-up-your-disk">
    </a>
    Disk Alanınızı Neler Dolduruyor?
</h2>

<p>Tipik bir Deploynix yönetimindeki Laravel sunucusunda, disk kullanımı beş kaynaktan gelmektedir; büyüme sırasına göre aşağıda sıralanmıştır:</p>

<h3>
    <a name="1-application-logs" href="#1-application-logs">
    </a>
    1. Uygulama Günlükleri
</h3>

<p>Laravel’in varsayılan günlükleme yapılandırması, <code>storage/logs/laravel.log</code> dosyasına yazmaktadır. Üretim ortamında, yoğun bir uygulama günde yüzlerce megabayt günlük verisi üretebilir. Hata günlükleri özellikle fazladır; tek bir işlenmemiş istisna, tam bir yığın izi ile birkaç kilobyte özelliğe sahip olabilir, ve bu hata her istekte gerçekleşirse, günlük dosyası saatte gigabaytlarca büyüyebilir.</p>

<p><code>daily</code> günlük kanalı, her gün yeni bir dosya oluşturarak bu durumu bir nebze hafifletmektedir (<code>laravel-2026-03-18.log</code>), ancak bir saklama sınırı olmadan bu günlük dosyaları süresiz olarak birikir.</p>

<h3>
    <a name="2-old-deployment-releases" href="#2-old-deployment-releases">
    </a>
    2. Eski Dağıtım Sürümleri
</h3>

<p>Deploynix, sıfır-downtime (kesintisiz dağıtım) için sembolik bağlantı yapısını kullanmaktadır. Her dağıtım, uygulama kodunuzun tam bir kopyasını içeren yeni bir sürüm dizini oluşturur (paylaşılan dizinler olan <code>storage</code> ve <code>vendor</code> hariç). Günde beş kez dağıtım yaparsanız ve sürümleri sonsuza dek saklarsanız, her biri 50 MB olan sürümler hızla birikir: günde 250 MB, ayda 7.5 GB.</p>

<p>Deploynix, yapılandırılmış saklama sayısını aşan eski sürümleri otomatik olarak siler. Varsayılan olarak, genellikle 5 sürüm tutulmaktadır. Eğer dağıtım yapılandırmanız daha fazlasını saklıyorsa veya temizleme adımı sessizce başarısız olursa, sürümler birikir.</p>

<h3>
    <a name="3-database-dumps-and-backups" href="#3-database-dumps-and-backups">
    </a>
    3. Veritabanı Yedeklemeleri ve Dumps
</h3>

<p>Sunucuda bırakılan manuel veritabanı dump'ları yaygın bir disk tüketicisidir. Bir sorunu debug etmek için <code>mysqldump</code> komutunu çalıştırıp, çıktı dosyasını silmeyi unutursanız, ev dizininde birkaç gigabaytlık bir dosya kalabilir.</p>

<p>Deploynix’in otomatik yedeklemeleri, dump'ları doğrudan dış depolamaya (S3, Wasabi, DigitalOcean Spaces) gönderir, böylece yerel diskte yer kaplamazlar. Ama manuel yedeklemeler çalıştırırsanız veya yedekleme görevi dump oluşturduktan sonra ama yükleme öncesinde başarısız olursa, yerel dosya kalır.</p>

<h3>
    <a name="4-system-logs-and-package-cache" href="#4-system-logs-and-package-cache">
    </a>
    4. Sistem Günlükleri ve Paket Ön Belleği
</h3>

<p>Ubuntu’nun sistem günlükleri (<code>/var/log/syslog</code>, <code>/var/log/auth.log</code>, journal günlükleri), apt paket önbelleği (<code>/var/cache/apt</code>) ve eski çekirdek sürümleri, uygulamanızın görünümüne sahip olmadığı disk alanını tüketmektedir.</p>

<p><code>journalctl</code> günlükleri, sistemd günlüğü boyut sınırları yapılandırılmadıysa özellikle büyük büyüyebilir. Birden fazla demon (Nginx, PHP-FPM, MySQL, Supervisor) ile bir sunucu üzerinde, tüm hizmetlerden gelen günlükler birikir.</p>

<h3>
    <a name="5-mysql-binary-logs-and-temporary-files" href="#5-mysql-binary-logs-and-temporary-files">
    </a>
    5. MySQL İkili Günlükleri ve Geçici Dosyalar
</h3>

<p>MySQL, çoğaltma ve zamansal geri yükleme için ikili günlükler üretir. İkili güncelleme etkinleştirildiğinde (MySQL 8.x’te varsayılan) ve <code>expire_logs_days</code> ayarı genişse, ikili günlükler gigabaytları tüketebilir.</p>

<p>MySQL, karmaşık sorgular (sıralamalar, birleştirmeler, geçici tablolar) için geçici dosyalar da oluşturur. Bunlar genellikle otomatik olarak temizlenir, ancak bir sorgu yürütme sırasında sonlandırılırsa, geçici dosyalar terkedilmiş olabilir.</p>

<h2>
    <a name="prevention-stop-the-disk-from-filling-up" href="#prevention-stop-the-disk-from-filling-up">
    </a>
    Önleme: Diskin Dolu Olmasını Engelle
</h2>

<h3>
    <a name="configure-log-rotation-for-laravel" href="#configure-log-rotation-for-laravel">
    </a>
    Laravel için Günlük Döngüsü Yapılandırın
</h3>

<p><code>single</code> günlük kanalını <code>daily</code> ile saklama süresi ile değiştirin:</p>
<div class="highlight js-code-highlight">
    <pre class="highlight php"><code><span class="c1">// config/logging.php</span>

‘channels’ => [
‘daily’ => [
‘driver’ => ‘daily’,
‘path’ => storage_path(<span class=”s1>’logs/laravel.log’),
‘level’ => <span class=”s1>’info’,
‘days’ => 7,
],
],