E-pin Satış Scriptinde Kimsenin Konuşmadığı Gerçek: Yedeğin Var Sanıyorsun Ama O Dosyayı Geri Yüklemeyi Hiç Denemediysen Yedeğin Yok Demektir

Çoğu işletme sahibi şunu sanır: hosting panelinde "yedek al" butonuna bastıysa ya da sağlayıcı "günlük yedek var" dediyse iş tamamdır. Oysa yedekleme iki yarısı olan bir işlemdir ve insanlar sadece birinci yarısını yapar. İkinci yarı, o yedeği gerçekten geri yükleyip sitenin çalıştığını görmektir. Test edilmemiş yedek, açılıp açılmayacağı bilinmeyen bir paraşüttür; uçaktan atladıktan sonra öğrenmek istemeyeceğin bir şey.

Dijital ürün satan bir vitrinde risk normal bir siteye göre çok daha yüksektir. Çünkü veritabanında sadece içerik yok; teslim edilmemiş stok kodları, kullanıcı bakiyeleri, ödeme kayıtları ve sipariş geçmişi var. Bunların bir kısmını kaybetmek, müşteriye para iade etmek ya da aynı kodu iki kez satmak anlamına gelir. Bu yazıda e-pin satış yazılımı için katmanlı bir yedekleme ve gerçekten işleyen bir geri yükleme stratejisini kuruyoruz.

Yedeklemeyi neden tek parça değil, katman olarak düşünmelisin?

Tek bir yedek türü her senaryoyu kurtarmaz. Sunucu diski bozulduğunda tam sistem görüntüsü işine yarar. Bir personel yanlışlıkla 200 ürünü sildiğinde sadece veritabanının dünkü hali işine yarar. Ödeme modülünü güncellerken bir şey bozulduğunda sadece dosyaların güncelleme öncesi hali işine yarar. Üç farklı sorun, üç farklı kurtarma yolu.

Bu yüzden yedeklemeyi katmanlara ayırırsın. En altta günlük tam yedek durur; sunucu tamamen gittiğinde oradan dönersin. Ortada saatlik veritabanı yedeği durur; veri kaybını dakikalarla sınırlar. En üstte ise işlem kaydı yani veritabanının kendi değişim günlüğü durur; istersen belirli bir saniyeye kadar geri sararsın. Bu üçlü birlikte çalıştığında, hangi tür kaza olursa olsun elinde uygun bir kurtarma yolu bulunur.

Hangi verinin kaybı gerçekten telafi edilemez?

Her tabloyu aynı ciddiyetle korumak gerekmez; ama hangisinin kritik olduğunu bilmek gerekir. Ürün açıklamaları kaybolursa canını sıkar, yeniden yazarsın. Teslim edilmemiş e-pin kodları kaybolursa doğrudan para kaybıdır. Kullanıcı bakiyesi kaybolursa güven kaybıdır ve geri kazanılması en zor olan şeydir. Ödeme kayıtları kaybolursa muhasebe tarafında çözemeyeceğin bir karmaşa doğar.

Bu yüzden kritik tabloları ayrı bir sıklıkta yedeklemek mantıklıdır. Stok, sipariş, bakiye hareketi ve ödeme tablolarını saatlik hatta daha sık dökmek, tüm veritabanını aynı sıklıkta dökmeye göre çok daha hafif olur. Dijital ürün satış scripti tarafında bu ayrımın yapılabilmesi, sunucu kaynağını boşa harcamadan güvenlik seviyesini yükseltir.

Aynı sunucudaki yedek neden yedek sayılmaz?

Yedeği aynı diskte, aynı hesapta ya da aynı sağlayıcının aynı makinesinde tutmak en sık görülen hatadır. Diskte bir sorun çıktığında hem asıl veri hem yedek aynı anda gider. Hesap askıya alındığında ikisine de erişemezsin. Bu yüzden kural nettir: en az üç kopya, en az iki farklı ortam, en az bir tanesi fiziksel olarak başka bir yerde.

