Kısa cevap: Kurumsal bir sitede yedekleme planı üç soruyu cevaplamalıdır: ne kadar veri kaybını kabul edebilirsiniz, siteyi ne kadar sürede geri getirmeniz gerekir ve yedek nerede duruyor. Bu üçü netleşmeden alınan yedek, ihtiyaç anında işe yaramama riski taşır.
Şirketlerin çoğunda yedekleme "sağlayıcı alıyor" cümlesiyle geçiştirilir. Sorun şu ki gerçek bir olayda önemli olan yedeğin alınmış olması değil, geri yüklenebilmesi ve ne kadar geriye gittiğidir.
İki sayıyı belirleyin
Kabul edilebilir veri kaybı. Yedek günde bir alınıyorsa en kötü senaryoda 24 saatlik veriyi kaybedersiniz. Tanıtım sitesi için bu sorun değildir, çünkü gün içinde değişen bir şey yoktur. Ama sipariş alan ya da üye kaydı olan bir sitede 24 saat çok uzundur.
Kabul edilebilir kesinti. Site kaç saat kapalı kalabilir? Yedeğin var olması yetmez; geri yükleme talebinin ne kadar sürede karşılandığını bilmeniz gerekir. Bunu sağlayıcınıza sorun ve cevabı yazılı alın.
Bu iki sayı planın tamamını belirler. Günlük yedek ve birkaç saatlik geri yükleme çoğu kurumsal site için yeterlidir; e-ticaret için değildir.
Yedek nerede duruyor?
En sık yapılan hata, yedeği barındığı sunucunun içinde tutmaktır. Sunucu ya da hesap düzeyinde bir sorun olduğunda yedek de aynı sorundan etkilenir.
Doğru düzen üç katmanlıdır:
Sağlayıcı yedeği. Farklı bir yedekleme altyapısında tutulan, sizin müdahale etmediğiniz katman. Bunun varlığını ve saklama süresini teyit edin.
Hesap içi güncel kopya. Hızlı geri dönüş için tek bir güncel yedek. Daha fazlası disk doldurur, faydası olmaz.
Şirket dışı kopya. Ayda bir indirilen ve şirket içinde saklanan bir arşiv. Sağlayıcıyla ilişkinizin bittiği ya da hesaba erişemediğiniz senaryonun tek çözümü budur.
KVKK açısından bir ayrıntı: yedeklerin fiziksel olarak nerede tutulduğu da kişisel veri aktarımı kapsamına girer. Yurt içi barındırma yapıyorsanız yedeklerin de yurt içinde kalması gerekir; konuyu KVKK uyumlu hosting yazısında ele aldık.
Neyin yedeklendiğini bilin
Bir WordPress sitesinin geri yüklenebilmesi için iki şey gerekir ve ikisi ayrı yerlerde durur:
Dosyalar: tema, eklentiler, yüklenen görseller ve ayar dosyaları. Bunlar disk üzerindedir.
Veritabanı: sayfa içerikleri, ayarlar, kullanıcılar, siparişler. Bunlar MySQL içindedir.
Sadece dosya yedeği alan bir düzen, veritabanı bozulduğunda işe yaramaz. Tersi de geçerli. Yedeğinizin ikisini birlikte kapsadığını doğrulayın.
Test edilmemiş yedek, yedek değildir
Bu maddeyi atlamayın. Şirketlerin büyük kısmı yedeğini hiç test etmez ve ilk denemeyi gerçek bir kriz anında yapar. O anda çıkan sorunlar genelde şunlardır: yedek eksik alınmış, veritabanı sürümü uyumsuz, geri yükleme yetkisi kimsede yok, ya da yedeğin şifresini bilen kişi işten ayrılmış.
Yılda bir kez, gerçek olmayan bir ortamda geri yükleme denemesi yapın. Bir saatlik iş, kriz anında günleri kurtarır.
Sorumluluğu bir kişiye bağlayın
Kurumsal sitelerde en kırılgan nokta teknik değil idari olur: yedekten kim sorumlu, belli değildir. Ajans "sağlayıcı alıyor" der, sağlayıcı "müşteri kendi de alsın" der, sonuçta kimse almaz.
Panel erişimlerini kişi bazında ayırın, yedek sorumluluğunu tek bir role bağlayın ve o kişi ayrıldığında erişimin şirkette kaldığından emin olun. Bunun e-posta tarafındaki karşılığını kurumsal e-posta yazısında anlattık.
Yurt içinde barındırılan ve günlük yedeklenen bir düzen arıyorsanız kurumsal hosting paketleri bu yapıyı sağlar.
Sık Sorulan Sorular
Kurumsal sitede yedek ne sıklıkla alınmalı?
Kabul edilebilir veri kaybınıza bağlıdır. Günlük yedek, gün içinde içeriği değişmeyen tanıtım siteleri için yeterlidir. Sipariş ya da üye kaydı alan sitelerde 24 saatlik kayıp çok uzundur, daha sık yedek gerekir.
Yedeğimi hosting hesabımda tutmam yeterli mi?
Değil. Sunucu ya da hesap düzeyinde bir sorun olduğunda yedek de etkilenir. Hesap içinde bir güncel kopya tutun, ayrıca sağlayıcının farklı altyapıdaki yedeğine ve şirket dışı bir arşiv kopyasına sahip olun.
Yedekte neler bulunmalı?
Dosyalar (tema, eklentiler, görseller) ve veritabanı birlikte. Sadece birini kapsayan yedek, diğeri bozulduğunda işe yaramaz.
Yedeği test etmem gerekir mi?
Evet, bu en çok atlanan ve en kritik adımdır. Test edilmemiş yedeklerde eksik alım, sürüm uyumsuzluğu ya da yetki sorunu ilk kez gerçek kriz anında ortaya çıkar. Yılda bir geri yükleme denemesi yapın.
Yedeklerin Türkiye'de olması gerekir mi?
Kişisel veri işliyorsanız evet, çünkü yedeğin fiziksel konumu da veri aktarımı kapsamına girer. Sunucu yurt içinde olup yedek yurt dışına gidiyorsa aktarım gerçekleşmiş sayılır.
Yedekten kim sorumlu olmalı?
Tek bir role bağlanmalı. Ajans ile sağlayıcı arasında sorumluluğun belirsiz kalması, yedeğin hiç alınmamasının en yaygın sebebidir. Erişimler kişi bazında ayrılmalı ve o kişi ayrıldığında erişim şirkette kalmalı.



