Yedekleme ve Felaket Kurtarma: Sunucunuz Çökerse İşiniz Ne Kadar Dayanır?

Bir gece yarısı sunucunuz yeniden başlamayı reddettiğinde ya da bir disk arızası veritabanınızı bozduğunda, sorduğunuz ilk soru genelde "en son yedek ne zaman alındı?" olur. E-pin ve dijital ürün satışı yapan bir işletmede bu soru sadece teknik bir merak değil, doğrudan gelir kaybı, müşteri güveni ve bazen tedarikçi bakiyesi anlamına gelir. Yedekleme ve felaket kurtarma, çoğu satıcının site açılana kadar hiç düşünmediği ama bir kriz anında her şeyin belirleyicisi olan konudur.

Sunucunuz bir gecede kaybolsa, işiniz kaç saatte ayağa kalkar?

Bu soruyu kendinize sormadan önce büyük ihtimalle net bir cevabınız yok. Oysa e-pin satışı yapan bir sitede "kaç saatte toparlarım" sorusunun cevabı doğrudan müşteri kaybına dönüşür. Ödeme alan ama teslimat yapamayan bir site, saatler içinde şikayet, ters ibraz (chargeback) ve marka güveni kaybıyla karşılaşır.

Gerçekte tehlike altında olan şeyler şunlardır:

• Sipariş ve ödeme geçmişi (muhasebe ve ihtilaf çözümü için kritik)
• Kullanılmamış stok kodları (kaybolursa doğrudan finansal zarar)
• Müşteri bakiyeleri / cüzdan tutarları
• Bayi komisyon ve borç-alacak kayıtları
• Tedarikçi API ayarları ve entegrasyon anahtarları

Bu listeye bakınca yedeklemenin "isteğe bağlı bir güzel özellik" değil, işin devamlılığı için ön koşul olduğu netleşir.

Hangi veriler gerçekten hayati, hangileri sadece "olsa iyi olur"?

Her veri aynı önem derecesinde değildir. Bir felaket anında zamanınız kısıtlıyken önceliklendirme yapabilmek, kurtarmayı hızlandırır. E-pin satış sisteminde veriler kabaca üç katmana ayrılır.

• Birinci katman (kayıpsa iş durur): sipariş tablosu, stok kodları, ödeme kayıtları, cüzdan bakiyeleri
• İkinci katman (kayıpsa ciddi aksama olur): ürün kataloğu, kategori yapısı, bayi hesapları, kupon/kampanya verileri
• Üçüncü katman (kayıpsa telafi edilebilir): tema dosyaları, statik görseller, blog içerikleri

Pek çok küçük işletme yedekleme derken sadece dosya sistemini (üçüncü katman) yedekler; oysa asıl kritik olan veritabanıdır. Bir felaket kurtarma stratejisinin önceliği her zaman birinci katmandan başlamalıdır.

Manuel yedekleme neden er ya da geç sizi yüzüstü bırakır?

Çoğu satıcı işe başlarken "haftada bir cPanel'den yedek alırım" der ve bir süre bu işe sadık kalır. Ancak zaman geçtikçe sipariş hacmi artar, iş yoğunlaşır ve yedekleme rutini aksamaya başlar. Sorun tam da burada ortaya çıkar: felaket, en son yedeğinizin ne kadar eski olduğunu umursamaz.

Manuel yedeklemenin tipik zaafları:

• İnsan hafızasına bağımlı olduğu için unutulur veya ertelenir
• Yedek dosyası genelde sunucunun kendisinde saklanır — sunucu çökünce yedek de gider
• Geri yükleme adımları test edilmemiştir; kriz anında ilk kez denenir
• Kısmi (sadece dosya ya da sadece veritabanı) yedekler tutarsızlık yaratır
• Hangi yedeğin hangi tarihe ait olduğu, dosya adlarına bakılarak tahmin edilir

Bu maddelerin ortak noktası şudur: sistem insana bağımlı olduğu sürece, ihmal her zaman bir gün gelir. Otomasyon olmadan süreklilik garanti edilemez.

Kriz anında geçen her dakika, tam olarak neye mal olur?

