Ç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.
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ır | Zayıf noktası | Önerilen sıklık |
|---|---|---|---|
| Tam yedek (dosya + veritabanı) | Sitenin tamamı | Boyut büyür, süre uzar | Haftada 1 |
| Yalnızca veritabanı dump | Sipariş, bakiye, stok | Dosya/tema kaybı | Günde 2 |
| Artımlı dosya yedeği | Değişen dosyalar | Zincir kopunca işe yaramaz | Günlük |
| Binary log / transaction log | Son dakikaya kadar veri | Kurulum bilgisi gerektirir | Sü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.
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ın | Geçti sayılma ölçütü |
|---|---|---|
| Veritabanı içe alma | Dump'ı test ortamına yükle | Hata 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şi | Bir bayi hesabıyla giriş yap | Oturum açılıyor, bakiye doğru |
| Sipariş akışı | Test anahtarıyla sipariş oluştur | Sipariş kaydı ve teslim üretiliyor |
| Otomatik teslim | Stoklu bir ürünü dene | Kod düşüyor, stok azalıyor |
| Bildirimler | E-posta kuyruğunu izle | Mesaj üretiliyor ve gidiyor |
| Zamanlanmış görevler | Cron listesini karşılaştır | Tüm görevler tanımlı |
| Rapor tutarlılığı | Günlük ciro toplamını kıyasla | Fark 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.

