Web Sitesi İçin Felaket Kurtarma Planı Nasıl Hazırlanır?

Bir web sitesi için felaket kurtarma planı, yalnızca yedek almak değil; kesintinin nasıl fark edileceğini, hangi verinin nereden geri getirileceğini ve hizmetin nasıl doğrulanacağını önceden belirlemektir. Önce barındırma ortamınızı ve erişim yetkilerinizi netleştirin, ardından yedeklerin bağımsız bir konumda bulunduğunu doğrulayın ve kontrollü bir geri yükleme provası yapın.

Felaket kurtarma planına başlamadan önce ortamı belirleyin

Paylaşımlı hosting kullanıyorsanız paneldeki yedekleme, dosya yöneticisi, veritabanı ve destek seçenekleriyle sınırlı olabilirsiniz. Bu ortamda sunucu imajı oluşturamaz veya işletim sistemi seviyesinde geri dönüş yapamazsınız; planınız site dosyaları, veritabanı, alan adı ayarları ve e-posta gibi hizmetlerin sağlayıcı tarafından hangi kapsamda kurtarılabildiğine dayanır.

Yönetici erişimli bir VPS ya da fiziksel sunucuda ise uygulama dosyaları, veritabanı, yapılandırma dosyaları, sertifika yenileme bilgileri ve bağlı depolama alanları ayrıca ele alınmalıdır. Yönetici erişiminiz yoksa sunucu düzeyinde işlem yapmaya çalışmayın. Önce barındırma panelindeki yetkileri ve sağlayıcının geri yükleme kapsamını yazılı olarak doğrulayın.

İlk karar, kaybın türüne göre verilir: yalnızca birkaç dosya değişmişse dosya yedeği yeterli olabilir; veritabanı bozulmuşsa aynı dosya kopyasını geri getirmek sorunu çözmez ve veritabanı yedeği gerekir. Sunucunun tamamı erişilemez durumdaysa, sağlayıcının altyapı kurtarma seçeneği veya ayrı bir barındırma ortamına taşınma planı gerekir.

Hangi verinin ve hangi sırayla geri getirileceğini yazın

Bir kurtarma belgesinde her bileşenin adı, yedekleme sıklığı, saklama konumu, son başarılı yedek zamanı ve geri yükleme yöntemi bulunmalıdır. Web sitesi için genellikle şu bileşenler ayrı kontrol edilir:

• Uygulama dosyaları: Tema, eklenti, yüklenen medya ve özel kodun hangi sürümünün kullanılacağını gösterir.
• Veritabanı: Kullanıcılar, siparişler, içerikler ve ayarlar burada tutuluyorsa dosya yedeğinden ayrı saklanmalıdır.
• Alan adı ve DNS kayıtları: Yeni bir sunucuya geçişte ziyaretçinin doğru adrese yönelmesini sağlar; DNS değişiklikleri sağlayıcıya ve önbellek sürelerine bağlı olarak hemen görünmeyebilir.
• Gizli yapılandırmalar: Veritabanı bağlantı bilgileri, uygulama anahtarları ve sertifika dosyaları yedekte bulunuyorsa erişimleri kısıtlı tutulmalıdır.

İkinci karar zinciri kurtarma sırasıyla ilgilidir: uygulama dosyaları sağlamsa ve yalnız veritabanı geri alınacaksa önce veritabanını izole bir kopyaya yükleyip uygulama bağlantısını test edin; tüm sunucu değişecekse önce çalışma ortamını kurun, sonra dosya ve veritabanını aynı uyumlu sürümlerle geri getirin. Uygulama sürümü ile veritabanı şeması uyumsuzsa geri yükleme başarılı görünse bile site hatalı çalışabilir.

Güvenli bir kurtarma provası için izlenecek adımlar

1. Başlangıç durumunu ve erişimleri kaydedin

Mevcut site adresini, yönetim panelini, kullanılan PHP veya uygulama sürümünü, veritabanı türünü ve sağlayıcı iletişim kanalını not edin. Paylaşımlı hostingde panel yedek ekranını; yönetilen sunucuda ise yedekleme konsolunu ve kurtarma izinlerini inceleyin. Bir değişiklik yapmadan önce mevcut yapılandırma değerlerini ve çalışan yedeğin tarihini saklayın.

2. Yedeğin gerçekten okunabildiğini doğrulayın

