İçeriğe atla
Bilgi Merkezi/Makale
Makale

Felaket Kurtarma (Disaster Recovery) Nedir, Nasıl Planlanır?

Felaket kurtarma, felaketten sonra BT sistemlerini ve veriyi geri getirir. Yedeklemeden farkını, yedek merkez türlerini, DRaaS'ı ve DR planını anlattık.

Oğuzhan Gerçek··7 dk okuma
Felaket Kurtarma (Disaster Recovery) Nedir, Nasıl Planlanır?

Kısa cevap: Felaket kurtarma (disaster recovery, DR), yangın, deprem, büyük bir donanım arızası, siber saldırı ya da insan hatası gibi bir olaydan sonra BT sistemlerini ve veriyi geri getirme yeteneğidir. Başarısı iki hedefle ölçülür: sistemin en geç ne zaman yeniden çalışacağı (RTO) ve en fazla ne kadar verinin kaybedilebileceği (RPO). Yedekleme felaket kurtarmanın bir parçasıdır; yüksek erişilebilirlik ise onun yerini tutmaz, çünkü silinen ya da bozulan veriyi ikinci kopyaya da taşır. İyi bir DR planı rolleri, felaket ilanını, failover ve geri dönüş adımlarını yazar ve düzenli testle doğrulanır.

Felaket kurtarma nedir?

Google Cloud'un tanımıyla felaket kurtarma, bir kurumun doğal ya da insan kaynaklı bir felaketten sonra BT altyapısına erişimi ve altyapının işlevini geri getirebilme yeteneği. AWS felakete deprem ve yangını, teknoloji arızalarını, insan hatasını ve üçüncü tarafların yetkisiz erişimini örnek veriyor.

ABD Ulusal Standartlar ve Teknoloji Enstitüsünün (NIST) beklenmedik durum planlama rehberi SP 800-34 Rev. 1, felaket kurtarma planını (DRP) bilgi sistemlerini büyük bir donanım ya da yazılım arızasından veya tesisin yıkılmasından sonra alternatif bir tesiste geri getirmek için yazılmış plan olarak tanımlıyor. Kısa tanımı sözlüğümüzde bulabilirsiniz.

Yedekleme, yüksek erişilebilirlik ve iş sürekliliğinden farkı

Bu dört kavram sık karıştırılıyor:

  • Yedekleme: Google Cloud'a göre felaket kurtarmanın bir bileşeni. Yedekleme verinin kopyalanmasına ve geri getirilmesine odaklanır; felaket kurtarma ise BT sistemlerini ve iş operasyonlarını geri getirmenin bütün stratejisidir. Yedek türlerini yedekleme yazımızda anlattık.
  • Yüksek erişilebilirlik (high availability, HA): AWS'ye göre erişilebilirlik iş yükünün bileşenlerine, felaket kurtarma ise iş yükünün bütününün ayrı kopyalarına bakar. Sürekli replikasyon yapan bir depolamada silinen ya da bozulan dosya ikinci kopyaya da yansır; DR stratejisi bu yüzden bir zaman noktası (point-in-time) yedeği de ister. Erişilebilirliğin ölçümü uptime yazımızın konusu.
  • İş sürekliliği: Google Cloud felaket kurtarmayı iş sürekliliğinin BT sistemlerine odaklanan alt kümesi sayıyor; AWS de DR planının iş sürekliliği planının parçası olmasını istiyor. İnsanları, süreçleri ve tedarikçileri de kapsayan çerçeveyi iş sürekliliği yazımızda anlattık.

RPO ve RTO: felaket kurtarmanın iki hedefi

AWS'nin tanımlarıyla:

  • RTO (recovery time objective): Hizmetin kesilmesiyle yeniden sağlanması arasında kabul edilebilecek en uzun gecikme.
  • RPO (recovery point objective): Son kurtarma noktasından bu yana geçmesine izin verilen en uzun süre; yani göze alınan veri kaybı.

