Disk Doldu Yazısını Gördüğünde İş Çoktan Bitmiştir: E-pin Satış Sisteminde Sessizce Diskini Yiyen Gizli Dosyaların İfşası

Bir sabah panel açılmıyor, ödeme sayfası hata veriyor, e-postalar gitmiyor. Hosting paneline bakıyorsun: disk yüzde yüz. İlk düşünce genelde şu olur: "ürünlerim çok, o yüzden dolmuş." Halbuki bir e-pin satış scriptinde ürünler diskin en hafif parçasıdır. Birkaç yüz bin satırlık stok tablosu bile birkaç yüz megabayt yer tutar. Diski dolduran şey neredeyse her zaman ürünler değil, arka planda biriken çöptür.

Bu çöp sessiz büyür. Kimse bakmaz, uyarı vermez, bir gün eşiği aşar ve tüm sipariş akışını durdurur. Daha kötüsü, disk dolduğunda sistem sadece yavaşlamaz; veritabanı yazamaz hale gelir, ödeme kaydı düşmez, kod teslim edilmez. Yani ortada bir depolama sorunu değil, doğrudan gelir kaybı vardır. Bu yazıda diski gerçekten kimin yediğini, inode tuzağını ve bir daha aynı noktaya gelmemek için kurman gereken üç mekanizmayı anlatıyorum.

Disk Neden Doluyor, Gerçekten Ürünlerin mi Ağır?

Bir dijital ürün satış yazılımında diski yiyen dosyalar genelde şu beş kümeden gelir: uygulama ve hata kayıtları, oturum dosyaları, önbellek klasörü, e-posta kuyruğu ve aynı diskte tutulan yedekler. Bunların hepsi normal çalışmanın yan ürünüdür; sorun üretilmesi değil, hiç temizlenmemesidir. Günde 40 megabayt üreten bir kayıt sistemi, bir yılda 14 gigabaytın üzerine çıkar.

Teşhisin en hızlı yolu klasör bazında büyüklük ölçmektir. SSH erişimin varsa kök dizinde en büyük klasörleri listelemek yeterli; yoksa dosya yöneticisinden klasör boyutlarını sırala. Gerçek suçluyu bulmadan yapılan her temizlik tahmindir. Çoğu vakada ilk üç klasör toplam kullanımın yüzde sekseninden fazlasını açıklar ve bu klasörlerin hiçbiri ürün görselleri değildir.

inode Kotası mı, Alan Kotası mı?

Bu ayrım çok sayıda satıcının günlerini alır. Panel "disk kullanımı yüzde 40" derken site hâlâ yazma hatası veriyorsa, sorun alan değil inode yani dosya sayısı kotasıdır. Paylaşımlı paketlerde genelde 200 bin ile 500 bin arası bir sınır vardır. Her oturum dosyası, her önbellek parçası, her küçük fatura dosyası bir inode harcar. Boyutları toplasan bir gigabaytı geçmez ama sayı olarak kotayı bitirirler.

inode tükenmesinin klasik belirtileri şunlardır: yeni dosya oluşturulamaz, oturum açılamaz, önbellek yazılamaz ve garip biçimde bazı sayfalar çalışırken bazıları çalışmaz. Çözüm boyut silmek değil, dosya sayısını azaltmaktır. Eski oturum dosyalarını temizlemek, önbelleği düzenli boşaltmak ve fatura PDF'lerini ayda bir arşivleyip tek dosyaya almak inode kullanımını dramatik biçimde düşürür.

Disk Dolduğunda Siparişlere Tam Olarak Ne Olur?

Burası konunun en can yakıcı kısmı. Disk dolduğunda MySQL geçici dosya yazamaz ve tabloları salt okunur gibi davranmaya zorlar. Sonuç: müşteri ödemeyi yapar, sağlayıcıdan onay döner, ama sipariş kaydı veritabanına yazılamaz. Para geçmiştir, kayıt yoktur. Kod teslim edilmez, müşteri haklı olarak yazar ve elinde gösterecek bir sipariş satırı bile bulunmaz.