Yedekleme ekranında yalnızca “başarılı” durumuna bakmayın; dosya arşivinin boyutunu, veritabanı dışa aktarımının tarihini ve saklama konumunu kontrol edin. Dosya arşivi beklenmedik biçimde boşsa veya veritabanı kaydı eskiyse bunu geçerli kurtarma noktası saymayın. Ayrı bir kopya yoksa üretim sitesinde değişiklik yapmadan önce sağlayıcının bağımsız yedek ya da geri yükleme seçeneğini netleştirin.

3. Üretimi etkilemeyen bir test alanı oluşturun

Sağlayıcınız izin veriyorsa geçici alt alan adı, ayrı veritabanı veya izole bir sunucu kullanın. Yedeği bu alana geri yükleyin; canlı veritabanının üzerine yazmayın. Dosyalar açılıyor, veritabanı bağlantısı kuruluyor ve yönetim paneli beklenen içerikleri gösteriyorsa temel kurtarma yolu çalışıyor demektir. Giriş bilgileri veya kişisel veriler bulunan test alanını herkese açık bırakmayın.

4. Gerçek kullanıcı akışlarını kontrol edin

Ana sayfayı açmakla yetinmeyin; giriş, içerik oluşturma, dosya yükleme ve gerekiyorsa sipariş ya da iletişim formu gibi kritik işlemleri test edin. Bir işlem dosya yazma hatası veriyorsa önce ilgili klasörün sahiplik ve yazma politikasını, veritabanı hatası veriyorsa bağlantı ayarlarını ve şema uyumunu inceleyin. Sorunu görmeden tüm izinleri genişletmeyin veya güvenlik kontrollerini kapatmayın.

5. Sonucu zaman damgasıyla doğrulayın

Testte başarısız olan aynı işlemi, düzeltmeden sonra yeniden çalıştırın ve yeni saatle oluşan uygulama veya sunucu kaydını inceleyin. Yeni kayıt bağlantı hatasının kaybolduğunu gösteriyor ancak dosya yazma hatası sürüyorsa yalnızca bağlantının düzelmiş olduğunu kabul edin; kalan belirti için ayrı bir inceleme yapın. Değişiklik sorunu artırırsa kaydettiğiniz önceki değere dönün. Test tamamlandığında geçici verileri güvenli biçimde kaldırma işini sağlayıcının prosedürüne göre planlayın.

Örneğin bir içerik sitesinde sunucu arızası sonrasında dosyalar geri yüklenmiş, ancak son makaleler görünmüyorsa sorun dosya arşivinde değil veritabanı yedeğinin tarihindedir. Daha eski veritabanı ile devam etmek yerine, erişilebilen en yeni veritabanı kopyasını ayrı test alanında doğrulamak daha güvenlidir. Test alanında içerikler doğru görünürse canlı geçiş planlanır; görünmüyorsa üretim verisinin üzerine yazmadan başka bir kurtarma noktası incelenir.

Planın sınırlarını ve sağlayıcıya bağlı noktaları yönetin

Yedek bulunması, her zaman eksiksiz kurtarma anlamına gelmez. Son yedekten sonraki siparişler, yüklenen dosyalar veya kullanıcı kayıtları kaybolabilir. Bu nedenle yedekleme aralığını iş yüküne göre seçin: sık veri değişen bir mağazada yalnızca haftalık dosya kopyası yetersiz kalabilir; nadiren güncellenen tanıtım sitesinde daha seyrek bir plan kabul edilebilir.

Sağlayıcının yedek saklama süresi, farklı veri merkezinde kopya tutup tutmadığı, geri yükleme için gereken yetki ve DNS değişikliğinin nasıl yapılacağı hizmete göre değişir. Bu ayrıntıları planın içine kişi adı yerine görev ve erişim kanalı olarak yazın. İlk provadan sonra yedek tarihini, test URL’sini ve gözlenen sonucu güncelleyin; her değişiklikte yalnızca tek bir faktörü değiştirerek hangi adımın sonucu etkilediğini koruyun.

Bir sonraki güvenli adım, panelinizdeki yedekleme kapsamını açıp dosya, veritabanı ve yapılandırma bileşenlerinin son başarılı tarihlerini aynı belgeye kaydetmektir. Barındırma seçeneklerini karşılaştırmanız gerekiyorsa İyibirNet üzerindeki ilgili hizmet bilgilerini ayrıca inceleyin; kurtarma kapsamını sağlayıcınızdan doğrulamadan planı tamamlanmış kabul etmeyin.