Küçük Web Uygulamaları İçin Felaket Kurtarma Planı Nasıl Hazırlanır?

Felaket kurtarma planı, bir web uygulaması kesildiğinde yalnızca yedeği bulunmasını değil, uygulamanın ne kadar sürede ve hangi veri kaybı sınırıyla yeniden çalışacağını tanımlar. Önce RTO’yu, yani kabul edilebilir en uzun kesinti süresini; RPO’yu, yani kaybedilebilecek en eski veri aralığını belirleyin. Ardından yedekleri farklı bir ortamda saklayıp kontrollü bir geri yükleme testi yapın.

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

Bu rehber, paylaşımlı hosting panelinde çalışan küçük bir web sitesi veya uygulaması ile yönetici erişimi bulunan bir VPS ya da fiziksel sunucu için uygundur. Panelde yedekleme ve veritabanı yönetimi yetkisine, sunucu tarafında ise ilgili işletim sistemi, uygulama ve depolama alanına erişmeniz gerekir. Sağlayıcının otomatik yedekleri hangi sıklıkta aldığı, kaç kopya tuttuğu ve başka bir konumda saklayıp saklamadığı hizmete göre değişebilir; bu bilgileri varsaymayın.

İlk olarak uygulamanın bileşenlerini yazılı hale getirin: alan adı ve DNS kayıtları, uygulama dosyaları, veritabanı, kullanıcı tarafından yüklenen dosyalar, ortam değişkenleri, zamanlanmış görevler ve dış servis bağlantıları. Sadece veritabanını kopyalamak, yüklenen görselleri veya uygulamanın çalışması için gereken yapılandırmayı geri getirmeyebilir. Listeye erişim bilgilerini düz metin olarak eklemek yerine sırların nerede ve nasıl güvenli biçimde yeniden oluşturulacağını belirtin.

RTO ve RPO hedefini iş yüküne göre seçin

Diyelim ki bir randevu uygulamasında gün içinde birkaç saatlik kesinti yönetilebilir, ancak son randevu kayıtlarının kaybolması kabul edilemez. Bu durumda RTO birkaç saat düzeyinde belirlenebilir; RPO ise daha kısa tutulmalıdır ve veritabanı yedeklerinin sıklaştırılması gerekir. Buna karşılık nadiren güncellenen bir tanıtım sitesi için daha uzun RTO ve günlük yedek yeterli olabilir. Hızlı kurtarma hedefi, daha sık kopyalama, hazır kaynak veya daha ayrıntılı test gerektirebileceğinden hedefi teknik imkânla birlikte değerlendirin.

Uygulanabilir bir kurtarma planını adım adım kurun

