Felaket Kurtarma

FELAKET VE İŞ SÜREKLİLİĞİ

Disaster, bir siber saldırıdan elektrik kesintilerine ve ekipman arızalarına, doğal afetlere kadar bir kuruluşun operasyonlarını riske atan herhangi bir şey olabilir. DR’nin amacı, bir işletmenin mümkün olduğunca normale yakın çalışmaya devam etmesidir. Olağanüstü durum kurtarma işlemi, planlama ve test etmeyi içerir ve işlemleri geri yüklemek için ayrı bir fiziksel yedekleme sistemi içerebilir. Bir acil durum iletişim planı kontak personeli ve ilgili acil müdahale personeli için gereken düzenlemeleri sağlar ve güncel tutmak, bir felaket kurtarma stratejisinin bir parçasıdır.

Modern felaket kurtarma, teorik bir felaket planlamaya fon yatırımı yapmaktan kaçınan küçük kuruluşlar için daha bütçeye uygun yollar da dahil olmak üzere çok sayıda seçeneğe sahiptir. Felaket kurtarma planlaması henüz gerçekleşmemiş yıkıcı bir olay etrafında toplanmış olsa da, üzülmektense güvende olmak ve bir strateji uygulamak genellikle daha iyidir. Aksi takdirde, organizasyon kritik bir anda bir plan olmadan yakalanma riskiyle karşı karşıyadır.

Olağanüstü durum kurtarma planının unsurları

Olağanüstü durum kurtarma planları, kuruluşa ve sektöre göre, farklı uyumluluk gereksinimleri ve beklentileriyle farklılık gösterir. Ancak, planların takip etmesi gereken genel bir taslak vardır.

Mikron Bilgisayara göre, bir DR planında ihtiyaç duyulan bileşenler şunları içerir:

  • Olağanüstü durum kurtarma politikası beyanı, plan genel görünümü ve planın ana hedefleri.
  • Kilit personel ve DR ekibi iletişim bilgileri.
  • Bir olayın hemen ardından afet müdahale eylemlerinin açıklaması.
  • Tüm ağın ve kurtarma sisteminin bir diyagramı.
  • Kurtarma sistemine nasıl ulaşılacağına ilişkin talimatlar.
  • Kurtarma sırasında yöneticilerin kullanacağı yazılım ve sistemlerin listesi.
  • Satıcıların teknik belgeleri de dahil olmak üzere çeşitli teknoloji geri kazanımları için örnek şablonlar.
  • Medya ile başa çıkmak için ipuçları.
  • Sigorta kapsamı özeti.
  • Mali ve hukuki sorunların ele alınması için önerilen eylemler.
  • Planın tamamlanmasına yardımcı olmak için kullanıma hazır formlar.

Mikron Bilgisayara göre, geliştirme ekibi DR planını oluştururken aşağıdaki faaliyetleri içermelidir:

  • Planın kapsamını belirlemek için iç teknoloji ekibi ve ağ yöneticisi ile görüşün ve ardından toplantıda üst yönetim hakkında kısa bilgi verin.
  • İlgili tüm ağ altyapısı belgelerini toplayın.
  • Altyapıya yönelik en ciddi tehditleri ve güvenlik açıklarını belirleyin.
  • Önceki kesintiler ve aksaklıklar geçmişini ve işletmenin bunları nasıl ele aldığını gözden geçirin.
  • En kritik BT varlıklarını belirleyin ve maksimum kesinti sürelerini belirleyin.
  • Afet müdahale ekibini ve yeteneklerini belirleyin.
  • Yönetimin planı gözden geçirmesini sağlayın.
  • Planı test edin ve gerekirse güncelleyin.
  • Olağanüstü durum kurtarma yeteneklerinin bir sonraki gözden geçirilmesini / denetlenmesini zamanlayın.

