Felaket kurtarma (Disaster Recovery, DR), bir kesinti veya felaket sonrasında sunucuların, verilerin ve uygulamaların önceden belirlenmiş sürede yeniden çalışır hâle getirilmesidir. İş sürekliliği ise bu süreçte şirketin kritik faaliyetlerini sürdürmesini hedefler. Oner Business Teknolojileri, RTO ve RPO hedeflerinizi belirler, sunucularınızı gerçek zamanlı şifreli tünellerle bulut veri merkezimize (Cloud DR Center) replike eder ve planı yılda en az iki kez tatbikatla test eder.
İş sürekliliği ve felaket kurtarma nedir?
İş sürekliliği, bir kriz anında şirketin müşterilerine hizmet vermeye devam edebilmesi için insan, süreç ve teknolojiyi birlikte ele alan yönetim çerçevesidir. Felaket kurtarma ise bu çerçevenin teknoloji ayağıdır ve IT sistemlerinin geri dönüşünü planlar. Birincisi “işi nasıl sürdürürüz”, ikincisi “sistemleri nasıl geri getiririz” sorusunu yanıtlar.
Pek çok şirket yedek almayı felaket kurtarma planı sanır. Oysa yedek yalnızca verinin bir kopyasıdır. Sunucu yanmışsa bu yedek hangi donanıma, kim tarafından, hangi sırayla ve ne kadar sürede geri yüklenecek? Kullanıcılar hangi ağ üzerinden bağlanacak? Müşterilere ve tedarikçilere ne söylenecek? Bu soruların yanıtı kriz anında değil, önceden yazılı olarak verilmelidir.
Felaket kurtarma çalışmalarımız, kurumsal veri yedekleme altyapısının üzerine inşa edilir ve onu sistem, ağ ve süreç boyutlarıyla tamamlar.
Oner Business Teknolojileri olarak fiziksel ve sanal sunucularınızı (VMware, Hyper-V) gerçek zamanlı şifreli tüneller üzerinden bulut veri merkezimize (Cloud DR Center) replike ediyoruz. Şirket içi sunucularınızın kopyası, veri merkezimizdeki DR sunucularıyla senkronize tutulur; felaket anında kritik sistemler, belirlenen RTO hedefi içinde bulut üzerinde yeniden çalıştırılır. Böylece kendi ikinci veri merkezinizi kurmanıza gerek kalmaz.
RTO ve RPO nedir, nasıl belirlenir?
RTO, bir sistemin kesintiden sonra en geç ne kadar sürede çalışır hâle gelmesi gerektiğini; RPO ise kaybedilmesi kabul edilebilir en fazla veri miktarını zaman olarak ifade eder. Bu hedefler teknik ekip tarafından değil, iş birimleriyle birlikte, kesintinin şirkete maliyeti değerlendirilerek belirlenir ve seçilecek çözümün maliyetini doğrudan etkiler.
Tüm sistemler için aynı hedefi koymak hem gereksiz hem pahalıdır. Satış ve üretimi durduran bir ERP sistemi ile arşiv dosya sunucusunun kurtarma önceliği aynı olamaz. Aşağıdaki tablo, farklı hedeflere karşılık gelen tipik felaket kurtarma yaklaşımlarını karşılaştırır:
| Yaklaşım | Tipik RTO | Tipik RPO | Uygun olduğu durum |
|---|---|---|---|
| Şirket dışı yedekten geri yükleme | Saatler – günler | Son yedek anı (çoğunlukla günlük) | Kısa kesintiye tahammülü olan destek sistemleri |
| Yerel yedek ve hazır yedek donanım | Saatler | Son yedek veya snapshot anı | Tek lokasyonlu KOBİ'lerin çekirdek sunucuları |
| Bulut veri merkezimize (Cloud DR Center) replikasyon | Dakikalar – saatler | Dakikalar | ERP, muhasebe ve üretim gibi kritik sistemler |
| Yüksek erişilebilirlik (kümeleme) | Çok kısa | Çok düşük | Kesintisiz çalışması gereken sistemler; tek başına fidye yazılımına karşı yeterli değildir |
İş etki analizi nasıl yapılır?
İş etki analizi, her iş sürecinin hangi IT sistemlerine bağlı olduğunu ve bu sistemler durduğunda şirketin saat saat ne kaybettiğini ortaya koyar. Sonuçta kritik sistemler önceliklendirilir, her biri için RTO ve RPO hedefi belirlenir ve felaket kurtarma bütçesi en çok zarar doğuracak kesintilere yönlendirilir.
- İş birimleriyle görüşülerek kritik süreçler ve bağımlı oldukları uygulamalar listelenir.
- Her uygulamanın çalıştığı sunucu, veritabanı, ağ bağlantısı ve dış servisler eşleştirilir.
- Kesintinin finansal, operasyonel ve yasal etkisi değerlendirilir.
- Sistemler öncelik gruplarına ayrılır ve kurtarma sırası belirlenir.
- Hedefler ile mevcut altyapının gerçek kurtarma kapasitesi arasındaki fark raporlanır.
Hangi felaket senaryolarına hazırlanmak gerekir?
Felaket kurtarma planı yalnızca deprem veya yangın gibi büyük olayları değil, çok daha sık yaşanan fidye yazılımı saldırılarını, depolama arızalarını, uzun süreli elektrik ve internet kesintilerini, yanlışlıkla silinen verileri ve kilit personelin ulaşılamaz olduğu durumları da kapsamalıdır. Her senaryonun kurtarma adımları farklıdır.
- Fidye yazılımı: Saldırı öncesine ait temiz ve değiştirilemez bir geri dönüş noktası gerekir; bkz. yönetilen güvenlik hizmetimiz.
- Donanım ve depolama arızası: Yedek donanım, garanti ve üretici destek süreleri plana yazılmalıdır.
- Deprem, yangın, su baskını: Sistem odası kullanılamaz hâle gelirse şirket dışı kopya ve alternatif çalışma yeri gerekir.
- Hat ve elektrik kesintisi: Yedek internet hattı, UPS ve şubeler için akıllı yük devretme; bkz. SD-WAN rehberimiz.
- Kilit personel: Parolalar ve prosedürlerin tek kişiye bağımlı olmaması.
Felaket kurtarma planı nasıl test edilir?
Felaket kurtarma planı üç düzeyde test edilir: ekibin senaryoyu adım adım konuştuğu masa başı tatbikatı, seçilen sistemlerin izole bir ortama geri yüklendiği kısmi test ve kritik sistemlerin yedek ortama devredildiği tam tatbikat. Oner Business, DR tatbikatlarını yılda en az iki kez yapar; her testte gerçek kurtarma süresi ölçülür ve plan güncellenir.
Test edilmemiş bir plan, kriz anında genellikle eksik bir parola, belgelenmemiş bir bağımlılık ya da beklenenden çok daha uzun süren bir geri yükleme nedeniyle aksar. Tatbikatlarımızı canlı sistemleri etkilemeden, sanal ağ tünelleri üzerinde siber ve fiziksel felaket senaryoları çalıştırarak yaparız; bu da tatbikatları daha sık ve daha düşük riskle yapmayı mümkün kılar. Ayrıntılar için sanallaştırma çözümlerimize ve VMware vSphere yazımıza göz atabilirsiniz.
Felaket kurtarma projesine nasıl başlanır?
Oner Business ile felaket kurtarma çalışması mevcut altyapının ve yedekleme yapısının keşfiyle başlar. Ardından iş etki analizi yapılır, RTO ve RPO hedefleri belirlenir, hedefe uygun mimari önerilir ve kurulur, yazılı kurtarma prosedürleri hazırlanır ve ilk tatbikatla plan doğrulanır. Plan, altyapı değiştikçe güncel tutulur.
Hedefimiz, işletmenizi fiziksel ve siber tehditlere karşı %100 dayanıklı hale getirmektir. Tüm aşamaları tek ekipte yürüttüğümüz için yedekleme, altyapı yönetimi ve güvenlik kararları birbiriyle uyumlu kalır. Mevcut hazırlık seviyenizi birlikte değerlendirmek için iletişim sayfamızdan bize ulaşabilirsiniz.
Sık Sorulan Sorular
İş sürekliliği, bir kriz sırasında şirketin kritik faaliyetlerini insan, süreç, tedarik ve iletişim boyutlarıyla birlikte sürdürmesini hedefleyen geniş bir yönetim çerçevesidir. Felaket kurtarma (DR) ise bu çerçevenin IT ayağıdır; sunucuların, verilerin, ağın ve uygulamaların belirlenen sürede yeniden çalışır hâle getirilmesini kapsar. İyi bir iş sürekliliği planı mutlaka test edilmiş bir felaket kurtarma planı içerir.
RTO (Recovery Time Objective), bir sistemin kesintiden sonra en geç ne kadar sürede yeniden çalışır hâle gelmesi gerektiğini gösterir. RPO (Recovery Point Objective) ise kabul edilebilir en fazla veri kaybını zaman olarak ifade eder; örneğin son yedekten bu yana geçen süre. Bu iki hedef, hangi yedekleme ve replikasyon yönteminin seçileceğini ve dolayısıyla felaket kurtarma çözümünün maliyetini doğrudan belirler.
Bir felaket kurtarma planı; kritik sistemlerin listesi ve öncelik sırası, her sistem için RTO ve RPO hedefleri, yedeklerin ve replikaların nerede tutulduğu, adım adım kurtarma prosedürleri, kriz anında görev alacak kişiler ve iletişim zinciri, tedarikçi ve üretici destek bilgileri ile test takviminden oluşur. Plan, yazılı, güncel ve kriz anında erişilebilir bir yerde saklanmalı ve düzenli olarak gözden geçirilmelidir.
Oner Business, felaket kurtarma planlarını yılda en az iki kez uygulamalı tatbikatla test eder; altyapıda büyük bir değişiklik yapıldığında plan ayrıca yeniden doğrulanır. Testler; masa başı senaryo tatbikatından, seçilen sistemlerin geri yüklenmesine ve tam yük devretme denemesine kadar farklı derinliklerde yapılabilir. Test sonucunda ölçülen gerçek kurtarma süreleri hedeflerle karşılaştırılır ve plan buna göre güncellenir.
Evet. Felaket kurtarma planı yalnızca büyük kurumlar için değildir. Bir KOBİ'nin muhasebe sunucusunun fidye yazılımıyla şifrelenmesi veya ofiste yaşanan bir su baskını, günlerce süren bir iş kaybına yol açabilir. KOBİ ölçeğinde plan; kritik sistemlerin belirlenmesi, şirket dışı yedek, geri yükleme prosedürü ve basit bir iletişim planıyla başlayabilir ve bütçeye göre aşamalı olarak geliştirilebilir.
Şirketin kendi ikinci veri merkezini kurması gerekmez. Saatler içinde kurtarmanın yeterli olduğu sistemler için şirket dışı yedekler ve hazır bir geri yükleme planı yeterli olabilir. Dakikalar içinde dönmesi gereken kritik sistemler ise Oner Business'ın bulut veri merkezine (Cloud DR Center) gerçek zamanlı şifreli tünellerle replike edilir. Doğru seçim, iş etki analizi sonrasında maliyet ve risk dengesine göre yapılır.
Evet. Günümüzde fidye yazılımı, deprem veya yangın kadar ciddi ve çok daha sık karşılaşılan bir felaket senaryosudur. Farkı, saldırının replikalara da yayılabilmesidir; bu nedenle yalnızca anlık replikasyona güvenen bir plan yetersiz kalabilir. Felaket kurtarma planında saldırı öncesine ait temiz, değiştirilemez bir geri dönüş noktası ve temizlenmiş bir ortamda geri yükleme prosedürü mutlaka tanımlanmalıdır.