Felaket Kurtarma Planı Nasıl Hazırlanır?

Felaket kurtarma planı, yalnızca yedek almak değil; hizmet kesildiğinde hangi verinin ne kadar kaybedilebileceğini, sitenin ne kadar sürede açılması gerektiğini ve geri yüklemenin kimin tarafından nasıl doğrulanacağını önceden belirlemektir. Önce RPO ve RTO hedeflerini yazın, ardından yedeklerin erişilebilirliğini kontrol edip izole bir ortamda geri yükleme tatbikatı yapın.

Felaket kurtarma planına başlamadan önce erişimi belirleyin

Planın uygulanacağı ortamı netleştirmeden verilen talimatlar yanıltıcı olabilir. Paylaşımlı hosting kullanıyorsanız genellikle hosting panelindeki yedekleme, dosya yöneticisi, veritabanı ve DNS ekranlarına erişirsiniz; işletim sistemi servislerine veya fiziksel disklere erişiminiz olmayabilir. Yönetilen ya da kendi yönettiğiniz sunucuda ise sunucu yöneticisi, depolama alanı, veritabanı yönetimi ve DNS hesabı gibi ek erişimler gerekir.

Başlamadan önce alan adının DNS yönetimini, uygulama dosyalarını, veritabanını, yüklenen medya dosyalarını, yapılandırma değerlerini ve yedek depolama hesabını listeleyin. Parolaları veya erişim anahtarlarını makalenin içine ya da ortak bir belgeye düz metin olarak koymayın; planın kendisinde yalnızca güvenli parola kasasındaki kayda referans verin. Değişiklik yapacaksanız mevcut ayarı ve yedekleme zamanlamasını önce kaydedin.

RPO ve RTO hedeflerini gerçek ihtiyaca göre seçin

RPO, bir arıza sonrasında kabul edilebilir veri kaybı aralığıdır. Son yedek iki saat önce alınmışsa, sistem düzgün geri dönse bile son iki saatteki sipariş veya içerik değişiklikleri kaybolabilir. RTO ise hizmetin yeniden kullanılabilir hâle gelmesi için kabul edilen süredir. Bu iki hedef aynı şey değildir; kısa sürede açılan ancak eski veriye dönen bir site, bazı işler için yeterli olmayabilir.

Karar şu şekilde verilebilir: İçeriği günde birkaç kez değişen ve kısa süreli kesintiyi tolere eden bir tanıtım sitesi için daha seyrek yedek ve daha uzun RTO kabul edilebilir; sık sipariş alan bir mağazada veri kaybı pahalıysa yedekleme sıklığı ve geri yükleme yöntemi daha dikkatli planlanmalıdır. Ancak RPO’yu küçültmek tek başına çözüm değildir; yedek bozuksa veya aynı sunucuda tutuluyorsa hedef kâğıt üzerinde kalır.

Örneğin varsayımsal olarak, bir kurumun duyuru sitesi günde iki kez güncelleniyor ve yöneticiler dört saatlik kesintiyi kabul ediyorsa dört saatlik RPO ile daha uzun bir RTO makul olabilir. Buna karşılık aynı kurumun başvuru formu sürekli veri alıyorsa, yalnızca site dosyalarını geri yüklemek yeterli değildir; veritabanı kayıtlarının daha sık korunması ve form hizmetinin ayrıca doğrulanması gerekir.

Yedekleri yalnızca varlığına göre değil, kullanılabilirliğine göre inceleyin

İlk kontrol, yedekleme ekranındaki son başarılı çalışma kaydıdır. Kayıt güncel görünse bile dosya yedeği, veritabanı yedeği ve gerekiyorsa medya klasörü ayrı ayrı kapsamda mı bakın. Uygulamanın çalışması için gereken yapılandırma dosyaları, zamanlanmış görevler ve DNS bilgileri de planın parçası olabilir; sağlayıcıya göre bunlar otomatik yedeğe dahil edilmeyebilir.