Bir kuruluş, olağanüstü durum kurtarma planını yaşayan bir belge olarak değerlendirmelidir. DR planının doğru olduğundan emin olmak için planlanmış incelemelere ve güncellemelere ihtiyacı vardır ve kurtarma gerekiyorsa çalışır. Plan, işletmede olağanüstü durum kurtarmayı etkileyebilecek değişiklikler olduğunda da güncellenmelidir.

 

Olağanüstü durum kurtarma ve iş sürekliliği arasındaki fark

İş sürekliliği ve olağanüstü durum kurtarma ( BC / DR ) genellikle el ele gider, ancak örtüşmeye rağmen aynı değildir. Hem iş sürekliliği hem de olağanüstü durum kurtarma, bir veri koruma stratejisinde kilit rol oynar ve kendi gereksinimleri ve stratejileriyle birlikte gelir.

Olağanüstü durum kurtarma, bir kuruluşun bir aksama veya başarısızlıktan sonra ayağa kalkmasına odaklansa da, iş sürekliliği planlaması bir olağanüstü durum meydana geldiğinde işleri devam ettirmeye odaklanır. Uygun bir iş sürekliliği planına sahip olmak için, uyumluluk gerekliliklerinden (eğer kuruluşun hazır bulunması gereken verilerden sorumlu olması durumunda), işletmenin itibarını korumaya kadar birçok motivasyon vardır. Doğal afet gibi kaçınılmaz bir şey beklenen kesinti süresi anlamına gelse de daha az kesinti süresi daha iyidir. Bir kuruluş bir siber saldırıya uğrayacak kadar şanssızsa, zaten kaybedilen bir güvenle uğraşacak, bu nedenle kesinti süresi daha az kabul edilebilir.

Hem felaket kurtarma hem de iş sürekliliği sadece teknik sorunlar için değil, fiziksel konular için de planlama içerir. Bir veri merkezi yıkıcı bir olaya maruz kalırsa, BC / DR planları, bir olay sırasında ve gerçekleştikten sonra, birincil konumun onarım için zamana ihtiyacı varsa, personel için potansiyel uzak çalışma yerleri ve prosedürleri içermelidir.

Tüm kuruluşlar felaketten kurtarma ile ilgilenmelidir, ancak bir iş sürekliliği planı da yüksek öncelikli olarak değerlendirilmelidir.

 

Olağanüstü durum kurtarmanın önemi: RPO ve RTO

İşletmeler yüksek kullanılabilirliğe daha fazla bağımlı hale geldikçe, kapalı kalma süresine tolerans azalmıştır.

Bir felaket bir işletme üzerinde yıkıcı bir etkiye sahip olabilir. Araştırmalar, birçok işletmenin önemli bir veri kaybı yaşadıktan sonra başarısız olduğunu göstermiştir, ancak DR yardımcı olabilir.

Kurtarma noktası hedefi ( RPO ) ve kurtarma süresi hedefi ( RTO ), olağanüstü durum kurtarma ve kesinti süresinde iki önemli ölçümdür.

RPO, bir felaketten sonra normal işlemlerin devam edebilmesi için bir kuruluşun yedekleme deposundan kurtarması gereken dosyaların maksimum yaşıdır. Kurtarma noktası hedefi, minimum yedekleme sıklığını belirler. Örneğin, bir kuruluşun dört saatlik bir RPO’su varsa, sistem en az dört saatte bir yedeklemelidir.

RTO, bir kuruluşun bir kuruluştan ofis dışı ve yerel yedek depolama alanından dosyaları kurtarması ve normal işlemlere devam etmesi için gereken en uzun süredir. Başka bir deyişle, iyileşme süresi hedefi, bir kuruluşun üstesinden gelebileceği maksimum kesinti süresidir. Bir kuruluşun iki saatlik RTO’su varsa, dosya kurtarma işlemi bundan daha uzun süremez.

RPO ve RTO, yöneticilerin en iyi felaket kurtarma stratejilerini, teknolojilerini ve prosedürlerini seçmelerine yardımcı olur.

