Yedekleme ve felaket kurtarma planı kurmak

"Yedeğimiz var" cümlesi, e-ticaret ekiplerinde en sık tekrarlanan ve en az doğrulanan cümledir. Panelde bir kutucuk işaretlidir, sağlayıcı "günlük yedek alıyoruz" demiştir, aylardır bir yere dosyalar yazılmaktadır. Oysa yedek almak güvence değil, yalnızca ihtimaldir; güvence, o yedekten ne kadar sürede ve ne kadar kayıpla geri dönebildiğinizdir. Bu rehberde hangi kayıp senaryosuna karşı korunduğunuzu, kurtarma hedeflerinizi nasıl sayıya çevireceğinizi ve planınızın gerçekten var olduğunu kanıtlayan tek şeyi — geri yükleme tatbikatını — konuşuyoruz.

Veri kaybı tek bir kapıdan gelmez

Çoğu yedekleme kurgusu tek senaryoya göre tasarlanır: "sunucu bozulursa". Gerçekte veri kaybı en az dört ayrı kapıdan girer ve her kapı yedeğinizden farklı bir özellik ister. Sorulacak soru "yedek alıyor muyuz" değil, "hangi kapıyı kapatıyoruz" olmalıdır.

• İnsan hatası: yanlış filtreyle yapılan toplu fiyat güncellemesi, silinen bir kategori, ters yönde çalışan bir içe aktarma dosyası. En sık yaşanan ve genellikle saatler sonra fark edilen senaryodur; gereken şey "dünkü yedek" değil, geriye dönük birkaç sürüm arasından seçim yapabilmektir.
• Kötü niyetli erişim: ele geçirilmiş bir yönetici hesabı ya da fidye yazılımı. Kritik ayrıntı şudur: saldırgan, sizin eriştiğiniz her yere erişir; sunucudaki yedek klasörü ve aynı hesapla bağlı bulut deposu da şifrelenir.
• Sağlayıcı tarafındaki arıza veya hesap sorunu: donanım arızası, veri merkezi kesintisi, ödeme sorunundan doğan askıya alma. Sağlayıcınızın yedeği, sağlayıcınıza erişemediğiniz anda işe yaramaz.
• Sessiz bozulma: hatalı bir entegrasyonun haftalarca yanlış veri yazması. En tehlikeli tarafı, yedeklerin "başarıyla" alınmasıdır: bozuk veriyi sadakatle kopyalarlar ve saklama süreniz kısaysa, sorunu fark ettiğinizde temiz sürüm silinmiştir.

Ortak ders net: aynı makinede, aynı hesapta duran bir kopya yedek değil, sadece ikinci bir dosyadır.

Planın iki sayısı: ne kadar süre kapalı, ne kadar veri eksik?

Konuşmayı somutlaştıran iki kavram var. RTO (kurtarma süresi hedefi) olaydan sonra ne kadar sürede yeniden satış yapar hâle geleceğinizi; RPO (veri kaybı toleransı) olay anıyla son sağlıklı yedek arasında ne kadarlık boşluğa razı olduğunuzu söyler. İkisi de teknik tercih değil, ticari karardır.

Her gece 03.00'te tek yedek alan bir mağaza öğleden sonra veri kaybı yaşarsa RPO'su yarım günü aşar. Kaybolan şey soyut bir "veri" değildir: o gün alınan siparişler, tahsil edilmiş ödemeler, iade talepleri ve stok hareketleridir. Ödeme sağlayıcısında görünen ama sitede karşılığı olmayan tahsilatlar çıkar; bunun muhasebe ve müşteri iletişimi maliyeti çoğu zaman arızadan pahalıdır.

RTO'yu duyguyla değil hesapla belirleyin: bir saatlik kesintide kaybedilen ciro, boşa akan reklam bütçesi ve pazaryeri performans göstergelerinde oluşan hasar. Sıfıra yakın hedefler teknik olarak mümkündür ama maliyet hızla tırmanır; doğru cevap "en iyisi" değil, kaybın maliyetiyle önlemin maliyetinin kesiştiği noktadır. Kesintilerin bir bölümü felaketle değil kapasiteyle ilgilidir; yoğun günlerde ayakta kalmak sunucu ölçekleme tarafının işidir. Bütün veriye aynı hedefi koymak ise gereksiz pahalıdır.

Yedek nerede duruyor, ne kadar kalıyor?

