Teknik

Yedeğin Her Gece Alınıyor Ama Geri Dönmüyor: E-Pin Scripti Kullananların Yıllarca Fark Etmediği Geri Dönüş Provası Meselesi

E-pin scripti kullanan işletmelerin yedekleri neden kriz anında açılmıyor? Geri dönüş provası, RTO/RPO ve adım adım tatbikat senaryosu bu rehberde.

Yedeğin Her Gece Alınıyor Ama Geri Dönmüyor: E-Pin Scripti Kullananların Yıllarca Fark Etmediği Geri Dönüş Provası Meselesi

Çoğu kişi yedeklemeyi bir kutucuk sanır. Panelde "otomatik yedek: açık" yazısını görür, cron satırında gece 04.00 kaydını fark eder ve içi rahat eder. Oysa e-pin satan bir işletmede yedeklemenin değeri, alınmasıyla değil geri dönebilmesiyle ölçülür. Elinde 40 GB'lık bir arşiv olabilir; o arşivi açtığında tablolar yarım geliyorsa, karakter seti bozuluyorsa ya da dosyalar var veritabanı yoksa, senin yedeğin yok demektir. Sadece yedek isminde bir dosyan var.

Bu yazıda sana kimsenin anlatmak istemediği kısmı anlatacağım: geri dönüş provası. Yani yedeği gerçekten bir yere kurup, sitenin ayağa kalktığını, siparişlerin göründüğünü, bayi bakiyesinin doğru olduğunu kendi gözünle doğrulama alışkanlığı. Kullandığın e-pin satış scripti ne kadar iyi yazılmış olursa olsun, provası yapılmamış bir yedek seni kriz gecesinde yalnız bırakır. Birkaç saatlik bir tatbikat, ileride yaşayacağın 12 saatlik kesintinin yerine geçer.

%68hiç geri dönüş denemesi yapılmamış yedek
11 saprovasız işletmede ortalama toparlanma süresi
24 dkprovalı işletmede ortalama toparlanma
3 kopyasağlıklı yedek kuralının alt sınırı

Yedek Almak mı, Geri Dönebilmek mi? Bunlar Aynı Şey Değil

Yedek almak bir kopyalama işlemidir; geri dönmek ise bir kurtarma sürecidir. Kopyalama tek adımdan oluşur, kurtarma ise on adımdan: sunucu hazırlamak, PHP sürümünü eşlemek, veritabanını oluşturmak, dump'ı içe almak, yapılandırma dosyasındaki bağlantı bilgilerini düzeltmek, dosya izinlerini onarmak, cron'ları yeniden tanımlamak, ödeme geçidi anahtarlarını yerine koymak, alan adını yönlendirmek, son olarak sipariş akışını tek tek denemek. Bu on adımın herhangi birinde eksik bir bilgi varsa süreç tıkanır.

İşin can sıkıcı tarafı şu: bu eksikleri ancak denerken görürsün. Panelde yedek dosyasının boyutuna bakarak anlaman mümkün değil. Bu yüzden ciddi bir dijital ürün satış scripti işleten herkesin yılda en az iki kez, tercihen çeyreklik olarak provasını yapması gerekir. Prova, kurtarma sürecini kâğıttan gerçeğe çevirir.

Sadece Dosya Yedeği Aldığın İçin mi Rahatsın? Asıl Tehlike Tam Orada

Pek çok işletme sahibi FTP üzerinden tüm klasörü indirir ve işi bitmiş sayar. Ama e-pin işinde değerin neredeyse tamamı veritabanındadır: kullanıcılar, bakiyeler, sipariş kayıtları, teslim edilmiş kod stokları, bayi iskontoları, kupon geçmişi. Dosyalar zaten yazılım sağlayıcından yeniden temin edilebilir; oysa dün akşam satılan 300 kodun kime gittiği bilgisi hiçbir yerden geri gelmez.

Bir diğer sessiz tehlike, yedeğin canlı sunucunun içinde durmasıdır. Aynı diskte tutulan yedek, disk arızasında, fidye yazılımında veya hesabın askıya alınmasında birlikte gider. En az bir kopya farklı sağlayıcıda, bir kopya da senin erişimindeki yerel bir diskte olmalı. Bu, klasik üç kopya mantığının e-pin işine uyarlanmış hâlidir.

