Epin Satış Scriptinde Kimsenin Anlatmadığı Felaket Senaryosu: Yedeğin Var Sanıyorsun Ama O Dosyanın Açılmadığını Öğrenmen 40 Dakika Sürecek

Çoğu işletme sahibi yedekleme konusunu "hosting firması zaten yedek alıyor" cümlesiyle kapatır. Kulağa mantıklı gelir; panelde bir yedek sekmesi vardır, tarih yazar, dosya boyutu görünür. Sorun şu ki o dosyanın gerçekten açılıp açılmadığını, veritabanının tutarlı bir anda alındığını ve kod ile veri sürümlerinin birbirine uyduğunu hiç kimse denemez. Yedek diye bilinen şey aslında bir umuttur.

Bu umudun bedeli e-pin işinde çok daha yüksek. Sen fiziksel ürün satmıyorsun; sattığın şey doğrudan veritabanında duran kodlar, bakiyeler ve sipariş kayıtları. Veritabanı bozulduğunda elinde satacak bir şey kalmaz, hangi müşteriye hangi kodu teslim ettiğini de kanıtlayamazsın. Bu yazıda bir epin satış scripti için gerçekten işe yarayan yedekleme ve kurtarma planını, ölçülebilir hedeflerle ve tatbikat mantığıyla kuruyoruz.

Veri Kaybı Gerçekten Nereden Geliyor, Hacker'dan mı?

Zihnimizde felaket senaryosu hep dramatiktir: bir saldırgan sunucuya girer, her şeyi siler. Gerçek hayatta ise en sık sebep çok daha sıkıcı. Yanlış tabloda çalıştırılan bir güncelleme sorgusu, eklenti kurulumu sırasında üzerine yazılan bir dosya, tema güncellemesinde kaybolan özelleştirme, panelden yanlış kategoriye uygulanan toplu fiyat değişimi. İnsan hatası, tek başına tüm diğer sebeplerin toplamına yakın bir pay tutuyor.

Bunun pratik sonucu şu: planını sadece "sunucu patlarsa" senaryosuna göre kurarsan hazırlıksız kalırsın. Çünkü asıl ihtiyacın çoğu zaman tüm sistemi değil, üç saat önceki tek bir tablonun halini geri getirmek olacak. Nokta geri dönüş yapamayan bir yedek stratejisi, olay anında seni tüm siteyi geriye alıp son üç saatlik siparişleri feda etmeye zorlar.

Neyi Yedekliyorsun? Listen Muhtemelen Eksik

Yedek denince akla veritabanı gelir ve orada durulur. Ama bir e-pin satış scripti tek bir parçadan oluşmuyor. Veritabanının yanında yükleme dosyaları, ürün görselleri, fatura çıktıları, ödeme geçidi yapılandırması, ortam değişkenleri, şifreleme anahtarları, cron tanımları ve web sunucusu kuralları var. Bunların biri eksik olduğunda geri dönüş yarım kalır: site açılır ama ödeme çalışmaz, ya da ürünler görünür ama görseller kırıktır.

Özellikle şifreleme anahtarı konusu ölümcül. Kodları veritabanında şifreli tutuyorsan ve anahtar dosyasını yedeklememişsen, veritabanını geri yüklemek hiçbir işe yaramaz; elinde okunamayan bir kod yığını olur. Aynı şekilde ödeme geçidi ayarlarının yedeği yoksa kurtarma sonrası ilk siparişler sessizce başarısız olur.

3-2-1 Kuralı Neden Hâlâ Tartışılmaz?

Kural basit: verinin en az üç kopyası olsun, bunlar en az iki farklı ortamda dursun ve en az bir kopya fiziksel olarak başka bir yerde bulunsun. E-pin işine uyarlaması şöyle: canlı veritabanı birinci kopya, sunucu üzerindeki otomatik yedek ikinci kopya, farklı sağlayıcıda tutulan uzak nesne depolaması üçüncü kopya. Üçüncü kopyayı aynı barındırma hesabının içinde tutmak kuralı ihlal eder; hesap askıya alındığında yedek de erişilemez hale gelir.