En eski kural hâlâ geçerli: en az üç kopya, iki farklı ortam, en az biri fiziksel olarak ayrı lokasyonda. Bugünün tehdit tablosu buna bir madde ekliyor: kopyalardan biri değiştirilemez ya da çevrimdışı olmalı ve farklı kimlik bilgileriyle korunmalıdır. Kurgunuzu tek soruyla test edin: "Yönetici parolam bugün ele geçirilse, saldırgan yedekleri de silebilir mi?" Cevap evet ise üç kopyanız kâğıt üzerinde vardır, pratikte yoktur.

Saklama süresi genelde disk maliyeti üzerinden konuşulur; oysa doğru ölçü fark etme gecikmesidir. Silinmiş bir kaydı üç hafta sonra fark ettiğinizde saklama süreniz bir haftaysa, kusursuz sistem bile sizi kurtarmaz. Katmanlı şema işi çözer: günlük yedekler birkaç hafta, aylık anlık görüntüler çok daha uzun tutulur.

İki nokta uyum tarafına bakar. Birincisi, yedekleriniz sipariş ve müşteri verisi taşır; yani kişisel veridir. Şifrelenmeleri, erişimin kayıtlı ve saklama sürelerinin tanımlı olması KVKK uyum kontrol listenizin parçasıdır; "sonsuza kadar saklamak" güvenlik değil, ayrı bir risktir. İkincisi, ticari ve mali kayıtların saklanması ayrı bir mevzuat konusudur ve fatura ile e-arşiv süreçlerinizin yükümlülükleri yedekleme politikanızdan bağımsız yürür; süreler için mali müşavirinize danışın.

Geri yükleme tatbikatı: planın var olduğunu kanıtlayan tek şey

Bir yedeğin geçerli olup olmadığı ancak geri yüklendiğinde bilinir. Aylarca "başarılı" raporu üreten bir işin aslında veritabanının bir bölümünü aldığı ya da medya klasörünü hiç kapsamadığı çoğu zaman ilk kez felaket anında öğrenilir.

1. Temiz bir hedefe geri yükleyin. Canlıya değil, ayrı bir test ortamına. Süreyi kronometreyle ölçün; gerçek RTO'nuz budur, tahmininiz değil.
2. Bütünlüğü kontrol edin. Veritabanı ile dosyalar aynı ana ait olmalıdır. Sipariş var ama fatura dosyası yoksa yedekleriniz senkron değildir.
3. İşlevi test edin. "Site açılıyor" yetmez: ürün sayfası, sepet, test modunda ödeme adımı ve panel girişi çalışıyor mu?
4. Kısmi geri yüklemeyi deneyin. Gerçek olayların çoğu tek bir tabloyu ya da silinmiş bir kategoriyi geri getirmeyi gerektirir. Her şeyi dünkü hâline döndürmek en kötü seçenektir; arada oluşmuş yeni siparişleri silersiniz.
5. Sonucu yazın. Tarih, süre, sorunlar ve sorumlu kişi. Bir sonraki tatbikatta süre kısalmalıdır; kısalmıyorsa plan değil ritüel yapıyorsunuz demektir.

Makul rutin en az çeyrekte bir; ayrıca sunucu taşıma, sürüm yükseltmesi ve büyük kampanya öncesi. Yanına iki alarm kurun: yedek işi başarısız olduğunda bildirim ve beklenen boyuttan sapma uyarısı. Sessizce çalışmayan yedekleme, hiç olmayandan tehlikelidir; yanlış güven duygusu üretir.

"Yedekleme bir dosya değil, bir süredir. Kriz anında ölçtüğünüz tek şey, geri dönene kadar geçen zamandır."

Kriz anında kimin ne yapacağı yazılı mı?

Felakette kaybedilen zamanın büyük kısmı teknik değil, karar ve iletişim kaynaklıdır. Kurtarma el kitabı kısa ve krizde okunabilir olmalıdır: kim karar verir, erişim bilgileri kimde durur (yalnızca çöken sistemin içinde değil) ve hangi işlem hangi sırayla yapılır.

Sıra meselesi hafife alınır. Saldırı sonrası en sık yapılan hata, hemen eski yedeği üstüne yazmaktır. Önce erişim kapatılmalı, mevcut durumun bir kopyası inceleme için saklanmalı ve saldırganın kullandığı açık kapatılmalıdır; kapatılmayan açık, geri yüklenen sitede aynı gün yeniden kullanılır. Parolaların ve entegrasyon erişim bilgilerinin yenilenmesi de bu aşamanın parçasıdır.