Yedek türüNeyi kurtarırZayıf noktasıÖnerilen sıklık
Tam yedek (dosya + veritabanı)Sitenin tamamıBoyut büyür, süre uzarHaftada 1
Yalnızca veritabanı dumpSipariş, bakiye, stokDosya/tema kaybıGünde 2
Artımlı dosya yedeğiDeğişen dosyalarZincir kopunca işe yaramazGünlük
Binary log / transaction logSon dakikaya kadar veriKurulum bilgisi gerektirirSürekli
Anlık sunucu görüntüsüTüm sistem, hızlı dönüşSağlayıcıya bağımlıHaftada 1

Provasız Yedek Neden Gece Yarısı Seni Yalnız Bırakır?

Kriz anı hiçbir zaman sakin bir sabah olmaz. Genellikle kampanya gecesinde, sipariş yoğunluğu tepedeyken bir güncelleme ters gider veya sunucu yanıt vermez. O dakikada iki şeyin tükenir: zaman ve soğukkanlılık. Provasını yapmadığın bir kurtarmayı, panik hâlindeyken ilk kez denemek, en kötü koşulda en zor işi yapmaya çalışmaktır.

Provanın gerçek faydası da burada. Prova sana bir sıra verir. Hangi dosyayı nereden indireceğini, hangi komutu hangi sırayla yazacağını, yapılandırma dosyasında hangi satırı değiştireceğini önceden bilirsin. Bu bilgi kafanda değil, yazılı bir kurtarma kartında durur. O kart tek sayfa olsa bile kesintini saatlerden dakikalara indirir.

Geri Dönüş Provasını Nasıl Kurgularsın? Adım Adım Senaryo

Prova için canlı siteye dokunman gerekmez, dokunmaman gerekir. İhtiyacın olan tek şey ayrı bir alt alan adı veya ucuz bir test hesabı. Oraya dünün yedeğini kurar, siteyi arama motorlarına kapatır ve ödeme geçitlerini test anahtarlarıyla çalıştırırsın. Amaç satış yapmak değil, akışın uçtan uca yaşadığını görmek.

Provada mutlaka bakman gereken noktalar şunlar: giriş yapılabiliyor mu, bayi bakiyesi doğru mu, bir ürün siparişi oluşturulabiliyor mu, otomatik teslim modülü stoktan kod çekiyor mu, fatura ve bildirim e-postası üretiliyor mu, admin raporlarındaki toplamlar canlıdaki toplamlarla tutuyor mu. Bu altı kontrolü geçen bir yedek gerçekten yedektir. Geçmeyen yedek, en iyimser ifadeyle bir umuttur.

Başarısız geri dönüş denemelerinde asıl sebep dağılımı

  • Eksik veya bozuk veritabanı dump 45%
  • Yapılandırma ve anahtar bilgisi kayıp 25%
  • Sürüm/uyumluluk farkı 20%
  • Dosya izinleri ve cron eksikleri 10%

RTO ve RPO: Kaç Dakika Kaybetmeyi Gerçekten Kabul Ediyorsun?

İki basit soruyla başla. Birincisi: sistem çöktüğünde en fazla ne kadar süre kapalı kalabilirim? Buna kurtarma süresi hedefi denir. İkincisi: en fazla kaç dakikalık veriyi kaybetmeyi göze alabilirim? Buna da veri kaybı toleransı denir. Günde 200 sipariş alan bir işletmede 6 saatlik veri kaybı, kırk elli siparişin kaybolması anlamına gelir; bu da geri ödeme, itibar zedelenmesi ve bayi güveninin sarsılmasıdır.

Bu iki sayıyı belirlediğin an yedekleme planın kendiliğinden şekillenir. Veri kaybı toleransın 15 dakikaysa gecelik dump yetmez, işlem kayıtlarını da tutman gerekir. Kurtarma süresi hedefin 30 dakikaysa yedeği bulup indirmeye çalışmak yerine hazır bekleyen bir ikinci ortamın olması gerekir. Hedefsiz yedekleme, ölçüsüz dikilen elbise gibidir.

Kurtarma kartını bir sayfada tut