Bir de sürüm mantığı gerekir. Tek dosyanın üzerine her gece yazan bir sistem, bozulmayı fark etmen üç gün sürdüğünde işe yaramaz; çünkü bozuk hali üç kez üzerine yazmış olur. Bu yüzden günlük, haftalık ve aylık olmak üzere dönen bir saklama takvimi kurulmalı. Kısa vadeli yedekler sık ve çok, uzun vadeli yedekler seyrek ve az.

RPO ve RTO Hedefini Yazmadan Plan Kurulur mu?

İki sayı belirlemeden yedekleme konuşmak boşa kürek çekmektir. RPO, kabul edebileceğin veri kaybı penceresidir: "En fazla 15 dakikalık sipariş kaybını göze alırım" gibi. RTO ise ayakta olmaya kadar geçen süredir: "En geç 60 dakikada satışa dönmeliyim." Bu iki sayıyı yazdığın anda hangi araçlara ihtiyacın olduğu kendiliğinden ortaya çıkar. 15 dakikalık RPO hedefi varsa gece bir kez alınan yedek yeterli değildir; artımlı işlem kaydı gerekir.

Ayrıca bu hedefler ticari kararlarını da şekillendirir. Yoğun kampanya gününde RPO'yu daraltmak, sakin dönemde gevşetmek makul bir seçimdir. Bir dijital ürün satış yazılımı etrafında kurulan operasyonda yedekleme sıklığı, ciro yoğunluğuyla birlikte düşünülmelidir.

Kurtarma Anında Sırayı Bilmiyorsan Süre Üçe Katlanır

Olay anında insan panikler; panikte doğaçlama yapılır ve doğaçlama veri kaybettirir. Bu yüzden plan sadece yedek almakla bitmez, yazılı bir kurtarma sırası içerir. Önce bakım moduna al, sonra mevcut bozuk halin bir kopyasını çek, sonra hangi yedeğe döneceğine karar ver, ardından veritabanını ve dosyaları geri yükle, yapılandırmayı doğrula, ödeme geçidini test et, cron'ları kontrol et ve en son bakım modunu kapat.

Bozuk halin kopyasını çekme adımı en çok atlanan ve en çok pişmanlık yaratan adımdır. Geri yükleme sırasında bir şey ters gittiğinde, hiç değilse başladığın noktaya dönebilmen gerekir. Ayrıca hangi siparişlerin arada kaldığını tespit edip müşteriye elle teslimat yapmak için o kopyaya ihtiyacın olacak.

Pinova Bu Süreçte Yükü Nasıl Hafifletiyor?

Pinova, e-pin satan işletmelerin kullandığı lisanslı bir e-pin yazılımı. Yedekleme tarafındaki katkısı sihirli bir düğme değil, sürecin öngörülebilir olması. Yapılandırma ayrı tutulur, şifreleme anahtarı web kök dizininin dışında durur, veri şeması sürüm kayıtlarıyla taşınır ve kurtarma sonrası bütünlük kontrolü yapılabilecek biçimde tasarlanır. Böylece geri yükleme, her seferinde yeniden keşfedilen bir bulmaca olmaktan çıkar, tekrarlanabilir bir işlem haline gelir. Özellikler bölümünde altyapı yaklaşımını, fiyat sayfasında paket kapsamını görebilirsin.

Yedekleme, işlerin iyi gittiği günlerde en kolay ertelenen, kötü gittiği günlerde ise tek çare olan iştir. Yukarıdaki katman tablosunu kendi kurulumuna uyarla, bir ayda bir tatbikat takvimi oluştur ve bu kontrolleri kalıcı bir alışkanlığa çevir. Altyapının bu süreci ne kadar kolaylaştırdığını görmek istersen canlı demo üzerinde panel yapısını gez, ardından kendi planını kâğıda dök.