Teknik

E-pin Yazılımında Veritabanı Yedekleme Otomasyonu: Bir Gecede Her Şeyi Kaybetmemenin Yolu

E-pin sitenizin veritabanı bir anda silinirse ne olur? Manuel yedeklemenin neden yetmediğini ve Pinova'nın otomatik yedekleme mantığını anlatıyoruz.

E-pin Yazılımında Veritabanı Yedekleme Otomasyonu: Bir Gecede Her Şeyi Kaybetmemenin Yolu

Bir e-pin ve dijital ürün satış sitesinde veritabanı; siparişleri, bakiyeleri, teslim edilmiş kodları, bayi hesaplarını ve tüm finansal geçmişi taşır. Sunucu sağlayıcınızda yaşanacak tek bir disk arızası, yanlışlıkla çalıştırılan bir komut ya da kötü niyetli bir saldırı, yıllarca biriktirdiğiniz bu veriyi dakikalar içinde silebilir. Peki elinizde gerçekten güvenilir bir yedek var mı, yoksa "büyük ihtimalle sorun olmaz" diyerek mi yaşıyorsunuz?

Bir e-pin veritabanı neden bankanızdan daha kritik olabilir?

Fiziksel bir mağaza soyulduğunda kasadaki para gider, ama müşteri kayıtları ve geçmiş işlemler genelde defterlerde durur. E-pin işinde durum tam tersidir: paranız zaten dijital, ürününüz zaten dijital, müşteri ilişkiniz zaten dijital. Veritabanınız kaybolduğunda kasadan çok daha fazlası gider.

  • Bakiye bilgileri: Bayilerinizin ve müşterilerinizin cüzdanında duran her kuruş, sadece veritabanı satırlarında var olur.
  • Teslim edilmiş kodlar: Hangi müşteriye hangi kodun verildiğinin kaydı olmazsa, aynı kodun tekrar satılıp satılmadığını bile bilemezsiniz.
  • Sipariş ve ödeme geçmişi: Bir itiraz ya da chargeback durumunda elinizde kanıt kalmaz.
  • Bayi hiyerarşisi ve komisyon oranları: Çok seviyeli bayi sisteminde bu yapı yeniden elle kurulacak kadar basit değildir.

Kısacası, e-pin sitesinde veritabanı kaybı fiziksel bir dükkanın yanmasından farksızdır — sadece sigortası çoğu zaman yoktur.

Manuel yedekleme sizi neden er ya da geç yüzüstü bırakır?

"Ara sıra phpMyAdmin'den export alıyorum" cümlesini çok duyarız. Sorun şu ki bu yaklaşım insan hafızasına ve disipline bağlıdır, ikisi de kriz anında en zayıf halkadır. Bir satıcı yoğun kampanya haftasında, tam da veritabanının en çok değiştiği günlerde, "yedek almayı unuttum" diyebilir.

Manuel yedeklemenin tipik başarısızlık noktaları şunlardır:

  • Yedek dosyası aynı sunucuda, aynı diskte tutulur — disk çökerse yedek de gider.
  • Yedekleme sıklığı düzensizdir; son yedek iki hafta önceki hâli gösterebilir.
  • Büyüyen veritabanında manuel export zamanla dakikalarca sürer ve site trafiğini yavaşlatır.
  • Kimse yedeğin gerçekten açılıp açılmadığını test etmez, sorun tam ihtiyaç anında ortaya çıkar.

Bu liste bir ihtimal değil, gerçek bir örüntüdür: pek çok site sahibi felaketi yaşadıktan sonra otomasyona geçer, öncesinde değil.

KriterManuel / EllePinova ile
Yedekleme sıklığıKişinin hatırlamasına bağlı, düzensizZamanlanmış, günlük/saatlik otomatik
Yedeğin saklandığı yerGenelde aynı sunucu/diskSunucu dışı depolama desteklenir
Kod ve bakiye tutarlılığıİşlem sırasında alınırsa veri bozulabilirTutarlı anlık görüntü ile alınır
Geri yükleme süresiElle SQL içe aktarma, saatler sürebilirPanel üzerinden hızlı geri yükleme
Kritik anda erişimKişi tatildeyse yedek de erişilemez olabilirSistem otomatik, kişiye bağımlı değil