1. Kritik varlıkları ve sorumluları kaydedin. Uygulama envanterinde her bileşenin sahibi, yedekleme sıklığı, geri yükleme yöntemi ve doğrulama adresi bulunsun. Bir bileşenin sahibi belirsizse önce onu netleştirin; çünkü sorumlu kişi bilinmeyen DNS, ödeme veya e-posta bağlantıları kurtarma sırasında gecikme yaratır.
2. Mevcut yedeklerin kapsamını kontrol edin. Paneldeki yedekleme ekranında veya sağlayıcının bildirdiği yedekleme raporunda tarih, kapsam ve saklama süresini inceleyin. Ayrı bir kopya yalnız aynı sunucuda duruyorsa donanım ya da hesap erişimi sorununda kullanılamayabilir. Yedek veritabanını, dosyaları ve gerekli yapılandırmayı içermiyorsa önce eksik bileşeni ekleyin; tüm sistemi değiştirmek yerine yalnızca eksik kapsamı düzeltin.
3. Yedekleri bağımsız bir hedefe kopyalayın. Sağlayıcının sunduğu başka depolama alanı veya erişimi sınırlandırılmış harici bir hedef kullanılabilir. Kopyalama tamamlandıktan sonra dosyanın tarihini, boyutunu ve bütünlük kontrolünü sağlayıcının desteklediği yöntemle doğrulayın. Kimlik bilgilerini yedeğin yanında açık biçimde saklamayın. Kopya oluşmamışsa planı başarılı kabul etmeyin; önce depolama kotasını, yetkiyi ve ağ aktarımı sonucunu inceleyin.
4. İzolasyonlu bir test ortamı hazırlayın. Geri yüklemeyi canlı sitenin üzerine yazmak yerine geçici bir alan adı, ayrı bir veritabanı ve mümkünse ayrı bir sunucu ya da panel hesabında yapın. Alan adı DNS’ini değiştirmeden uygulamanın geçici adresinden açılabilen bir test düzeni tercih edin. Sağlayıcı bu imkânı sunmuyorsa canlı veriye dokunmadan, yalnızca doğrulanabilir küçük bir kopya üzerinde test yapın; test ortamının üretim sırlarına erişmesini gereksiz yere genişletmeyin.
5. Geri yükleyip işlevsel kontrol yapın. Önce dosyaları, ardından veritabanını ve gerekli yapılandırmayı sağlayıcının önerdiği sırayla geri yükleyin. Sonuçta uygulama açılıyor mu, giriş yapılabiliyor mu, yeni bir deneme kaydı oluşturulabiliyor mu ve mevcut yüklemeler görülebiliyor mu kontrol edin. Uygulama açılıyor fakat veriler eskiyse RPO hedefi karşılanmıyordur; yedek zamanını ve veritabanı kopyasının gerçekten seçilip seçilmediğini inceleyin. Dosya yüklemeleri yoksa medya dizininin veya nesne depolama bağlantısının yedek kapsamına girip girmediğini kontrol edin.
6. Süreyi ve kanıtı kaydedip planı güncelleyin. Yedek seçiminin başladığı, uygulamanın açıldığı ve temel işlemin tamamlandığı saatleri not edin. Başarısız bir geri yüklemede hata ekranının zamanı ile panel raporundaki yeni kaydı eşleştirin. Örneğin kayıt, veritabanı kullanıcısının yetkisi olmadığını gösteriyorsa yalnızca test veritabanında gerekli yetkiyi sağlayıp önceki değeri not edin; aynı geri yükleme işlemini yeniden çalıştırın ve yeni zaman damgalı kaydı kontrol edin. Başarılı sonuç, uygulamanın açılmasının yanında örnek kaydın okunup yazılabildiğini göstermelidir.

Sonuca göre hangi değişikliği yapmalısınız?

Testte yedek bulunuyor ancak geri yükleme hedefinde yer kalmıyorsa sorun yedekleme sıklığı değil kapasitedir; hedef depolamayı büyütmek veya saklama politikasını yeniden düzenlemek gerekir. Yedek geri yükleniyor fakat uygulama dış servise bağlanamıyorsa DNS, API erişimi veya sırların yeniden oluşturulması adımını plana ekleyin. Uygulama yalnızca uzun işlemlerde zaman aşımına uğruyorsa bunu veritabanı bütünlüğü sorunu varsayarak yedekleri değiştirmeyin; uygulama ve sunucu zaman aşımı ayarlarını ayrı bir testte inceleyin.

Bir değişiklik yaptıktan sonra aynı başarısız işlemi, örneğin test veritabanına geri yüklemeyi, yeniden uygulayın ve bu denemeye ait yeni kayıtları önceki sonuçlarla karşılaştırın. Sorun sürüyorsa son değişikliği geri alın; birden fazla ayarı aynı anda değiştirmek hangi düzeltmenin işe yaradığını belirsizleştirir. Canlı veriye yazma riski oluştuğunda testi durdurup izolasyonu yeniden kurun. Plan, belirlenen RTO veya RPO’yu karşılamıyorsa hedefi sessizce gevşetmek yerine yedek sıklığı, bağımsız depolama ve geri yükleme sorumluluğunu yeniden tasarlayın.

Planı ne sıklıkta doğrulamalısınız?

Uygulama, veritabanı şeması, sağlayıcı, depolama hedefi veya erişim yöntemi değiştiğinde geri yükleme testi tekrarlanmalıdır. Değişiklik yokken de belirlediğiniz RPO ve RTO hedeflerinin hâlâ anlamlı olup olmadığını periyodik olarak gözden geçirin. İlk pratik adım, bugün kullandığınız son yedeğin kapsamını listelemek ve canlı sisteme dokunmadan ayrı bir hedefte küçük bir geri yükleme denemesi planlamaktır. Hosting ortamı veya sunucu seçeneklerini karşılaştırırken İyibirNet üzerindeki ilgili bilgileri de ayrıca inceleyebilirsiniz.