Yedekleme Çözümleri: RPO ve Kurtarma Planı

Yedekleme çözümleri seçerken yalnızca verinin kopyalanıp kopyalanmadığına değil, arıza sonrası ne kadar veri kaybını kabul edebileceğinize ve hizmeti ne kadar sürede geri getireceğinize bakmalısınız. Sık değişen bir mağaza ile nadiren güncellenen tanıtım sitesinin aynı yedekleme düzenine ihtiyacı yoktur; doğru seçim, iş yükü ve geri dönüş hedefleri birlikte değerlendirilerek yapılır.

Yedekleme çözümleri için önce RPO ve RTO hedefini belirleyin

RPO, bir arıza durumunda kaybetmeyi göze aldığınız veri aralığıdır. Örneğin RPO değeri dört saat olan bir uygulamada, son yedek ile arıza arasındaki işlemlerin kaybolması kabul edilebilir sayılır. RTO ise hizmetin yeniden kullanılabilir hâle gelmesi için hedeflenen süredir. Bu iki değer, yedekleme sıklığını ve kurtarma yöntemini doğrudan etkiler.

Bir e-ticaret sitesinde siparişler gün boyunca sürekli değişiyorsa ve birkaç saatlik kayıt kaybı kabul edilemiyorsa daha sık alınan yedekler veya işlem günlüklerini de kapsayan bir tasarım değerlendirilebilir. Ancak yedekleme aralığını sıklaştırmak tek başına yeterli değildir; depolama kapasitesi, ağ kullanımı ve geri yükleme süresi de artabilir. Daha seyrek güncellenen bir kurumsal tanıtım sitesinde günlük yedekleme, daha uzun RPO kabul edilebildiği için yeterli olabilir.

İş yüküne göre yedekleme türünü seçin

Dosya ve veritabanı yedekleri

Dosya tabanlı yedekler web dosyalarını, yüklenen görselleri ve yapılandırma dosyalarını korumaya yardımcı olur. Veritabanı yedeği ise kullanıcı hesapları, siparişler ve içerik kayıtları gibi uygulamanın dinamik verilerini kapsar. İçerik yönetim sistemi kullanan bir sitede yalnızca dosyaları kopyalamak, veritabanındaki son değişiklikleri korumaz. Bu nedenle uygulamanın dosya ve veritabanı bileşenlerinin aynı zaman aralığını temsil edip etmediğini kontrol etmek gerekir.

Uygulama küçükse ve belirli dosyaları ayrı ayrı geri almak önemliyse dosya artı veritabanı yedekleri pratik olabilir. Tüm sunucuyu kısa sürede aynı yapılandırmayla ayağa kaldırmak gerekiyorsa sistem görüntüsü veya sunucu imajı daha uygun bir seçenek olabilir. İmajlar hızlı dönüş sağlayabilse de farklı işletim sistemi, donanım veya sanallaştırma ortamına taşınırken uyumluluk ve lisans koşulları sağlayıcıya göre değişebilir.

Yerel kopya, uzak kopya ve saklama süresi

Aynı sunucuda duran yedek, disk arızası veya sunucunun tamamına erişim kaybı gibi olaylarda asıl verilerle birlikte etkilenebilir. Bu yüzden yedeklerden en az bir kopyanın ayrı bir depolama alanında tutulması değerlendirilmelidir. Uzak depolama seçeneğinde aktarım süresi, geri indirme maliyeti, saklama süresi ve silinmeye karşı koruma gibi sağlayıcıya bağlı ayrıntıları inceleyin.

Günlük kopyaları uzun süre saklamak geçmiş bir tarihe dönmeyi kolaylaştırır, fakat kapasite ihtiyacını büyütür. Karar verirken önce yasal veya operasyonel saklama süresini belirleyin; ardından tam yedek, artımlı yedek ve otomatik silme politikasının bu süreyi nasıl etkilediğini sorun. Artımlı yedekler yalnızca son değişiklikleri kaydederek alan kullanımını azaltabilir, ancak geri yükleme sırasında birden fazla yedek zincirine ihtiyaç duyulabileceği için kurtarma süresi artabilir.

Bir yedekleme çözümünü ilk kullanımda nasıl değerlendirmeli?

Önce kritik bir dosya, bir veritabanı kaydı ve mümkünse uygulamanın temel yapılandırmasını içeren küçük bir test kümesi belirleyin. Yedekleme tamamlandıktan sonra panelde veya yönetim arayüzünde alınma zamanını, kapsanan bileşenleri ve hata uyarılarını kontrol edin. “Başarılı” görünen bir görev, veritabanı dışarıda bırakıldıysa tek başına yeterli kanıt değildir.

