Dijital Ürün Scripti Arşivleme Gerçeği: Panelindeki Eski Siparişler Neden Sessizce Şişiyor ve Hangi Veriyi Kaç Yıl Saklamak Zorundasın?

Çoğu işletme sahibi, dijital ürün satış scriptinde 'arşivleme' denince akla gelen tek şeyin veritabanı yedeği almak olduğunu sanır. Haftada bir sıkıştırılmış dosyayı indirip masaüstüne atmak, yılların birikimini güvence altına aldığı hissini verir. Oysa asıl tehlike yedeğin olmaması değil; panelde her gün sessizce büyüyen, kimsenin sınıflandırmadığı veri yığınının bir gün seni hem yavaşlatması hem de bir uyuşmazlıkta elin boş bırakmasıdır.

Bu yazıda yedekleme ile arşivlemenin neden aynı şey olmadığını, bir e-pin scriptinin hangi tablolarında veri patlaması yaşandığını ve hangi kaydı ne kadar süre tutmanın mantıklı olduğunu tek tek açacağım. Amaç sana korku satmak değil; iki yıl sonra 'keşke o kaydı silmemişim' ya da 'keşke bu tabloyu şişirmemişim' dediğin anı hiç yaşatmamak. Doğru kurulmuş bir arşiv düzeni, panelin hızını da müşteri güvenini de aynı anda korur.

Yedek almak arşivleme mi? Bu ikisini karıştıran herkes aynı yere çarpıyor

Yedek, dünün fotoğrafıdır: sistem çöktüğünde geri dönmek içindir. Arşiv ise yaşayan sistemden çıkarılmış, ama erişilebilir kalmış veridir. İkisinin amacı farklı olduğu için stratejileri de farklıdır. Yedeğe bakıp 'verim güvende' diyen bir işletme, üç yıl önceki bir siparişin kod teslim kaydını sorgulamak istediğinde koca bir dosyayı geri yüklemek zorunda kalır. Bu da canlı paneli riske atmak demektir.

Sağlıklı kurulum üç katmandan oluşur: canlı veri (son 90-180 gün, hızlı sorgulanan), sıcak arşiv (ayrı tabloda veya ayrı veritabanında tutulan, rapor için erişilebilir geçmiş) ve soğuk arşiv (sıkıştırılmış, nadiren açılan, uzun ömürlü depo). Dijital ürün satış yazılımı tarafında bu ayrımı yapmadığın sürece paneli büyüten her gün, gelecekteki her raporu biraz daha yavaşlatır. Pinova'da geçmiş kayıtları canlı listelerden ayırıp arşiv görünümünden okumak, tam olarak bu üç katmanı tek panelde yönetmen için var.

Hangi tablo seni önce boğar? Veri patlamasının sessiz kaynakları

Deneyimli bir gözle bakıldığında bir e-pin satış scriptinin hacmi ürünlerden değil, izlerden büyür. Sipariş sayısı ayda bin bile olmasa; her sayfa görüntüleme, her giriş denemesi, her kur güncelleme, her bildirim kuyruğu kaydı satır üretir. Altı ay sonra bakarsın ki ürün tablosu birkaç megabayt, log tabloları gigabaytlarca. Sorun disk değil; yedek süresinin uzaması, rapor sorgularının yavaşlaması ve bir arıza anında neyi arayacağını bulamamaktır.

Bu yüzden arşiv stratejisi her zaman bir envanterle başlar. Tabloları 'ne işe yarıyor, kim okuyor, kaç gün sonra değersiz oluyor' sorularıyla etiketle. Değersizleşen kaydı silmek değil, döndürmek gerekir: belirli bir yaşı geçen satırları aylık arşiv tablolarına taşımak, canlı tabloyu hafif tutar. Rotasyon kuralı olmayan log, log değil çöplüktür ve bir gün en çok ihtiyaç duyduğun anda içinde aradığını bulamazsın.

Bir e-pin yazılımında kodun kendisi saklanır mı? İşte kritik ayrım

Burada çok işletmenin yanlış yaptığı nokta var: satılmış ve teslim edilmiş bir kodun düz metin hâlini süresiz tutmak fayda değil yük getirir. Çünkü o kod artık müşteriye ait bir değer taşıyıcısıdır ve panelinde okunabilir hâlde durduğu her gün bir sızıntı senaryosunun kapsamını büyütür. Doğru yaklaşım, kodun tamamını değil doğrulanabilir izini saklamaktır: maskelenmiş son haneler, tekilleştirme için üretilmiş özet değeri, teslim zamanı, hangi siparişe gittiği ve hangi tedarikçi partisinden geldiği.