Daha sıkı RTO pencerelerini karşılamak, yöneticilerin daha hızlı erişebilmesi için ikincil verilerin konumlandırılmasını gerektirir . Yerinde kurtarma , verileri daha hızlı geri yüklemenin bir yöntemidir. Bu teknoloji, yedekleme verilerini yedekleme cihazında canlı bir duruma taşıyarak verilerin ağ üzerinde taşınması gereğini ortadan kaldırır. Depolama sistemine ve sunucu hatalarına karşı koruma sağlayabilir. Yerinde kurtarma kullanmadan önce, bir kuruluş disk yedekleme cihazının performansını, verileri yedekleme durumundan canlı duruma ve geri dönmeye taşımak için gereken süreyi dikkate almalıdır. Yerinde kurtarma 15 dakikaya kadar sürebileceğinden, bir kuruluşun daha hızlı bir kurtarma süresi istiyorsa çoğaltma yapması gerekebilir.

Bir felakete hazırlanmak, DR’nin RTO ve RPO hedefleri içinde gerçekleştirilmesini sağlayan donanım ve yazılım, ağ ekipmanı, güç, bağlantı ve testleri kapsayan kapsamlı bir yaklaşım gerektirir. Kapsamlı bir DR planı uygulamak küçük bir görev olmamasına rağmen, potansiyel faydalar önemlidir.

Olağanüstü durum kurtarma planlaması ve stratejisi

Olağanüstü durum kurtarma planı, bir kuruluşun donanım ve yazılım, ağlar, prosedürler ve insanlar dahil olmak üzere BT altyapısını tehdit eden planlanmamış olaylara yanıt vermek için yapılandırılmış bir yaklaşım sağlar.

Plan, operasyonlar üzerindeki olumsuz etkileri en aza indirmek için kesintiye uğramış sistemleri ve ağları kurtarmak için adım adım olağanüstü durum kurtarma stratejileri sunar. Bir risk değerlendirmesi, BT altyapısına yönelik olası tehditleri tanımlar; DR planı, kuruluş için en önemli unsurların nasıl kurtarılacağını açıklar.

Olağanüstü durum kurtarma testi

Test, DR planlamasında yönetimin değiştirilmesi, boşlukların belirlenmesine ve bir kriz durumunda eylemlerin prova edilmesi için bir şans sağlanmasında kritik öneme sahiptir . Bir DR planında çok sayıda hareketli parça vardır, bu nedenle test edilmesi kuruluşun olağanüstü durum kurtarma senaryoları sırasında çalışanların tam olarak ne yapması gerektiğini anlamasına yardımcı olabilir.

BC Test Şablonu

Bir kuruluşun olağanüstü durum kurtarma politikasını test etmek için bir programı olmalı ve ne kadar müdahaleci olduğuna dikkat etmelidir. DR testi çok sık personel üzerinde boşaltılabilir, ancak daha az sıklıkta yapılan organizasyonlar genellikle testi daha da geciktirir. Ayrıca, bir kuruluş herhangi bir sistem değişikliğinden sonra DR planını test etmelidir.

Test etmenin bir yolu bir süre afet modunda çalışmaktır; örneğin, kurtarma sistemine geçmemek, sistemlerin bir hafta orada çalışmasına izin vermek ve sonra geri dönmek.

Olağanüstü durum kurtarma testinden en iyi şekilde yararlanmanın yolları şunlardır:

  • Test için güvenli yönetim onayı ve finansmanı.
  • Test hakkında ayrıntılı bilgi verin.
  • Test ekibinin tamamının planlanan test tarihinde bulunduğundan emin olun.
  • Testinizin diğer zamanlanmış testlerle veya etkinliklerle çakışmadığından emin olun.
  • Test komut dosyalarının doğru olduğunu onaylayın.
  • Test ortamının hazır olduğunu doğrulayın.
  • Testin kuru çalışmasını programlayın.
  • Gerekirse testi durdurmaya hazır olun.
  • Not alın.
  • Neyin işe yarayıp neyin başarısız olduğuna ilişkin bir işlem sonrası raporunu doldurun.
  • DR planını güncellemek için test sonuçlarını kullanın.