Otomatik yedekleme perde arkasında nasıl çalışır?

Otomasyon dediğimizde karmaşık bir şey düşünmenize gerek yok; temelde üç basit adım tekrar tekrar, insan müdahalesi olmadan çalışır.

  • Zamanlayıcı (cron): Sunucu üzerinde belirli aralıklarla (örneğin her gece 03:00'te) tetiklenen bir görev, veritabanının o anki hâlinin bir kopyasını çıkarır.
  • Tutarlı anlık görüntü: Yedek alınırken aynı anda bir sipariş işleniyorsa, yarım kalmış bir kayıt yedeğe girmemelidir. Doğru yapılandırılmış bir yedekleme, işlemleri kilitleyerek ya da işlem günlüğünü (transaction log) kullanarak tutarlı bir kopya alır.
  • Sıkıştırma ve etiketleme: Dosya sıkıştırılır, tarih-saat damgasıyla adlandırılır ki hangi yedeğin ne zamana ait olduğu bir bakışta anlaşılsın.
  • Sunucu dışına taşıma: En kritik adım budur — yedek, üretim sunucusundan farklı bir konuma (başka bir sunucu, bulut depolama, FTP hedefi) kopyalanır. Aksi hâlde "yedek" kelimesi anlamını yitirir.
  • Eski yedeklerin temizlenmesi: Disk dolmasın diye belirli bir sayıdan eski yedekler otomatik silinir, ama son birkaç kritik nokta (örneğin son 7 gün + son 4 hafta) korunur.

Bu zincirin herhangi bir halkası elle yapılıyorsa, zincir er ya da geç kopar. Otomasyonun değeri tam da burada: hiçbir halkanın insana bağımlı olmamasıdır.

Pratik İpucu

3-2-1 kuralını hedefleyin: verinin en az 3 kopyası, 2 farklı ortamda (örneğin disk + bulut), 1 kopyası da fiziksel olarak farklı bir konumda olsun. E-pin sitesi için bu, sunucudaki günlük yedeğe ek olarak haftalık bir kopyanın ayrı bir depolama alanına gönderilmesi kadar basit bir alışkanlıkla sağlanabilir.

Hangi veriyi, ne sıklıkla, nereye yedeklemelisiniz?

Her tablo aynı önemde değildir, ama bir e-pin sisteminde ayırma lüksünüz de aslında yok — çünkü tablolar birbirine bağımlıdır. Sipariş tablosu olmadan bakiye hareketleri anlamsızlaşır, kod stoğu olmadan teslimat geçmişi eksik kalır. Bu yüzden pratik yaklaşım genelde şudur:

  • Tam veritabanı yedeği: Günde en az bir kez, mümkünse gece trafiğin düşük olduğu saatte.
  • Sık değişen tablolar için ek yedek: Sipariş ve bakiye hareketleri gibi tablolar, kampanya dönemlerinde saatlik yedeklenebilir.
  • Saklama süresi: Son 7-14 günlük günlük yedek + son birkaç aylık haftalık yedek, çoğu senaryoyu (yanlış silme, veri bozulması, saldırı sonrası geri sarma) karşılar.
  • Konum çeşitliliği: Tek bir hedefe güvenmeyin; sunucu sağlayıcınızın kendi yedeği bile tek başına yeterli değildir, çünkü hesabınızla birlikte o da etkilenebilir.

Bir diğer sık atlanan nokta: yalnızca veritabanını değil, ürün görselleri, fatura şablonları ve site ayar dosyalarını da yedekleme kapsamına almak gerekir. Veritabanı geri gelse bile eksik dosyalarla site yarım çalışır.

Yedeğiniz var ama geri yükleyemiyorsanız ne işe yarar?

Yedekleme dünyasında en sinir bozucu an, "yedeğimiz var" güveniyle krizi atlatmaya çalışırken dosyanın bozuk çıkmasıdır. Bir yedek, yalnızca geri yüklenebildiği kanıtlanana kadar teorik bir güvencedir.

  • Yedek dosyasının bütünlüğünü kontrol edin — sıkıştırılmış dosya açılabiliyor mu?
  • Ayda bir kez, test ortamında gerçek bir geri yükleme denemesi yapın. Üretim sitesine dokunmadan, ayrı bir veritabanına içe aktarıp verinin eksiksiz geldiğini doğrulayın.
  • Geri yükleme süresini ölçün. Kriz anında "ne kadar sürer" sorusunun cevabını bilmiyorsanız, panik yönetimi zorlaşır.
  • Geri yükleme adımlarını yazılı hale getirin; bu işi yalnızca bir kişi biliyorsa, o kişi ulaşılamaz olduğunda site de ulaşılamaz kalır.

Test edilmemiş bir yedek, aslında yedek değil, sadece bir varsayımdır.

Pinova'da yedekleme otomasyonu tam olarak nasıl işliyor?

Pinova kendi sunucunuza kurulan bir yazılım olduğu için veritabanınız da fiziksel olarak sizin kontrolünüzdedir — bu hem avantaj hem sorumluluktur. Bu sorumluluğu elle taşımak zorunda kalmamanız için Pinova, zamanlanmış yedekleme görevlerini destekleyecek şekilde tasarlanmıştır: düzenli aralıklarla veritabanının tutarlı bir kopyası alınır, sıkıştırılır ve tercih ettiğiniz saklama noktasına (sunucu dışı depolama dahil) yönlendirilebilir.

Bunun pratikteki karşılığı şudur: bayi bakiyeleri, teslim edilmiş e-pin kodları, sipariş geçmişi ve tedarikçi (Turkpin/Pinabi) entegrasyon kayıtları gibi işin can damarı sayılan veriler, siz hatırlamasanız bile arka planda korunmaya devam eder. Bir sunucu göçü, bir hosting sorunu ya da beklenmedik bir arıza yaşandığında elinizde yakın tarihli, tutarlı bir kopya bulunur — sıfırdan başlamak zorunda kalmazsınız.

Ayrıca Pinova'nın kendi sunucunuzda çalışması, yedekleme stratejinizi tamamen size özel şekilde kurgulayabilmeniz anlamına gelir: isterseniz günlük, isterseniz kampanya dönemlerinde saatlik yedek alacak şekilde ayarlayabilir, yedekleri istediğiniz bulut depolama veya ikinci bir sunucuya taşıyabilirsiniz. Kilitli bir SaaS yapısında olmadığınız için bu esnekliği kimseden izin almadan kurarsınız.

Bir sonraki sunucu çökmesinde hazır olacak mısınız?

Pinova ile e-pin sisteminiz kendi sunucunuzda çalışır ve veritabanı yedekleme sürecinizi tamamen kendi kurallarınıza göre otomatikleştirebilirsiniz — beklemeden bugün kurun.

Veritabanı yedeği ile sunucu yedeği aynı şey mi?

Hayır. Sunucu yedeği (snapshot) tüm sistemi kapsar ama genelde daha seyrek alınır ve büyük dosyalardır. Veritabanı yedeği ise sık değişen sipariş ve bakiye verisine odaklanır, daha küçük ve daha sık alınabilir. İkisini birlikte kullanmak en güvenli yöntemdir.

Yedekleri ne kadar süre saklamalıyım?

Genel kabul gören yaklaşım son 7-14 günü günlük, son birkaç ayı haftalık olarak saklamaktır. Bu, hem yakın tarihli bir hataya hem de geç fark edilen bir soruna karşı geri dönüş imkanı verir.

Yedekleme site performansını yavaşlatır mı?

Doğru zamanlanmışsa (düşük trafikli saatlerde, tutarlı anlık görüntü yöntemiyle) etkisi minimaldir. Sorun genelde yedeklemenin yoğun saatlerde ve verimsiz şekilde elle çalıştırılmasından kaynaklanır.

Yedeğim varsa neden hâlâ risk altındayım diyorsunuz?

Çünkü test edilmemiş, tek bir konumda tutulan ya da düzensiz alınan bir yedek, kriz anında çalışmama ihtimali taşır. Gerçek güvence; düzenli alınan, sunucu dışında saklanan ve geri yüklemesi test edilmiş yedektir.

Daha Fazlasını Keşfedin

Dijital ürün satışı ve otomasyon üzerine güncel rehberlere göz atın.

Tüm Yazıları Gör →
Bu yazıyı paylaşın
Bu yazıyı beğendiniz mi?
Teşekkürler!
← Tüm yazılar