Bu izle hem 'ben bu kodu aldım ama çalışmıyor' diyen müşteriye net cevap verirsin, hem de aynı kodun ikinci kez satılmadığını kanıtlarsın. Satılmamış stoktaki kodlar ise ayrı konudur: onlar şifreli alanlarda, erişimi sınırlı biçimde durmalıdır. Arşiv, değer taşımayan ama ispat taşıyan veriyi biriktirme sanatıdır. Bu ayrımı kuran bir epin yazılım kurulumu, hem müşteri güvenini hem de kendi hukuki pozisyonunu aynı hamlede sağlamlaştırır.

Yedeği nereye koyuyorsun? Aynı sunucudaki kopya yedek değildir

Arşiv stratejisinin en çok atlanan kısmı konumdur. Sunucunun kendi diskine alınan sıkıştırılmış dosya, disk arızasında da hesap kapanmasında da seninle birlikte gider. Sağlıklı kurgu üç yerdedir: sunucuda son birkaç günlük hızlı geri dönüş kopyası, farklı bir sağlayıcıda uzak kopya ve senin fiziksel erişimindeki bir soğuk kopya. Buna sık sık '3-2-1' denir ve klişe olması yanlış olduğu anlamına gelmez.

Bir de kimsenin sevmediği ama her şeyi belirleyen adım var: geri yükleme tatbikatı. Yedeğin var olduğu değil, geri döndüğü önemlidir. Üç ayda bir, boş bir alt alan adına arşivi açıp paneli ayağa kaldır, birkaç siparişi kontrol et, kayıp veri var mı diye bak. Bu yarım saatlik alışkanlık, bir felaket gününde işletmenin hayatta kalıp kalmamasını belirler. Tatbikat yapılmamış yedek, sadece iyi niyetle dolu bir dosyadır.

Arşiv ile hız ilişkisi: rapor ekranın neden her ay biraz daha yavaşlıyor?

Panelin açılış süresi arttıkça ilk suçlanan hep sunucu olur. Oysa çoğu durumda sebep basittir: raporlar bütün geçmişi tarıyordur. Yüz binlerce satırın içinde 'bu ayın cirosu' sorusunu sormak, arşivlenmiş bir yapıda milisaniyelik bir iş, arşivlenmemiş bir yapıda saniyelerce süren bir taramadır. Çözüm daha büyük sunucu değil, veriyi doğru bölmek ve özet tablolar üretmektir.

Pratik reçete şu: günlük ciro, ürün bazlı satış adedi ve tedarikçi maliyeti gibi rakamları her gece bir özet tabloya yaz. Raporlar bu özetten okusun, ham satırlara sadece detay istendiğinde insin. Böylece geçmişini kaybetmeden hızlı kalırsın. İyi bir dijital ürün satış scripti zaten bu mantığı hazır sunar; sen sadece hangi metriğin özetlenmesi gerektiğine karar verirsin.

Uygulama takvimi: bir haftada kurulabilecek gerçekçi arşiv düzeni

Bu işi büyük bir proje gibi düşünmek erteletir. Oysa küçük adımlarla bir haftada oturur. Birinci gün envanter: hangi tablo ne kadar yer kaplıyor. İkinci gün politika: yukarıdaki tabloyu kendi işine göre uyarla. Üçüncü gün rotasyon: log temizliği ve arşiv tablolarına taşıma işini zamanlanmış göreve bağla. Dördüncü gün konum: uzak ve soğuk kopyaları ayarla. Beşinci gün tatbikat: geri yüklemeyi dene ve sonucu yaz.

Kalan iki gün belgeleme içindir. Kim neyi ne zaman siliyor, arşiv nerede, şifreler kimde, geri yükleme adımları ne? Bunu tek sayfaya yaz ve ekibinle paylaş. Ekip büyüdükçe bu sayfa, kurumsallaşmanın ilk tuğlası olur. Arşivleme bir yazılım özelliği değil, bir işletme alışkanlığıdır; yazılım sadece o alışkanlığı kolay hâle getirir. Özelliklerin tamamını özellikler bölümünde, paket farklarını ise fiyat tablosunda karşılaştırabilirsin.

Arşivleme, büyüdüğünde değil bugün küçükken kurulduğunda ucuz olan işlerden biridir. Beş yüz siparişlik bir panelde politika yazmak yarım gün sürer; elli bin siparişte aynı iş haftalar alır ve risk taşır. Kendi verinin kaç katmanda durduğunu, hangi kaydın ne kadar yaşadığını ve bir felaket gününde neyi ne kadar sürede geri getirebileceğini bilmek, işletme sahibi olmanın sessiz ama en değerli konfor alanıdır. Bu düzenin tek panelde nasıl göründüğünü görmek istersen canlı demo üzerinden sipariş geçmişi, log ekranı ve arşiv görünümlerini kendi ellerinle gezebilirsin.