Google Cloud'un planlama rehberine göre RTO ve RPO küçüldükçe uygulamayı çalıştırmanın maliyeti genellikle artar. Bu yüzden hedef her sistem için ayrı konur; iş maliyetinden nasıl türetildiğini RPO ve RTO nasıl hesaplanır yazısında verdik.

Sıcak, ılık ve soğuk yedek merkez

Kurtarmanın yapıldığı ikinci lokasyona felaket kurtarma merkezi (FKM) denir. NIST SP 800-34 yedek merkezleri hazırlık durumuna göre ayırıyor:

  • Soğuk (cold site): Elektrik, iletişim ve iklimlendirme altyapısı var, bilgi işlem donanımı yok; donanım felaketten sonra getirilir.
  • Ilık (warm site): Sistem donanımının, yazılımının ve iletişim altyapısının bir kısmı ya da tamamı kuruludur.
  • Sıcak (hot site): Donanımı ve yazılımıyla tam çalışır durumda bekler.
  • Ayna (mirrored site): Tümüyle yedeklidir; veri gerçek zamanlı ve otomatik olarak yansıtılır.

Google Cloud farkı bir lastik benzetmesiyle anlatıyor: soğuk modelde stepne yoktur ve birinin yeni lastik getirmesi beklenir, ılık modelde stepne ve takım hazırdır, sıcak modelde araç run-flat lastikle yoluna devam eder.

Bulutta aynı kademeler AWS'nin sınıflandırmasında dört stratejiye karşılık geliyor:

  • Backup and restore: En ucuz ve en basit yol; sistem felaketten sonra yedekten kurulur.
  • Pilot light: Veri sürekli kopyalanır, çekirdek altyapı hazır bekler; uygulama sunucuları felaket anında açılır.
  • Warm standby: İş yükü ikinci bölgede azaltılmış kapasiteyle zaten çalışır ve trafiği hemen karşılar.
  • Multi-site active/active: Trafik bütün bölgelerden karşılanır ve kurtarma süresi çoğu felakette sıfıra yaklaşır; en karmaşık ve en pahalı seçenek de budur.

DRaaS: hizmet olarak felaket kurtarma

Google Cloud'a göre DRaaS'ta veri ve BT altyapısı üçüncü taraf bir sağlayıcının bulutunda yedeklenip barındırılır; kriz anında DR planını sağlayıcı uygular. Bulut platformlarının kurtarma hizmetleri de benzer çalışır: Azure Site Recovery iş yüklerini birincil lokasyondan ikincil bir lokasyona replike eder; kesintide oraya failover yapılır, birincil lokasyon düzelince geri dönülür.

DRaaS ikinci tesisi işletme yükünü sağlayıcıya taşır, planın sahipliğini değil: Microsoft, DR planında ekibinizle sağlayıcı arasındaki sorumlulukların tanımlanmasını istiyor. Kendi FKM'nizi kurmakla DRaaS arasındaki kararı kurumsal felaket kurtarma stratejisi yazısında, kurgunun nasıl işletildiğini felaket kurtarma mühendisliği sayfamızda anlattık. Terimin kısa tanımı sözlükte.

Felaket kurtarma planı neleri içerir?

NIST SP 800-34 planı üç aşamaya ayırıyor: planın devreye alınıp kurtarma ekibine haber verildiği etkinleştirme ve bildirim; sistemin alternatif bir lokasyonda ya da yedek imkânlarla çalıştırıldığı kurtarma; sistemin sınanıp normal işleyişe döndürüldüğü yeniden yapılandırma (reconstitution). Microsoft'un Well-Architected rehberine göre planda en az şunlar yazılı olmalı:

  • Felaketi ilan edecek, olayı kapatacak, test ve doğrulamayı yürütecek kişiler; eskalasyon yolları
  • Tam bir felaketi, büyük bir kesintiyi ve hızla düzeltilebilecek küçük bir sorunu ayıran ölçüt
  • Ön koşullarıyla (script, kimlik bilgisi, yapılandırma) adım adım failover talimatı
  • Failover sonrası işler: DNS güncellemesi, trafik yönlendirmesi, bağlantı dizesi (connection string) değişikliği
  • Ayrı bir süreç olarak geri dönüş (failback); Microsoft'a göre hemen ya da günler, haftalar içinde yapılabilir