Pratikte kurulum şöyle olabilir: birinci kopya sunucunun kendisinde, hızlı geri dönüş için. İkinci kopya farklı bir sağlayıcıdaki nesne depolamada. Üçüncü kopya ise yazıldıktan sonra değiştirilemeyen bir alanda ya da ayda bir indirilen bir arşivde. Bu üçüncü kopya özellikle fidye yazılımı senaryosunda hayat kurtarır; çünkü saldırgan eriştiği her yedeği silmeye çalışır.

Geri yükleme tatbikatını nasıl yapıyorsun?

Asıl iş burada. Ayda bir, yedeğinden tamamen ayrı bir alt alan adına ya da yerel bir ortama geri yükleme yaparsın. Süreyi tutarsın: dosyalar ne kadarda indi, veritabanı ne kadarda yüklendi, site ne kadarda açıldı. Sonra kontrol listesini işaretlersin. Ana sayfa açılıyor mu, giriş yapılabiliyor mu, bir ürün sepete ekleniyor mu, test siparişi teslim ediliyor mu, admin panel raporları geliyor mu.

Bu tatbikat iki şeyi öğretir. Birincisi, gerçek kurtarma süreni öğrenirsin; "bir saatte döneriz" sandığın işin altı saat sürdüğünü kaza anında değil, sakin bir pazar günü keşfedersin. İkincisi, yedeğinde eksik kalan şeyleri görürsün. Çok sık rastlanan eksikler: ortam değişkenleri, ödeme sağlayıcı anahtarları, zamanlanmış görev tanımları, e-posta ayarları ve web sunucusu yapılandırması. Bunların hiçbiri veritabanında değildir ve unutulduğunda site ayağa kalkmaz.

Kaza anında hangi sırayla hareket edeceksin?

Panik anında karar vermek en kötü fikirdir; bu yüzden sıra önceden yazılır. İlk adım durdurmaktır: vitrini bakım moduna al, yeni sipariş ve teslimat akışını kes. İkinci adım kanıt almaktır; bozuk halin bir kopyasını çıkar, çünkü geri yükleme üzerine yazacak ve incelemek için elinde hiçbir şey kalmayacak. Üçüncü adım en uygun yedek noktasını seçmektir; en yenisi değil, bozulmanın başlamasından hemen önceki nokta.

Dördüncü adım geri yüklemeyi canlı ortama değil, önce hazırlık ortamına yapmaktır. Doğrula, sonra devreye al. Beşinci adım mutabakattır: yedek noktası ile kaza anı arasında kalan siparişleri ödeme sağlayıcısı kayıtlarıyla karşılaştırıp elle tamamlarsın. Altıncı adım ise iletişimdir; etkilenen müşteriye ne olduğunu ve ne yapıldığını söylemek, sessiz kalmaktan her zaman daha iyidir.

Pinova bu süreci nasıl kolaylaştırıyor?

Pinova, yedeklemeyi "hosting sağlayıcın ne verirse" seviyesinde bırakmaz. Kritik tabloları ayrı sıklıkta dökebilen zamanlanmış görevler, dış depoya aktarım, yedek dosyalarının bütünlük doğrulaması ve geri yükleme kontrol listesi işin parçası olarak gelir. Ayrıca yapılandırma dosyaları ve anahtarlar için ayrı bir arşiv mantığı vardır; çünkü bir kurulumu ayağa kaldıran şey sadece veritabanı değildir.

Bunun işletme tarafındaki anlamı şudur: sistem tarafında bir kaza yaşandığında konuştuğun süre saatler değil dakikalardır ve bu süre tahmin değil, ölçülmüş bir gerçektir. Hangi bileşenin nasıl yedeklendiğini özellikler bölümünden inceleyebilir, kurulum ve destek kapsamını paket sayfasında görebilirsin.

Yedekleme, karşılığını yalnızca bir kez ama çok büyük ödeyen bir yatırımdır. O bir kez geldiğinde elinde test edilmiş bir plan varsa olay bir aksaklık olarak kalır; yoksa işletmenin dönüm noktası olur. Bugün yapabileceğin en değerli şey, mevcut yedeğini ayrı bir ortama geri yüklemeyi denemek ve süreyi not almaktır. Altyapının bu tarafını nasıl ele aldığını görmek istersen canlı demo üzerinden yönetim panelini gezip sistem ve yedek ekranlarına bakabilirsin.