Sunucu erişim bilgileri, veritabanı adı, PHP sürümü, cron satırları ve ödeme anahtarlarının nerede saklandığı tek sayfada yazılı olsun. Kriz anında aradığın şey bilgi değil, sıra olacak.

İyi Bir E-Pin Yazılımı Bu Provayı Nasıl Kolaylaştırır?

Bir e-pin satış yazılımı kurtarma dostu tasarlanabilir. Yapılandırmanın tek dosyada toplanması, kurulum sihirbazının mevcut veritabanını tanıması, e-pin stoklarının şifreli ama taşınabilir biçimde tutulması, alan adı değiştiğinde lisansın kilitlenmemesi; bunların hepsi provayı on dakikalık bir işe indirir. Tersine, ayarları veritabanının on ayrı tablosuna dağıtan bir epin yazılım her taşımada seni saatlerce oyalar.

Pinova'yı bu gözle inceleyebilirsin. Kurulum ve yapılandırma tarafı taşınabilirlik düşünülerek kurgulandığı için yedeği yeni bir ortama kurup denemek özel bir uzmanlık gerektirmez. Özellikler bölümünde yönetim ve stok yapısını, fiyat tarafında ise lisans kapsamını görebilirsin. Ama kararı verirken tek ölçütün şu olsun: bu yazılımın yedeğini ben tek başıma geri getirebilir miyim?

Prova kontrol adımıNasıl doğrularsınGeçti sayılma ölçütü
Veritabanı içe almaDump'ı test ortamına yükleHata satırı yok, tablo sayısı eşit
Türkçe karakterÜrün ve sipariş notlarını açBozuk karakter görünmüyor
Kullanıcı girişiBir bayi hesabıyla giriş yapOturum açılıyor, bakiye doğru
Sipariş akışıTest anahtarıyla sipariş oluşturSipariş kaydı ve teslim üretiliyor
Otomatik teslimStoklu bir ürünü deneKod düşüyor, stok azalıyor
BildirimlerE-posta kuyruğunu izleMesaj üretiliyor ve gidiyor
Zamanlanmış görevlerCron listesini karşılaştırTüm görevler tanımlı
Rapor tutarlılığıGünlük ciro toplamını kıyaslaFark yok veya açıklanabilir

Kurtarması kolay bir altyapıyla çalış

Yedeği geri getirmek bir gecelik kahramanlık değil, rutin bir işlem olmalı. Pinova'nın kurulum, stok ve lisans yapısını kendi senaryonla test et.

Geri dönüş provasını ne sıklıkla yapmalıyım?

Küçük ölçekli bir işletmede altı ayda bir yeterli olabilir; günde yüzlerce sipariş alıyorsan çeyreklik yapman daha sağlıklı. Ayrıca sunucu değişimi, büyük sürüm güncellemesi veya ödeme geçidi eklemesi sonrası mutlaka bir prova yap.

Provayı canlı sitenin üzerinde yapabilir miyim?

Yapmamalısın. Ayrı bir alt alan adı veya ucuz bir test hesabı kullan, arama motorlarına kapat ve ödeme geçitlerini test anahtarlarıyla çalıştır. Provanın amacı satış değil, akışın çalıştığını görmektir.

Sadece panelin otomatik yedeği bana yeter mi?

Tek başına yetmez. Otomatik yedek aynı sunucuda duruyorsa disk arızası, fidye yazılımı veya hesap askıya alınmasında birlikte kaybolur. En az bir kopya farklı bir sağlayıcıda, bir kopya da senin elinde olsun.

Veritabanı çok büyüdü, yedek almak yavaşladı. Ne yapmalıyım?

Log ve oturum tablolarını arşivle, eski kayıtları ayrı tablolara taşı ve tam yedeği haftalık, veritabanı dump'ını günlük planla. Böylece hem yedek süresi kısalır hem de veri kaybı toleransın daralır.

Yedekleme bir kutucuk değil, bir alışkanlıktır; geri dönüş provası da bu alışkanlığın tek gerçek kanıtıdır. Bir öğleden sonranı ayır, dünün yedeğini bir test alanına kur ve sipariş akışını uçtan uca dene. Kurtarması kolay bir altyapının nasıl göründüğünü merak ediyorsan canlı demo üzerinden panel yapısını gez, sonra kendi kurtarma kartını tek sayfada yazmaya başla.

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