Geri yükleme bittiğinde iş bitmez. Sitenin verisi birkaç saat geriye alındıysa dış sistemler ileri saatte kalır: pazaryerlerindeki stok bilgisi, kargo tarafında üretilmiş etiketler, muhasebe kayıtları. Bu yüzden geri dönüşün ardından pazaryeri stok senkronunu kontrollü biçimde yeniden kurmak gerekir; aksi hâlde satılmış ürünü tekrar satışa açar ya da aynı siparişi iki kez işlersiniz.

Son olarak iletişim: müşteriye ne söyleneceği önceden taslak hâlinde hazır olmalıdır; kesintideki sessizlik, kesintinin kendisinden çok güven kaybettirir. Kişisel verinin etkilendiği durumlarda bildirim yükümlülükleri devreye girer; usul ve süreler için hukuk danışmanınıza danışın.

Sorumluluk kimde? Sağlayıcınıza sormanız gereken sorular

Pek çok mağazada yedekleme sorumluluğu, "sağlayıcı hallediyordur" varsayımıyla "biz aldığımızı sanıyorduk" cümlesi arasında kaybolur. Netleştirmenin yolu somut sorular sormaktır.

• Yedekler hangi sıklıkta alınıyor, ne kadar saklanıyor? Kampanya döneminde sıklık artırılabiliyor mu?
• Yedekler farklı bir lokasyonda mı, yoksa aynı sunucu ve aynı hesabın içinde mi duruyor?
• Yedeğin kopyasını kendim indirebiliyor muyum? Sağlayıcıdan ayrılmak da bir kurtarma senaryosudur.
• Geri yüklemeyi ben başlatabiliyor muyum, yoksa talep açıp sıra mı bekliyorum?
• Tek bir tabloyu veya dosyayı geri almak mümkün mü; yoksa tek seçenek "her şeyi dünkü hâline döndürmek" mi?
• Yedekler şifreli mi, kimler erişebiliyor ve sağlayıcı kendi geri yükleme testini yapıyor mu?

Cevaplar belirsizse aslında cevabınızı almışsınızdır: ikinci kopyayı kendi kontrolünüzde tutun. En kırılgan kurgu, tek bir hesaba bağlı ve hiç denenmemiş yedeklemedir.

Sık sorulan sorular

Hosting sağlayıcım zaten günlük yedek alıyor; ayrıca kendi yedeğimi almalı mıyım?

Almalısınız. Sağlayıcı yedeği, sağlayıcıyla ilgili senaryoların hiçbirini kapsamaz: hesabın askıya alınması, geniş çaplı arıza ya da hizmetten ayrılma kararı. Ayrıca bu yedekler genellikle "tüm sistemi belirli bir güne döndürme" mantığıyla çalışır; tek bir müşterinin kayıtlarını geri getirmek mümkün olmaz. Kendi kontrolünüzdeki şifreli ikinci kopya, iki boşluğu birden kapatır.

Küçük bir mağazayım; ne sıklıkta yedek almalı, ne kadar saklamalıyım?

Sıklığı ciro değil iki soru belirler: kaç saatlik veriyi elle yeniden girmeye razısınız ve o saatlerde kaç sipariş akıyor? Günde birkaç sipariş alan mağazada günlük yedek makuldür; sürekli sipariş akan mağazada aynı kurgu, bir günlük satışı riske atmak demektir. Saklamada ise disk maliyetine değil, bir hatayı en geç ne kadar sürede fark ettiğinize bakın.

Geri yükleme tatbikatını canlı siteyi riske atmadan nasıl yaparım?

Tatbikat zaten canlıda yapılmaz. Yedeği erişimi kapalı ayrı bir test ortamında ayağa kaldırın; ödeme ve e-posta gönderimi gibi dış servisleri test moduna alın ki gerçek müşterilere bildirim gitmesin. Kurulum adımlarını da belgeleyin: bir kez yazdığınızda gerçek olayda aynı adımları yeniden keşfetmezsiniz.

Yedekleme ve kurtarma tek seferlik bir kurulum değil; hedefleri yazılı, sorumlusu belli ve düzenli denenen bir süreçtir. Yükü hafifletmenin en pratik yolu, verinin tek yerde yönetildiği bir altyapıda çalışmaktır: stok ve sipariş yönetimi, pazaryeri ve kargo entegrasyonları, sanal POS ve SEO dostu vitrin tek panelden yürüdüğünde, geri dönüşte neyin senkronlanacağını takip etmek kolaylaşır. Şimşek Software'in e-ticaret altyapısını kendi senaryolarınız üzerinden görmek isterseniz demo talep edin; kurtarma planınızı birlikte gözden geçirelim.