Bu yüzden disk dolması bir bakım konusu değil, ticari bir acil durumdur. Doğru müdahale sırası şudur: önce siteyi bakım moduna al ki yeni ödeme alınmasın, sonra en büyük tek dosyayı hedef alarak hızlı alan aç, ardından ödeme sağlayıcı raporuyla kendi sipariş listeni karşılaştır ve kaydı düşmeyen işlemleri elle tamamla. Bu üçüncü adımı atlayan satıcılar haftalar sonra hâlâ kayıp sipariş tartışıyor olur.

Bir Kayıt Dosyası 18 GB Olur mu? Olur.

Hata ayıklama modu bir kez açılıp kapatılmayı unutulduğunda, her istek için onlarca satır yazılır. Ödeme sağlayıcıya giden her isteğin tam gövdesi kayda düşer. Bunu bir de tekrarlayan bir hata ile birleştir; aynı uyarı saniyede birkaç kez yazılır. Birkaç ay sonra tek bir dosya, tüm hosting paketinden büyük hale gelir. Bu, uydurma bir senaryo değil; en sık karşılaşılan tek kalem.

Kalıcı çözüm rotasyondur. Kayıt dosyası belirli bir boyuta ulaştığında yenisi açılır, eskiler sıkıştırılır ve belirli bir süre sonra silinir. Ayrıca üretimde hata ayıklama seviyesi kapalı, yalnızca uyarı ve hata seviyesi açık olmalı. Bir de şu alışkanlık: kayıt dosyalarına düzenli bakmak. Sadece yer açmak için değil, orada tekrarlayan bir hata varsa onu görmek için. Şişen kayıt genelde bir arızanın habercisidir.

Yedekleri Aynı Diskte Tutmanın İki Katlı Bedeli

Çok yaygın bir alışkanlık: yedekleri hesabın içinde bir klasörde biriktirmek. Bu iki ayrı sorun yaratır. Birincisi depolama; her tam yedek gigabaytlar ekler ve otomatik yedek açıksa artış sessizdir. İkincisi ve daha ciddisi, yedeğin koruma amacını yitirmesi. Sunucu diski bozulursa ya da hesap askıya alınırsa, yedeğin de gitmiştir. Aynı sepette taşınan yumurta mantığı.

Doğru kurgu şudur: yedek üretilir, dış bir depolama alanına aktarılır, hesaptaki kopya silinir. Böylece disk sabit kalır ve yedek gerçek bir sigortaya dönüşür. Pinova'da yedek hedefinin dışa yönlendirilebilir olması bu yüzden temel bir gereklilik; kapsam ve paket karşılaştırmasını fiyat bölümünde görebilirsin.

Kalıcı Çözüm: Rotasyon, İzleme ve Ayrık Depolama

Disk sorunu tek seferlik bir temizlikle çözülmez; çözülmüş gibi görünür ve üç ay sonra aynı yerden geri gelir. Kalıcı çözüm üç mekanizmanın birlikte kurulmasıdır. Rotasyon, üretilen çöpün ömrünü sınırlar. İzleme, eşiğe yaklaşıldığında sana haber verir. Ayrık depolama ise büyüyen tek kalem olan yedekleri diskin dışına çıkarır.

İzleme kısmını özellikle vurgulamak isterim çünkü en çok atlanan adım burasıdır. Yüzde 75 eşiğinde bir uyarı e-postası alan satıcı, sorunu iş saatinde ve sakin kafayla çözer. Uyarısı olmayan satıcı ise aynı sorunu gece yarısı, ödeme akışı durmuşken öğrenir. Aradaki fark teknik değil, tamamen hazırlıkla ilgilidir. Sistemin hangi bileşenlerinin bu izlemeyi sağladığını özellikler bölümünde inceleyebilirsin.

Disk doluluğu, bir e-pin işletmesinde en kolay önlenebilir ama en pahalıya patlayan arızadır. Rotasyonu kur, eşik uyarısını aç, yedekleri dışarı taşı; bu üçü tamamlandığında konu gündeminden tamamen düşer. Diskin nasıl izlendiğini, kayıt ve yedek ayarlarının panelde nereden yönetildiğini merak ediyorsan canlı demo üzerinden sistem ekranlarını özgürce gezebilirsin.