Yedek yalnızca üretim sunucusunda duruyorsa disk arızası veya hesap erişim sorunu yedeği de etkileyebilir. Bu nedenle sağlayıcının desteklediği güvenli bir ikincil konum kullanın ve saklama süresini RPO’dan ayrı değerlendirin. Bir yedeğin eski olması, otomatik olarak işe yaramadığı anlamına gelmez; fakat yedekten geri dönüldüğünde hangi verilerin eksik kalacağını önceden yazmak gerekir.

Geri yükleme tatbikatını kontrollü biçimde uygulayın

Gerçek site üzerinde dosya silerek veya canlı veritabanını değiştirerek test yapmayın. Mümkünse staging alanı, geçici bir sunucu ya da sağlayıcının izole geri yükleme özelliğini kullanın. Böyle bir alan yoksa, üretim hesabında değişiklik yapmadan önce sağlayıcının geri yükleme yönteminin hangi kaynakları etkilediğini yazılı olarak doğrulayın.

1. Başlangıç durumunu kaydedin: Alan adı, uygulama sürümü, veritabanı adı, dosya kapsamı, son yedek zamanı ve mevcut DNS değerlerini not edin. Bu bilgiler, test ile canlı ortamın karıştırılmasını önler.
2. Uygun bir yedek seçin: Yedekleme panelinde başarılı durumdaki en güncel kaydı ve bir önceki kaydı karşılaştırın. Son kayıt eksik dosya veya veritabanı uyarısı içeriyorsa onu tek seçenek kabul etmeyin; eksiksiz olduğu görülen önceki kaydı test için ayırın.
3. İzole ortama geri yükleyin: Önce dosyaları, sonra veritabanını ve uygulamanın ihtiyaç duyduğu yapılandırmayı sağlayıcının desteklediği yöntemle geri alın. Dosyalar oluşmuş ancak uygulama veritabanına bağlanamıyorsa sorun yedek eksikliğinden çok bağlantı bilgilerinin veya izinlerin ortama uyarlanması olabilir; yalnızca izinleri genişletmek yerine ilgili yapılandırma değerlerini kontrol edin.
4. İşlevsel doğrulama yapın: Ana sayfayı, yönetim girişini, veritabanından veri okuyan bir sayfayı, dosya yüklemeyi ve kritik formu test edin. Ana sayfa açılırken eski içerik görünüyorsa dosyalar gelmiş, veritabanı ya da önbellek katmanı eksik kalmış olabilir. Form kaydı oluşturulamıyorsa yeni bir test kaydının veritabanında oluşup oluşmadığını kontrol edin; bu bulguya göre bağlantı, şema veya yazma yetkisini ayrı ayrı inceleyin.
5. Sonucu ve süreyi kaydedin: Geri yükleme başlangıç-bitiş zamanını, eksik kalan bileşeni ve kabul kriterlerini belgeleyin. Aynı test işlemini değişiklikten sonra yeniden yapın ve bu kez yeni zaman damgalı kayıtları inceleyin. Sorun sürerse üretim ortamındaki ayarı değiştirmeyin; test ortamını koruyup önceki yapılandırmaya dönün ve sağlayıcının geri yükleme kapsamını netleştirin.

Planı ne zaman güncellemelisiniz?

Yeni bir ödeme modülü, veritabanı şeması, depolama konumu veya DNS sağlayıcısı eklendiğinde planı yeniden değerlendirin. Bir değişiklikten sonra yedek başarıyla oluşsa bile geri yükleme testinde yeni bileşenin çalıştığı kanıtlanmamış olur. Her testte tek bir değişkeni değiştirin; böylece başarısızlığın yedek dosyasından mı, uygulama yapılandırmasından mı yoksa ağ yönlendirmesinden mi kaynaklandığını ayırabilirsiniz.

İlk pratik adım, mevcut yedekleme ekranından son başarılı çalışmanın kapsamını ve zamanını kaydetmek, ardından RPO ile RTO hedeflerini birer cümleyle yazmaktır. Sunucu veya barındırma seçeneklerini değerlendirirken genel yönlendirme için İyibirNet kaynağına da göz atabilirsiniz; teknik kurtarma planınızda ise her zaman kendi ortamınızdaki doğrulanmış yedek ve geri yükleme sonuçlarını temel alın.