Kapsamlı bir felaket kurtarma testi yapmak en uygun yöntem olsa da, bu, finansman, zaman veya kaynak eksikliği nedeniyle her zaman mümkün olmayabilir. Bu durumda, bir kuruluş yine de kilit katılımcıları bir araya getirmeli, ilgili tüm belgeleri dağıtmalı ve testin gözden geçirilmesini gerçekleştirmelidir. Bu ölçeklendirilmiş DR testi yaklaşımı için riskler vardır, çünkü kapsamlı bir şekilde test edilmemiş teknoloji gerektiğinde düzgün çalışmayabilir.

Hizmet olarak bulut felaket kurtarma / felaket kurtarma

Hizmet olarak olağanüstü durum kurtarma ( DRaaS ), son yıllarda popülerlik kazanan bulut tabanlı bir DR yöntemidir.

DRaaS’ın pozitifleri arasında daha düşük maliyet, daha kolay dağıtım ve planları düzenli olarak test etme yeteneği bulunur. Bulut depolama hizmetleri, paylaşılan bir altyapı üzerinde çalışarak kuruluştan tasarruf sağlar. Kuruluşlar sadece ihtiyaç duydukları hizmetlere kaydolabildikleri için daha esnektirler. DR testleri, geçici örneklerin döndürülmesiyle tamamlanabilir.

Ancak büyük çaplı bir felaketten sonra bulut tabanlı felaket kurtarma, DR uygulamasında her uygulamayı çalıştıracak kadar yer olmayabilir. Cloud DR ayrıca bant genişliği ihtiyaçlarını artırır ve daha karmaşık sistemlerle ağ performansını düşürebilir. Maliyetler, bazıları ağ bant genişliği tüketimine veya depolama tüketimine dayalı ücretler olmak üzere satıcılar arasında büyük ölçüde farklılık gösterir ve hızlı bir şekilde artabilir.

Bir sağlayıcı seçmeden önce , bir kuruluş felaket kurtarma ihtiyaçlarını belirlemek için bir iç değerlendirme yapmalıdır. Potansiyel bir DRaaS sağlayıcısına sorulacak sorular şunları içerir:

  • DRaaS mevcut altyapıya göre çalışacak mı? Ürün mevcut yedekleme ve DR platformlarıyla nasıl entegre olacak?
  • Bölgesel bir felaket sırasında sağlayıcının müşterilerinin yüzde kaçı aynı anda desteklenebilir?
  • Sağlayıcı bir olağanüstü durum kurtarma hizmeti sağlayamazsa ne olur?
  • Kullanıcılar dahili uygulamalara nasıl erişecek?
  • Bir müşteri bir felaketten sonra ne kadar süre sağlayıcının veri merkezinde çalışabilir? Yeniden çalışma prosedürleri nelerdir?
  • Bir felaket sırasında sağlayıcıdan ne kadar yardım beklenebilir?
  • Test süreci nedir?
  • Ürün ölçeklenebilirlik sunuyor mu?
  • Sağlayıcı olağanüstü durum kurtarma hizmeti için nasıl ücret alıyor?

Çoğu bulut kurtarma durumunda, bir kuruluş kriz çözülür çözülmez iş yüklerini orijinal yerine geri almayı planlamalıdır. Ancak, bazı DRaaS sağlayıcıları otomatik geri dönüşü desteklemez.

Olağanüstü durum kurtarma sistemleri: Sıcak, sıcak ve soğuk

Bir DR sisteminde bir kuruluş, birincil veri merkezi bulunmadığında teknoloji altyapısını ve işlemlerini kurtarabilir ve geri yükleyebilir. DR sistemleri dahili veya harici olabilir.

