Sunucular için Felaket Kurtarma Testi Örneği
31 Ekim 2026 tarihinde yayımlandı
Hiç geri yüklenmemiş bir yedek henüz bir kurtarma planı değildir. Başka bir yerde duran, umut vadeden bir dosyadan ibarettir. Bu felaket kurtarma testi örneği, küçük bir barındırma ekibinin, ajansın veya sunucu sahibinin rutin bir tatbikatı üretim ortamında bir olaya dönüştürmeden gerçekçi bir arızayı nasıl test edebileceğini gösterir.
Amaç basit: İnsanların gerçekten kullandığı hizmetleri, işletmenizin kabul edebileceği bir süre içinde geri yükleyebileceğinizi kanıtlamak. Buna web siteleri, veritabanları, DNS kayıtları, aynı sunucuda barındırılıyorsa e-posta ve kurtarma sonrasında her şeyi yönetmek için gereken erişim dahildir.
Bir felaket kurtarma testi neleri kanıtlamalı
Yararlı bir test, yedekleme işinin tamamlandığını doğrulamaktan daha fazlasını yapar. Pratik soruları yanıtlar: Doğru yedeği bulabiliyor musunuz? Bu yedeği temiz bir sunucuya geri yükleyebiliyor musunuz? Web sitesi düzgün yükleniyor mu? Veritabanı yeterince güncel mi? Yetkili bir ekip üyesi oturum açıp devralabiliyor mu?
İşte burada iki kurtarma hedefi önem kazanır. Kurtarma noktası hedefiniz ya da RPO, ne kadar veri kaybını göze alabileceğinizi belirler. Yedeklemeler her gece çalışıyorsa, bir güne kadar olan değişiklikleri kaybedebilirsiniz. Kurtarma süresi hedefiniz ya da RTO, bir hizmetin ne kadar süre kullanılamayabileceğini belirler. Kişisel bir portföy sitesi birkaç saatlik kesintiyi tolere edebilir. Sipariş alan bir çevrimiçi mağaza ise muhtemelen bunu tolere edemez.
Bu hedefleri tatbikattan önce belirleyin. Aksi takdirde geri yükleme, işletmenin hizmete bir saat içinde yeniden ihtiyaç duyduğu hâlde altı saat sürmüş olsa bile, sonunda başarıyla tamamlandığı için başarılı görünebilir.
Felaket kurtarma testi örneği: Arızalanan bir web sunucusu
Bir Linux sunucusunda 25 müşteri web sitesini barındıran bir ajans düşünün. Sunucuda günlük tam yedeklemeler, dört saatte bir veritabanı yedeklemeleri yapılmakta ve yedekler üretim sunucusunun dışında tutulmaktadır. Pazartesi sabahı bir disk arızası sunucuyu kullanılamaz hâle getirir.
Test sırasında üretim sunucusunun fişini çekmeyin. Ayrı bir kurtarma sunucusunda veya yalıtılmış bir sanal makinede kontrollü bir simülasyon oluşturun. İlk tatbikat için 25 sitenin tamamı yerine temsili bir web sitesi seçin. Veritabanı, medya yüklemeleri, SSL, zamanlanmış görevler ve gerçek bir yönetici oturum açma bilgisi olan bir site seçin. Basit bir statik sayfa, bir şeyi kanıtlamak için fazla kolaydır.
Test senaryosu şöyle yazılabilir:
Olay: Disk arızası nedeniyle üretim sunucusu kalıcı olarak kullanılamıyor.
Kurtarma hedefi: Seçilen web sitesini ve veritabanını, en fazla dört saatlik veri kaybıyla 90 dakika içinde yedek bir sunucuya geri yüklemek.
Başarı ölçütleri: Web sitesi geçici bir ana makine adı veya hosts dosyası testi üzerinden erişilebilir olmalı, sayfalar HTTPS üzerinden yüklenmeli, yönetim alanında oturum açılabilmeli, güncel içerik bulunmalı, yüklenen dosyalar görüntülenmeli, formlar düzgün gönderilmeli, zamanlanmış görevler çalışmalı ve sunucu günlüklerinde kritik uygulama hataları olmamalıdır.
Bu odaklı bir testtir, ancak genellikle gecikmelere yol açan unsurları ortaya çıkarır: eksik kimlik bilgileri, tamamlanmamış yedeklemeler, DNS varsayımları, sürüm uyuşmazlıkları ve net olmayan sorumluluklar.
Testten önce kurtarma sürecini görünür hâle getirin
Bir kurtarma testi, iki yıl önceki komutları hatırlayan tek bir kişiye bağlı olmamalıdır. Yedeklerin nerede bulunduğunu, bunlara nasıl erişileceğini, DNS değişikliklerini kimin onaylayabileceğini ve hangi hizmetlerin önce geri getirilmesi gerektiğini yazılı hâle getirin.
Yedekleme depolama alanınızın üretim sunucusundan ayrı olduğunu doğrulayın. Yalnızca web siteleriyle aynı diskte saklanan yedekler, yanlışlıkla dosya silinmesi durumunda işe yarar; ancak sunucu kaybından sonra pek yardımcı olmaz. Ayrıca kurtarma kimlik bilgilerinin, arızalanan sunucuya bağlı kalmadan kullanılabildiğini doğrulayın. Buna yedekleme depolama alanına, alan adı kayıt kuruluşuna ve DNS sağlayıcısına erişim, SSH anahtarları, lisans bilgileri ve gereken uygulama gizli anahtarları dahildir.
Bir sunucu paneli kullanıyorsanız teknik ayarların yanı sıra tıklama adımlarını da belgeleyin. Bu bir kestirme yol değildir. Olay gerçekleştiğinde müsait olan kişinin kurtarma işlemini tekrarlanabilir biçimde gerçekleştirebilmesini sağlar. FASTPANEL; web sitelerini, veritabanlarını, yedeklemeleri ve sunucu ayarlarını yönetilebilir tek bir yerde tutmaya yardımcı olabilir, ancak test için yine de net sorumluluklar ve kanıtlar gerekir.
Tatbikatı güvenli bir sırayla yürütün
Ekip simüle edilmiş olay bildirimini aldığında kronometreyi başlatın. Süreyi, her işlemi kimin yaptığını ve ilerlemeyi engelleyen kararları kaydedin. Bu notlar, sırf evrak işi olsun diye tutulan kayıtlar değil, test sonucunun bir parçasıdır.
Önce kurtarma ortamını hazırlayın. İşletim sistemini ve gereken çalışma zamanı sürümlerini mümkün olduğunca eşleştirin. Birebir kopyalama her zaman gerekli değildir; ancak işletim sistemini, PHP sürümünü, veritabanı sürümünü ve web sunucusu yapılandırmasını aynı anda değiştirmek sorun gidermeyi zorlaştırır. Kurtarma ortamı farklıysa bu farkı belgeleyin.
Ardından seçilen yedeği alın ve tarihini doğrulayın. Web sitesi dosyalarını ve veritabanını geri yükleyin, ardından bağlanması için uygulamanın ihtiyaç duyduğu yapılandırma değerlerini ekleyin. Yapılandırma dosyalarının her şeyi içerdiğini varsaymayın. Birçok uygulama; web sitesi dizininin dışında bulunan ortam değişkenlerine, API anahtarlarına, e-posta ayarlarına, cron işlerine veya izinlere bağlıdır.
Geri yüklenen siteyi geçici bir URL, hazırlık alanı için kullanılan bir alan adı veya yerel bir hosts dosyası girdisi üzerinden çevrimiçi hâle getirin. Sitenin çalıştığından emin olana kadar genel DNS kayıtlarını kurtarma sunucusuna yönlendirmeyin. Ana sayfayı, birkaç iç sayfayı, görselleri, formları, hesap oturum açma işlemini ve yönetim alanını kontrol edin. WordPress sitesi için kalıcı bağlantıları, eklentileri, yüklemeleri ve zamanlanmış yayınları da kontrol edin.
Ardından siteyle ilişkili hizmetleri inceleyin. SSL sertifikasının yüklenebildiğini veya yenilenebildiğini, giden e-postanın beklendiği gibi yapılandırıldığını, zamanlanmış görevlerin mevcut olduğunu ve veritabanı kullanıcılarının yalnızca ihtiyaç duydukları erişime sahip olduğunu doğrulayın. Ana sayfanın başarıyla yüklenmesi iyi bir başlangıçtır, ancak bitiş çizgisi değildir.
Yedek sunucuya geçiş kararını da test edin
Teknik geri yükleme, felaket kurtarmanın yalnızca yarısıdır. Diğer yarısı, trafiğin yedek sunucuya ne zaman ve nasıl taşınacağına karar vermektir.
Bu tatbikatta, geri yüklenen site kontrolleri geçtikten sonra bir DNS değişikliğini simüle edin. Yalnızca internet genelindeki DNS yayılımının ne kadar sürdüğünü değil, değişikliği hazırlayıp duyurmanın ne kadar zaman aldığını ölçün. Daha düşük DNS TTL değerleri bekleme süresini azaltabilir, ancak kesinti yaşanmadan önce planlanmalıdır. Mevcut çözümleyiciler eski değeri önbelleğe almış olabileceğinden, olay sırasında TTL değerini değiştirmek genellikle hemen fayda sağlamaz.
Kurulumunuz yük dengeleyici, ters vekil sunucu veya bulut tabanlı bir yedek sunucuya geçiş hizmeti kullanıyorsa, yalnızca DNS'yi değil bu mekanizmayı test edin. Doğru yaklaşım mimarinize bağlıdır. Birkaç iş sitesine sahip tek bir sunucu, DNS üzerinden gayet iyi kurtarılabilir. Bir barındırma sağlayıcısı veya yüksek işlem hacmine sahip bir mağaza için daha hızlı bir yedek sunucuya geçiş tasarımı ve kullanıma hazır durumda tutulan ikincil bir ortam gerekebilir.
İşe yarar sonuçları kaydedin
Tatbikatın sonunda yalnızca “geri yükleme başarılı” yazmayın. Gerçek kurtarma süresini, yedeğin ne kadar eski olduğunu, başarısız kontrolleri ve gereken manuel adımları kaydedin. Rakamları RTO ve RPO hedeflerinizle karşılaştırın.
Örneğin ekip web sitesini 52 dakikada geri yükleyebilir, ancak en güncel veritabanı yedeğinin altı saatlik olduğunu fark edebilir. Sunucunun kurtarılması 90 dakikalık RTO hedefini karşılarken veri kurtarma, dört saatlik RPO hedefini karşılamamıştır. Bu yine de değerli bir sonuçtur; çünkü belirli bir çözümü işaret eder: veritabanı yedekleme sıklığını artırmak veya uygun durumlarda işlem düzeyinde koruma eklemek.
Sık rastlanan bulgular arasında eksik yedek saklama politikası, test edilmemiş kimlik bilgileri, yüklenen dosyaları kapsamayan yedekler, uyumsuz yazılım sürümleri ve DNS erişiminin tek bir çalışanın hesabına bağlı olması yer alır. Önce en yüksek riskli sorunu giderin, bir sorumlu belirleyin ve son tarih koyun. Takip yapılmayan bir test, aynı sorunun provası olmaktan öteye geçmez.
Ne sıklıkla test etmelisiniz?
Çoğu küçük işletme için üç ayda bir yapılan kurtarma testi, uygulanabilir bir başlangıç noktasıdır. Sunucu taşıma, yeni bir yedekleme sağlayıcısına geçiş, veritabanı yükseltmesi, uygulamanın yeniden tasarlanması veya altyapıyı yöneten kişilerin değişmesi gibi önemli değişikliklerden sonra daha sık test yapın.
Test kapsamını dönüşümlü olarak değiştirin. Bir çeyrekte kritik öneme sahip tek bir web sitesini ve veritabanını geri yükleyin. Sonraki çeyrekte sunucunun tamamını yeniden kurmayı test edin. Daha sonra bir hesap erişimi arızasını veya yanlışlıkla silme senaryosunu test edin. Farklı arızalar farklı zayıf noktaları ortaya çıkarır; yararlı bir şey öğrenmek için her seferinde ortalığı mümkün olduğunca karıştırmanız gerekmez.
En iyi felaket kurtarma planı, ekibinizin önündeki bilgilerle sakin bir şekilde uygulayabildiği plandır. Bu test akıllardan silinmeden bir sonrakini planlayın; ardından her seferinde kurtarma sürecini biraz daha kısaltıp netleştirin.