Google Cloud her adımın somut ve tek anlamlı komut ya da eylemlerden oluşmasını öneriyor; "geri yükleme script'ini çalıştır" gibi bir talimatı fazla genel buluyor.

Felaket kurtarma testi

NIST'e göre test, planın bileşenlerini ölçülebilir göstergelerle doğrular. Rehberin örnek test alanları bildirim prosedürleri, sistemin yedekten alternatif bir platformda kurtarılması, iç ve dış bağlantılar ve normal işleyişe dönüş. AWS planın yılda en az bir ya da iki kez test edilmesini, Microsoft ise ideal olarak altı ayda bir gözden geçirilmesini öneriyor. Microsoft planın masa başı tatbikatları, üretim dışı provaları ve üretimde yapılan tatbikatları birlikte kapsamasını istiyor; RTO ve RPO hedeflerinin gerçek koşullarda tutup tutmadığını ise yalnızca üretimdeki tatbikat gösteriyor.

Testin adım adım nasıl kurulacağını ve geri dönüşün neden ayrıca prova edilmesi gerektiğini felaket kurtarma testi yazısında anlattık.

Fidye yazılımı senaryosu

Fidye yazılımında sorun tesisin ya da donanımın kaybı değil, verinin şifrelenmesidir. Yalnızca replikasyona dayanan bir kurgu bu yüzden yetmez: AWS'nin uyarısıyla bozulan veri ikinci kopyaya da yansır. CISA'nın #StopRansomware rehberi hazırlık ve kurtarma için şunları öneriyor:

  • Kritik verinin çevrim dışı ve şifreli yedeklerini tutmak; erişilebilirliklerini ve bütünlüklerini bir felaket kurtarma senaryosunda düzenli olarak test etmek
  • Sistemleri kritik hizmetlerin önceliğine göre yeniden kurmak ve veriyi aynı sırayla çevrim dışı yedeklerden geri yüklemek
  • Yedekten yeniden kurmadan önce zararlı yazılım bırakıcılarını (dropper) tespit etmek ve temiz sistemlere yeniden bulaşmayı önlemek

Doğru kurtarma noktasının değiştirilemez yedek ve journal ile nasıl seçildiğini fidye yazılımı kurtarma planı yazısında anlattık. Yedeklerin işletimini yedekleme, replikasyon ve kurtarma, verinin korunmasını veri koruma ve kurtarma hizmetlerimizde ele alıyoruz.

Sık sorulan sorular

Disaster recovery ne demek? Felaket kurtarma demek: bir felaketten sonra BT sistemlerinin ve verinin geri getirilmesi. Kısaltması DR.

DR planı nedir? Bilgi sistemlerinin büyük bir arızadan ya da tesis kaybından sonra nasıl geri getirileceğini anlatan yazılı plandır. Rolleri, felaket ilanını, failover ve geri dönüş adımlarını içerir.

Felaket kurtarma ile yedekleme arasındaki fark nedir? Yedekleme verinin kopyasını saklar ve felaket kurtarmanın bir parçasıdır. Felaket kurtarma ise sistemleri, ağı ve uygulamaları da çalışır hâle getirmeyi kapsar.

Felaket kurtarma ile iş sürekliliği aynı şey mi? Hayır. Felaket kurtarma BT sistemlerine odaklanır; iş sürekliliği insanları, süreçleri ve tedarikçileri de kapsar. DR planı, iş sürekliliği planının bir parçasıdır.

DRaaS nedir? Hizmet olarak felaket kurtarma demek. Veri ve altyapı bir sağlayıcının bulutunda yedeklenir, kriz anında kurtarmayı sağlayıcı yürütür.

Kaynaklar