Bir kuruluş dahili bir olağanüstü durum kurtarma sistemi oluşturur ve bakımını yapar. Büyük bilgi gereksinimleri ve agresif RTO’ları olan kuruluşların, genellikle ikinci bir veri merkezi olan dahili bir DR sistemi kullanma olasılığı daha yüksektir. Dahili bir saha inşa etmedeki hususlar arasında donanım konfigürasyonu, destek ekipmanı, güç bakımı, alanın ısıtılması ve soğutulması, düzen tasarımı, konum ve personel bulunmaktadır. Bir kuruluş, kurtarma sisteminin birincil veri merkeziymiş gibi bir risk değerlendirmesi yapmak isteyebilir.

Dahili sistem seçeneği genellikle harici bir sistemden çok daha pahalıdır, ancak önemli bir avantaj, olağanüstü durum kurtarma sürecinin tüm yönleri üzerinde kontrol edilmesidir.

Dışarıdan bir sağlayıcı harici bir olağanüstü durum kurtarma sistemine sahiptir ve işletir. Dış bölgeler sıcak, ılık veya soğuk olabilir.

  • Sıcak sistem:Donanım ve yazılım, personel ve müşteri verileri ile tam olarak işlevsel bir veri merkezi; bir felaket durumunda operasyonel olarak hazır.
  • Sıcak sistem:Müşteri verisi olmayan donanımlı bir veri merkezi; bir kuruluş bir felaketten sonra ek ekipman kurabilir ve müşteri verilerini tanıtabilir.
  • Soğuk sistem:BT sistemlerini ve verilerini destekleyecek altyapıya sahiptir, ancak bir kuruluş DR planlarını etkinleştirip ekipmanı yükleyene kadar teknolojiye sahip değildir; bazen uzun süreli bir felaket sırasında sıcak ve ılık alanları desteklemek için kullanılır.

Uzaklık, bir olağanüstü durum kurtarma sisteminin önemli bir öğesidir. Daha yakın bir sistemin yönetilmesi daha kolaydır, ancak birincil veri merkezini etkileyen büyük bir felaketten etkilenmeyecek kadar uzakta olmalıdır. Daha uzaktaki sistemler daha fazla personel gerektirebilir ve maliyetleri artırabilir.

Bir bulut kurtarma sistemi başka bir seçenektir. Bulut depolama genellikle daha ucuzdur ve daha az kaynak ve altyapı gerektirir, ancak yöneticiler bant genişliği ve güvenlik konusunda dikkatli olmalıdır.

Sistemlerle ilgili olarak, bir kuruluş felaket kurtarma hizmet sağlayıcılarıyla sözleşme yaparken sahaya yakınlığı, iç ve dış kaynakları, operasyonel riskleri, hizmet düzeyi sözleşmelerini ve maliyeti göz önünde bulundurmalıdır.

DR katmanları

1980’lerde, IBM ile çalışan Paylaşım Teknik Yönlendirme Komitesi, 0-6 arasındaki katmanları kullanan olağanüstü durum kurtarma hizmeti düzeylerinin bir açıklamasını sundu. Katman 0, en az saha dışı kurtarılabilirlik miktarını ve katman 6 ise en fazla olanı temsil etmektedir.

  • Aşama 0:Tesis dışı veri yok. Kurtarma yalnızca tesis içi sistemler kullanılarak mümkündür.
  • Aşama 1:Soğuk bir sistem ile fiziksel yedekleme. Büyük olasılıkla teyp üzerindeki veriler, gerekli donanıma sahip olmayan bir tesise taşınır.
  • Aşama 2:Sıcak bir sistem ile fiziksel yedekleme. Büyük olasılıkla teyp üzerindeki veriler, birincil sistemin, önemli sistemleri desteklemek için gerekli donanıma sahip bir tesis dışı tesise taşınır.
  • Aşama 3:Elektronik kasa. Veriler elektronik olarak sıcak bir bölgeye iletilir.
  • Aşama 4: Zamanında kopyalar / aktif ikincil sistem. Hayati veriler, her sistem diğerini yedekleyen birincil ve ikincil sistemler arasında kopyalanır. Disk bu katmanda sıklıkla kullanılır.
  • Aşama 5:İki saha taahhüt / işlem bütünlüğü. Veriler sistemler arasında sürekli olarak iletilir.
  • Aşama 6:Minimal – sıfır veri kaybı. Kurtarma anında gerçekleşir, genellikle disk yansıtma veya çoğaltma içerir.