Felaket kurtarmada iki metrik konuşulur: RTO (Recovery Time Objective — sistemi ne kadar sürede ayağa kaldırabilirsiniz) ve RPO (Recovery Point Objective — en fazla ne kadarlık veri kaybını göze alabilirsiniz). E-pin satışında bu iki rakam doğrudan paraya çevrilebilir.

Örneğin günde ortalama 150 sipariş alan orta ölçekli bir mağaza düşünün. Sistem 4 saat kapalı kalırsa, bu süre boyunca gelen tüm ödeme talepleri ya kaybolur ya da manuel işlem kuyruğuna düşer — her ikisi de müşteri memnuniyetsizliği ve ek iş yükü demektir. RPO'nun büyük olması (örneğin son yedeğin 24 saat önceki olması) ise, o 24 saatte tamamlanan siparişlerin veya cüzdana yüklenen bakiyelerin sistemsel olarak "yok" sayılması riski taşır.

Kısacası RTO ve RPO ne kadar küçükse, felaket anında kaybınız o kadar sınırlı kalır. Bu iki değeri küçültmenin yolu ise otomatik, sık ve doğrulanmış yedeklemeden geçer.

Bir yazılımın "otomatik yedekleme" demesi ile gerçekte güvenilir olması arasındaki fark nedir?

Piyasada birçok e-ticaret ve e-pin scripti "otomatik yedekleme" özelliğinden bahseder, ama bu ifadenin arkasında çok farklı uygulamalar olabilir. Bazıları sadece dosyaları, bazıları sadece veritabanını yedekler; bazıları yedeği aynı sunucuda tutar, bazıları hiç test edilmemiş bir geri yükleme sürecine sahiptir.

Pinova'da yedekleme yaklaşımı, yukarıda anlatılan riskleri doğrudan hedef alacak şekilde kurgulanmıştır: kritik tablolar (siparişler, stok kodları, cüzdan bakiyeleri, bayi hesapları) düzenli aralıklarla yedeklenir, dosya sisteminden bağımsız olarak veritabanı tutarlılığı korunur ve yedek erişimi panel üzerinden kolayca yönetilebilir. Kendi sunucunuza kurulan bir sistem olduğu için, yedeklerinizi kendi altyapı politikanıza (harici depolama, farklı sağlayıcı, kendi sunucu grubunuz) göre şekillendirme özgürlüğüne de sahip olursunuz — üçüncü taraf bir SaaS'a bağımlı kalıp "verilerim nerede duruyor" belirsizliğini yaşamazsınız.

Aşağıdaki tablo, manuel yönetilen bir sistemle Pinova altyapısındaki yaklaşımı karşılaştırıyor:

Kendi sunucunuzda gerçekçi bir felaket kurtarma planını nasıl kurarsınız?

Pinova gibi kendi sunucunuza kurulan bir sistemde, yazılımın sunduğu yedekleme altyapısı kadar sizin de birkaç temel adımı hayata geçirmeniz önemlidir. Aşağıdaki liste, teknik derinliğe girmeden uygulanabilecek bir kontrol çerçevesi sunuyor.

• Yedek sıklığını iş hacminize göre belirleyin: günlük yüzlerce sipariş alan bir mağaza için saatlik veritabanı yedeği, düşük hacimli bir mağaza için günlük yedek yeterli olabilir.
• Yedekleri farklı bir konumda tutun: sunucu sağlayıcınızın sunduğu otomatik snapshot'lara ek olarak, ayrı bir depolama alanı (harici sunucu, bulut depolama) kullanın.
• Geri yüklemeyi ara sıra test edin: bir yedeği gerçekten geri yükleyip sistemin çalıştığını görmeden, o yedeğin işe yarayacağından emin olamazsınız.
• Erişim ve şifreleme kontrolü yapın: yedek dosyaları müşteri verisi içerdiği için, bu dosyalara kimlerin erişebildiğini ve şifreleme durumunu düzenli kontrol edin.
• Bir "kriz anı" prosedürü yazın: sunucu çöktüğünde kimin ne yapacağı, hangi yedeğin nereden alınacağı önceden yazılı olsun; panik anında doğaçlama yapmak hata riskini artırır.

Bu adımlar tek başına mükemmel bir güvence sağlamaz, ama düzenli uygulandığında en yaygın felaket senaryolarının çoğuna karşı işinizi koruma altına alır.