Sonraki adım, üretim sistemini değiştirmeden ayrı bir test ortamına geri yükleme yapmaktır. Geri yüklenen sitede giriş, yeni bir içerik kaydı, veritabanı bağlantısı ve yüklenmiş bir dosya gibi temel işlemleri deneyin. Dosya açılıyor fakat uygulama veritabanına bağlanamıyorsa dosya yedeği kullanılabilir olsa da uygulama kurtarması tamamlanmış sayılmaz. Bu gözlem, veritabanı yedeğinin ayrıca alınması veya bağlantı bilgilerinin kurtarma planına eklenmesi gerektiğini gösterir.

Diyelim ki bir kurumun uygulaması gün içinde yoğun biçimde veri yazıyor, fakat tam sunucu geri dönüşü için birkaç saatlik bakım penceresi bulunuyor. Bu durumda sık veritabanı yedekleri ve daha seyrek sistem imajları birlikte değerlendirilebilir: veritabanı RPO hedefini karşılamaya, imaj ise temel sunucu yapısını yeniden kurmaya hizmet eder. Uygulama yalnızca statik dosyalardan oluşuyorsa bu karmaşık yapı gereksiz olabilir; dosya sürümleme ve uzak kopya daha anlaşılır bir seçenek sunabilir.

Sağlayıcı ve yönetim modelini karşılaştırın

Paylaşımlı hosting panelinde yedekleme kapsamı, saklama süresi ve geri yükleme yetkisi sağlayıcının politikasına bağlı olabilir. Panelde yalnızca hesabı geri yükleme seçeneği bulunuyorsa tek bir veritabanı tablosunu veya dosyayı seçerek dönmek mümkün olmayabilir. Yönetilen sunucuda ise otomasyon ve kurtarma seçenekleri daha ayrıntılı olabilir, ancak hangi bileşenlerin dahil olduğu ve test ortamının sunulup sunulmadığı ayrıca doğrulanmalıdır.

Sunucuyu kendiniz yönetiyorsanız zamanlanmış görevlerin çalışması, depolama alanının dolmaması ve yedeklerin erişilebilirliği sizin sorumluluğunuzdadır. Bir çözüm otomatik çalışsa bile başarısız görev bildirimleri incelenmiyorsa görünürdeki düzenlilik yanıltıcı olabilir. Şu sırayla değerlendirin: kritik veri sık değişiyorsa RPO'yu karşılayan sıklığı arayın; geri dönüş çok kısa olmalıysa imaj veya hazır kurtarma ortamını inceleyin; bütçe ve kapasite sınırlıysa saklama süresini ve artımlı yedekleme etkisini hesaplayın. Bu koşullardan biri karşılanmıyorsa diğer özelliklerin iyi olması seçimi kurtarma açısından yeterli kılmaz.

Geri yükleme planını belgeleyin ve düzenli test edin

Yedekleme planında sorumlu kişi, yedeklerin bulunduğu konum, erişim yöntemi, geri yükleme sırası ve son başarılı test tarihi yazılı olmalıdır. Kimlik bilgilerini veya erişim anahtarlarını belgeye açık biçimde eklemek yerine güvenli bir parola yöneticisi ya da kurumun erişim politikasını kullanın. Yedeklerin şifrelenmesi, anahtarların kimde bulunduğu ve silinmeye karşı koruma seçenekleri de sağlayıcıya göre ayrıca incelenmelidir.

İlk testte kabul kriteriniz, belirlediğiniz dosya ve veritabanı kaydının doğru tarihten geri gelmesi ve uygulamanın temel işlevlerinin çalışması olabilir. Test başarısız olursa tüm ayarları aynı anda değiştirmeyin. Örneğin hata yalnızca veritabanı geri yüklemesinde görülüyorsa önce veritabanı dışa aktarma kapsamını ve sürüm uyumluluğunu ele alın; dosya yedeğini gereksiz yere değiştirmeyin. Testi yeni bir tarihte tekrarlayın ve sonucu kaydedin. İhtiyaçlarınıza uygun hizmet kapsamını incelemek için İyibirNet üzerindeki ilgili hosting bilgilerini değerlendirebilirsiniz.

Bir sonraki somut adım, mevcut siteniz için kabul edilebilir RPO ve RTO değerlerini yazmak, son yedeğin hangi bileşenleri içerdiğini kontrol etmek ve üretim verisine dokunmadan küçük bir geri yükleme testi planlamaktır. Test edilemeyen bir yedek, arşiv olarak mevcut olsa bile kurtarma planının tamamı değildir.