Daha sonra otomasyonu içerecek şekilde bir aşama 7 eklendi ve olağanüstü durum kurtarma senaryolarında en yüksek kullanılabilirlik seviyesini temsil ediyor.

Genel olarak, iyileşme yeteneği bir sonraki en yüksek kademeyle iyileşmekle birlikte, maliyetler de artar.

Afet türleri

Hem insanın hem de doğanın neden olduğu – iyileşme durumlarına yol açan çok çeşitli felaketler var. Belli bir felaket olanaksız gibi görünebilir, ancak felaket kurtarma amacıyla gerçekleşme olasılığını tanımak önemlidir.

Afet türlerine örnekler:

  • Uygulama veya sanal makine
  • İletişim hatası.
  • Tek bir ana bilgisayarın veya birden çok ana bilgisayarın başarısız olmasına neden olabilecek kasa hatası.
  • Raf arızası.
  • Sprinkler sisteminin yanlışlıkla tetiklenmesinden elektrik kesintisine, sel veya yangına kadar değişen veri merkezi felaketi.
  • Bina felaketi.
  • Kampüs felaketi; örneğin, bir bölgeyi tahrip eden bir kasırga.
  • Şehir çapında felaket.
  • Ulusal felaket. Bu çok küçük ülkelerde daha olasıdır, ancak büyük ülkelerde imkansız değildir.

Bu felaketlerin varlığının bilinmesi, onlar için planlamanın ilk adımıdır. Bir kuruluşun potansiyel felaketlere hazırlanmasına yardımcı olabilecek iki rapor vardır: bir risk değerlendirmesi ve bir iş etkisi analizi (BIA).

Bir kuruluşu olumsuz etkileyebilecek tehlikeleri belirlemek ve hasarı azaltmanın yollarını belirlemek için bir risk değerlendirmesi yapılır. Riskler, kuruluşun içinde bulunduğu sektör ve coğrafi konumu gibi faktörlere göre değişiklik gösterir, bu nedenle felaket kurtarma planlama sürecinin bir risk değerlendirmesi yapılmasını içermesi önemlidir. Genel olarak, potansiyel tehlikeleri belirleyerek, bu tehlikelerin kime veya neye zarar vereceğini belirleyerek ve bu riskleri hesaba katmak için bulguları güncelleme prosedürlerini kullanarak bir risk değerlendirmesi yapılmalıdır.

Bir BIA, bir felaketin ticari faaliyetler üzerindeki etkilerini belirler ve değerlendirir. İş etkisi analizi hem finansal hem de finansal olmayan bir felaketin maliyetini tahmin etmeye yardımcı olabilir. Bir BIA farklı afetlerin bir kuruluşun güvenliği, finansmanı, pazarlaması, ticari itibarı, yasal uygunluğu ve kalite güvencesi üzerindeki etkisini inceler. Bir risk değerlendirmesinden önce gerçekleştirilen bir BIA, kuruluşun önemli kısımlarını belirler ve DR planında RPO’ların ve RTO’ların oluşturulmasına yardımcı olabilir.

İşletmenizin en uygun disaster çözümünü belirlemeniz için bizlerle iletişime geçebilirsiniz.

WhatsApp chat