Bir e-pin sitesi işletiyorsanız, en değerli varlığınız aslında ödeme sayfanız ya da tasarımınız değil — veritabanınızdır. Müşteri bakiyeleri, tamamlanmış siparişler, bayi komisyon hesapları ve tedarikçi API anahtarları tek bir dosyada toplu halde durur. Sunucu çökmesi, yanlış bir DELETE sorgusu ya da kötü niyetli bir erişim; saniyeler içinde aylarca biriktirdiğiniz güveni yok edebilir. Peki bu riski gerçekten ne kadar ciddiye alıyorsunuz?
E-Pin Sisteminizin Veritabanı Neden Bu Kadar Kritik?
Normal bir e-ticaret sitesinde veritabanı kaybı can sıkıcıdır ama telafi edilebilir; ürünleri tekrar yükler, siparişleri müşteriyle teyit edersiniz. E-pin ve dijital ürün satışında durum farklıdır, çünkü elinizdeki veri anlık ve geri döndürülemez işlemlerden oluşur.
- Cüzdan bakiyeleri: Müşterinin yüklediği bakiye kaydı kaybolursa, elinizde "bu kişi ne kadar parası olduğunu" ispatlayacak ikinci bir kaynak kalmaz.
- Teslim edilmiş kodlar: Hangi pin'in hangi siparişe, hangi tedarikçiden geldiği bilgisi kaybolursa, aynı kodun iki kez satılıp satılmadığını asla bilemezsiniz.
- Bayi komisyon geçmişi: Çok seviyeli bayi sisteminde kim kime ne kadar borçlu, bu tablo olmadan çözülemez bir kaos haline gelir.
- Tedarikçi API anahtarları: Turkpin/Pinabi gibi entegrasyonların kimlik bilgileri veritabanında tutulur; sızarsa üçüncü şahıslar sizin adınıza sipariş açabilir.
Kısacası veritabanı, e-pin scriptinde "yedek alınırsa iyi olur" seviyesinde bir detay değil, işin devamlılığının kendisidir.
Yedek Almadan Önce Hangi Tabloları Önceliklendirmelisiniz?
Küçük ölçekli sitelerde genelde "tüm veritabanını yedekle, iş bitsin" mantığı işler ve bu doğru bir başlangıçtır. Ancak trafik ve sipariş hacmi büyüdükçe, tek bir dump dosyasının boyutu şişer ve geri yükleme süresi uzar. Bu noktada tabloları önem sırasına göre ayırmak işinizi kolaylaştırır.
- Birinci öncelik: Kullanıcı hesapları, cüzdan/bakiye hareketleri, sipariş tablosu — bunlar anlık, geri alınamaz finansal kayıtlardır.
- İkinci öncelik: Bayi hiyerarşisi ve komisyon oranları, ödeme sağlayıcı işlem kayıtları (PayTR/Shopier/havale bildirimleri).
- Üçüncü öncelik: Ürün kataloğu, kategori ve stok tabloları — bunlar genelde tedarikçi API'sinden yeniden çekilebilir, dolayısıyla kayıp durumunda geri kazanılması daha kolaydır.
- Ayrı tutulması gereken: API anahtarları ve ödeme gizli anahtarları — bu tablo hem daha sık hem de ayrı bir şifreli kanaldan yedeklenmelidir, çünkü sızıntı riski en yüksek olan katman burasıdır.
Bu ayrım, felaket anında hangi tabloyu önce geri yükleyeceğinizi de netleştirir: önce parayı ve siparişleri kurtarırsınız, katalog ikinci plana kalabilir.
Otomatik mi Elle mi? Yedekleme Sıklığını Belirleyen Şey Nedir?
"Haftada bir yedek alıyorum" cümlesi kulağa yeterli gelebilir, ama bir e-pin sitesinde bir gün içinde yüzlerce sipariş geçebilir. Yedekleme sıklığını belirleyen tek şey takvim değil, sizin işlem hacminizdir. Günde 50'den fazla sipariş alan bir site için haftalık yedek, aradaki tüm günün siparişlerini riske atmak demektir.
| Kriter | Manuel / Elle | Pinova ile |
|---|---|---|
| Yedekleme sıklığı | Hatırladıkça, genelde haftalık ya da aylık | Günlük otomatik zamanlanmış yedek |
| İnsan hatası riski | Yüksek — "bu ay unutuldu" senaryosu yaygın | Cron tabanlı, insan müdahalesi gerektirmez |
| Kritik tabloların ayrılması | Elle SQL dump yazmak gerekir | Bakiye/sipariş tabloları önceliklendirilmiş yapı |
| Geri yükleme süresi | Dosya bulma + sunucu erişimi + manuel restore, saatler sürebilir | Panel üzerinden hızlı geri yükleme |
| Sızıntı sonrası iz sürme | Log tutulmadıysa neredeyse imkansız | Erişim ve işlem logları ayrı tutulur |
Buradaki fark aslında disiplin farkıdır: elle yedekleme, sizin en yoğun olduğunuz günlerde ihmal edilme ihtimali en yüksek olan iştir — tam da yedeğe en çok ihtiyaç duyacağınız dönemde.
Yedekler Nerede Saklanmalı, Sunucunun Kendisi Yeterli mi?
Çoğu site sahibinin yaptığı en yaygın hata, yedek dosyasını aynı sunucunun içinde farklı bir klasöre atıp işi bitmiş saymaktır. Oysa sunucunuz hacklenirse, disk arızası yaşarsa ya da barındırma firmanız bir olayla karşılaşırsa, o "yedek" de asıl veriyle birlikte gider.
- Sunucu içi kopya: Hızlı geri yükleme için pratiktir ama tek başına yeterli değildir — sunucu kaybı = yedek kaybı demektir.
- Uzak depolama (offsite): Ayrı bir sunucuya, bulut depolama alanına ya da en azından farklı bir fiziksel konuma otomatik aktarım şarttır.
- Birden fazla nokta: Genel kabul gören "3-2-1" mantığı burada da geçerlidir — verinin en az 3 kopyası, 2 farklı ortamda, 1'i site dışında olmalıdır.
- Erişim kısıtı: Yedek dosyalarının bulunduğu konuma da aynı ciddiyetle erişim kontrolü uygulanmalıdır; şifrelenmemiş bir yedek dosyası, canlı veritabanından farksız bir hedeftir.
Pinova kurulumlarında yedekleme rutini, dosyanın sunucu dışına aktarılmasını da kapsayacak şekilde yapılandırılabilir — böylece "sunucu gitti, yedek de onunla gitti" senaryosunun önüne geçilir.
Ayda bir kez, gerçekten bir yedek dosyasını test ortamına geri yükleyip siparişlerin ve bakiyelerin doğru göründüğünü kontrol edin. Alınan ama hiç açılmamış bir yedek, bozuk olup olmadığını asla bilmediğiniz bir yedektir.
Veritabanı Şifreleme ve Erişim Yetkilendirmesi Nasıl Kurulur?
Yedekleme, güvenliğin sadece yarısıdır. Diğer yarısı, veritabanına kimin, nasıl ve ne yetkiyle eriştiğini kontrol altında tutmaktır. E-pin scriptlerinde bu konu özellikle önemlidir çünkü tek bir sızmış API anahtarı, tedarikçi hesabınızdan yetkisiz sipariş açılmasına kadar gidebilir.
- En az yetki prensibi: Veritabanı kullanıcısına sadece uygulamanın ihtiyaç duyduğu işlemler için yetki verin; yönetim panelinden ayrı, kısıtlı bir kullanıcı tanımlamak sızıntı halinde hasarı sınırlar.
- Hassas alanların şifrelenmesi: Tedarikçi API anahtarları ve ödeme sağlayıcı gizli anahtarları, düz metin yerine şifrelenmiş biçimde saklanmalıdır.
- Ortam değişkenleri: Kimlik bilgilerinin kod içine gömülmesi yerine sunucu tarafında ayrı bir yapılandırma dosyasında tutulması, kaynak kodu sızsa bile anahtarların açıkta kalmamasını sağlar.
- IP kısıtlaması: Veritabanı sunucusuna sadece uygulama sunucunuzun IP'sinden erişime izin vermek, dışarıdan doğrudan bağlantı denemelerini büyük ölçüde eler.
- İki adımlı doğrulama: Yönetim paneline ve sunucu erişimine 2FA eklemek, çalınan bir şifrenin tek başına yeterli olmasını engeller.
Bu ayarların çoğu bir kere kurulduktan sonra günlük operasyonu etkilemez; sadece "bir şeyler ters giderse" diye orada durur ve genelde tam da ihtiyaç duyduğunuz an fark edilir.
Bir Sızıntı ya da Veri Kaybı Anında İlk 10 Dakikada Ne Yapmalısınız?
En iyi hazırlık bile bir olayı tamamen engelleyemeyebilir; önemli olan o anda panikle rastgele hareket etmemektir. Önceden yazılmış basit bir kontrol listesi, kaybedilen dakikaların sayısını doğrudan etkiler.
- 1. Erişimi kısıtlayın: Şüpheli aktivite fark ettiğiniz anda, önce dış erişimi (özellikle API anahtarlarını) geçici olarak devre dışı bırakın.
- 2. Son sağlam yedeği belirleyin: Hangi yedek dosyasının olay öncesine ait olduğunu netleştirin, üzerine yazmadan bir kopyasını ayırın.
- 3. Anahtarları yenileyin: Tedarikçi ve ödeme sağlayıcı API anahtarlarını, veritabanı şifresini ve panel yönetici parolasını değiştirin.
- 4. Logları inceleyin: Erişim loglarından olayın hangi saatte, hangi IP'den başladığını tespit etmeye çalışın.
- 5. Müşterilere ne zaman ve nasıl bilgi vereceğinize karar verin: Bakiye ya da sipariş verisi etkilendiyse, şeffaf ama sakin bir bildirim güveni korumanın en hızlı yoludur.
Bu adımların önceden bir doküman haline getirilmiş olması, olay anında "şimdi ne yapacağız" tartışmasıyla vakit kaybetmenizi önler.
Bu Ayarların Hepsini Tek Tek Kurmak Zorunda mısınız?
Pinova ile teslim edilen scriptlerde otomatik günlük yedekleme, kısıtlı veritabanı erişimi ve API anahtarı şifreleme kurulumdan itibaren hazır gelir; siz sadece uygulama ile ilgilenirsiniz.
E-pin scripti veritabanı yedeği ne kadar sıklıkla alınmalı?
Günlük işlem hacmi yüksekse (günde onlarca-yüzlerce sipariş) günlük otomatik yedek asgari standarttır; düşük hacimli sitelerde bile haftalık elle yedek yeterli sayılmamalıdır çünkü aradaki gün kaybı geri döndürülemez.
Yedek dosyası sunucunun kendisinde tutulursa yeterli mi?
Hayır. Sunucu içi kopya hızlı geri yükleme için işe yarar ama sunucu kaybı, saldırısı ya da disk arızası durumunda o yedek de kaybolur. Yedeğin en az bir kopyası mutlaka sunucu dışında (offsite) tutulmalıdır.
API anahtarları veritabanında düz metin olarak mı saklanmalı?
Hayır, tedarikçi ve ödeme sağlayıcı gibi hassas anahtarlar şifrelenmiş biçimde saklanmalı ve mümkünse kod içine gömülmek yerine ayrı bir yapılandırma katmanında tutulmalıdır.
Pinova'da yedekleme ve güvenlik ayarları kurulum sonrası mı yapılıyor?
Hayır, otomatik günlük yedekleme ve temel erişim güvenliği kurulumla birlikte hazır gelir; ek olarak API anahtarı şifreleme ve IP kısıtlaması gibi ileri seviye ayarlar panel üzerinden yapılandırılabilir.