Disaster Recovery (Felaket Kurtarma)

Disaster recovery (felaket kurtarma), bir organizasyonun yangın, sel, deprem, elektrik kesintisi, donanım arızası, siber saldırı ya da basit bir insan hatası gibi beklenmedik olaylardan sonra iş sürekliliğini koruyabilme yeteneğidir. Amaç nettir: bu tür olayların yol açtığı veri kaybını ve hizmet kesintisini en aza indirmek, kritik iş süreçlerini mümkün olan en kısa sürede yeniden çalışır hale getirmek. Kulağa teknik bir konu gibi gelse de aslında bir risk yönetimi meselesidir; çünkü bir e-ticaret sitesinin saatlerce erişilemez olması ya da bir muhasebe veritabanının geri dönülmez şekilde kaybolması, çoğu işletme için doğrudan gelir ve itibar kaybı demektir.

Bu rehberde disaster recovery kavramını tek tek ele alacağız: DR’nin yedeklemeden farkı, planın hangi bileşenlerden oluştuğu, RTO ve RPO gibi ölçütlerin ne anlama geldiği, hangi DR senaryolarının var olduğu ve felaket kurtarma planını adım adım nasıl kurgulayacağınız. Sonunda en sık sorulan soruları da derli toplu yanıtladık.

Disaster recovery yedeklemeyle aynı şey mi?

En sık karıştırılan nokta bu. Yedekleme (backup), verilerin bir kopyasını almaktır. Disaster recovery ise o kopyaları, sunucuları, ağı, uygulamaları ve süreçleri bir araya getirip işi yeniden çalışır hale getirme planının bütünüdür. Yani yedekleme, DR’nin kritik ama tek başına yetersiz bir parçasıdır.

Şöyle düşünün: Veritabanınızın gece yarısı alınmış bir yedeği elinizde olabilir. Ancak o yedeği hangi sunucuya, hangi sırayla, ne kadar sürede geri yükleyeceğinizi, DNS kayıtlarını nereye yönlendireceğinizi, müşterilere ne diyeceğinizi bilmiyorsanız, elinizdeki kopya bir dosyadan ibarettir. DR planı tam da bu boşluğu doldurur. Bir adım ötesinde, çoğu kuruluş DR’yi iş sürekliliği planlamasının (BCP) bir alt kümesi olarak konumlandırır: BCP “işin tamamı nasıl ayakta kalır” sorusunu sorar, DR ise bunun BT ayağını yürütür.

RTO ve RPO nedir? DR planının iki temel sayısı

Bir felaket kurtarma planının kalitesi, somut iki hedefe indirgenebilir. Bu iki kavram, sektörde DR’nin ortak dili gibidir:

• RTO (Recovery Time Objective – Kurtarma Süresi Hedefi): Bir kesinti yaşandığında sistemlerin en geç ne kadar sürede yeniden çalışır hale gelmesi gerektiğidir. Olaydan ileriye doğru sayar. Örneğin RTO 1 saat ise, kesintiden bir saat sonra hizmetin ayakta olması beklenir.
• RPO (Recovery Point Objective – Kurtarma Noktası Hedefi): Göze alabileceğiniz maksimum veri kaybı miktarıdır; zaman cinsinden ölçülür. Olaydan geriye doğru sayar. RPO 15 dakika ise, en kötü ihtimalle son 15 dakikalık veriyi kaybetmeyi kabul ediyorsunuz demektir; bu da yedeklemenin en az 15 dakikada bir alınması gerektiği anlamına gelir.

Bu iki sayı doğrudan bütçeyi belirler. RTO’yu dakikalara, RPO’yu saniyelere indirmek istiyorsanız sürekli replikasyon ve sıcak yedek (hot standby) altyapısı gerekir; bu da daha pahalıdır. Bir blog için RTO 24 saat kabul edilebilirken, bir ödeme sistemi için RTO dakikalarla, RPO ise saniyelerle ifade edilir.

Disaster recovery planının bileşenleri

Sağlam bir felaket kurtarma planı, birbirini tamamlayan birkaç parçadan oluşur. Aşağıdaki başlıklar, sektörde standart kabul edilen yapı taşlarıdır:

1. Yedekleme (Backup): Verilerin düzenli ve otomatik aralıklarla kopyalanması. Otomasyon burada kritiktir; insan hafızasına bırakılan yedek er ya da geç unutulur.
2. Veri kurtarma (Data Recovery): Yedeklenen verinin hızlı ve doğrulanmış biçimde geri yüklenmesi. “Geri yükleme yapabiliyor muyuz” sorusunun cevabı test edilmeden bilinemez.
3. Sistem yedekleme (System Backup): Sadece veri değil; işletim sistemi, uygulama yapılandırmaları ve sunucu imajlarının da yedeklenmesi. Modern yaklaşımda bu, altyapının kod olarak (IaC) tanımlanmasıyla otomatikleştirilir.
4. Yüksek erişilebilirlik (High Availability): Tek bir donanımın arızalanması durumunda hizmetin kesintisiz devam etmesini sağlayan yedekli mimari. HA, DR ile aynı şey değildir; HA anlık arızaları tolere eder, DR ise büyük felaketlerden sonrasını planlar.
5. Acil durum müdahale planı: Olay anında kimin neyi yapacağını, iletişim zincirini ve önceliklendirmeyi tanımlar.
6. İş sürekliliği planı (BCP): Kritik iş fonksiyonlarının kesintiye rağmen sürdürülmesini hedefler.
7. Test ve tatbikat: Planın kâğıt üstünde kalmaması için düzenli simülasyonlar, masaüstü tatbikatları ve gerçek failover denemeleri yapılır.

DR senaryoları: soğuk, ılık ve sıcak yedek

Felaket kurtarma yaklaşımları, ne kadar hızlı ayağa kalkmak istediğinize ve bütçenize göre genelde üç olgunluk seviyesinde ele alınır:

Buradaki kilit kavram failover (devralma): birincil sistem çöktüğünde trafiğin ikincil sisteme aktarılmasıdır. Felaket atlatıldıktan sonra trafiğin tekrar asıl sisteme döndürülmesine ise failback denir. Sıcak yedek modelinde bu geçiş otomatik ve neredeyse fark edilmeden gerçekleşir. Bulut tabanlı modellerde, ikincil ortamı sürekli açık tutmak yerine yalnızca ihtiyaç anında ölçeklendirmek maliyeti ciddi şekilde düşürür.

Felaket kurtarma planı adım adım nasıl hazırlanır?

Teoriyi uygulamaya dökmek için izlenebilecek pratik bir yol haritası:

1. Risk ve etki analizi yapın: Hangi sistem kritik, çökerse iş ne kadar etkilenir? Bir iş etki analizi (BIA) ile sistemlerinizi önem sırasına koyun.
2. RTO ve RPO hedeflerini belirleyin: Her kritik sistem için kabul edilebilir kesinti ve veri kaybı süresini netleştirin.
3. 3-2-1 yedekleme stratejisi kurun: 3 kopya, 2 farklı ortam, 1 kopya tesis dışında (offsite). Birincil tesis tamamen kaybolsa bile dokunulmamış bir kopyanız kalır.
4. Geri yükleme sırasını dokümante edin: Sistemler arası bağımlılıkları gözeterek hangi servisin önce kalkacağını yazın. Veritabanı ayağa kalkmadan uygulama sunucusunu başlatmak işe yaramaz.
5. Otomasyon ve script kullanın: Altyapıyı kod olarak tanımlamak (IaC) ve hazır kurtarma scriptleri, yeniden inşa süresini dramatik biçimde kısaltır.
6. Düzenli test edin: Yılda en az bir kez gerçek bir failover tatbikatı yapın. Test edilmemiş bir DR planı, gerçek anlamda plan değildir.
7. Güncel tutun: Altyapı değiştikçe planı revize edin; bir yıl önceki plan bugünkü mimarinizi yansıtmayabilir.

Verilerini yedeklemeyen işletmelerin riskleri nelerdir?

Yedeklemeyi ve felaket kurtarmayı ihmal eden işletmeler bir dizi ciddi riskle karşı karşıyadır:

1. Veri kaybı: Donanım arızaları, fidye yazılımları, doğal afetler veya hatalı işlemler müşteri bilgilerinin, finansal kayıtların ve kritik verinin kalıcı kaybına yol açabilir.
2. İş sürekliliği sorunları: Kritik verinin kaybı, süreçleri durdurur ve hizmet kesintilerine neden olur.
3. Müşteri memnuniyetsizliği: Kesintiler ve bilgi kayıpları, müşteri güvenini sarsar; kayıp müşterilere dönüşür.
4. Yasal sorumluluk: KVKK gibi düzenlemeler kişisel verinin korunmasını zorunlu kılar; ihlal durumunda cezai yaptırım söz konusudur.
5. İtibar zararı: Veri güvenliğini ciddiye almayan markalara güven azalır.
6. Mali kayıplar: Kurtarma çabaları, tazminatlar ve kesinti maliyetleri ciddi tutarlara ulaşır.
7. Rekabet gücü kaybı: Veriye erişimini kaybeden işletme, pazar analizi ve karar alma gücünü de yitirir.

İşletme verilerini riske eden durumlar nelerdir?

Veriyi tehdit eden başlıca etkenler şunlardır:

• Kötü amaçlı yazılımlar: Fidye yazılımları, virüsler ve truva atları veriyi şifreleyebilir veya silebilir.
• Fiziksel zararlar: Yangın, sel, deprem veya hırsızlık donanımı doğrudan etkiler.
• Teknolojik arızalar: Disk, sunucu veya ağ ekipmanı arızaları.
• İnsan hataları: Yanlışlıkla silme, hatalı yapılandırma veya yanlış komut.
• Siber saldırılar ve veri sızıntısı: İçeriden veya dışarıdan gelen ihlaller.
• Yetersiz güvenlik: Zayıf parolalar, güncellenmemiş yazılımlar ve eksik ağ güvenliği.
• Yedekleme eksikliği: Yedeklerin hiç alınmaması ya da düzenli güncellenmemesi.

Bu risklere karşı en etkili savunma, güçlü bir veri güvenliği katmanıyla birlikte yürüyen, test edilmiş bir felaket kurtarma planıdır. Çalışanlara verilen düzenli güvenlik eğitimi de insan kaynaklı hataları belirgin biçimde azaltır.

Veri yedeklemesi için en iyi çözümler nedir?

En iyi çözüm, işletmenizin veri hacmine, bütçesine ve RTO/RPO hedeflerine bağlıdır. Yaygın yaklaşımlar:

• Bulut tabanlı yedekleme: Otomatik yedekleme, kolay kurtarma ve coğrafi dağıtım sunar; günümüzde kurumsal yedekleme uygulamalarının büyük çoğunluğu bulut tabanlıdır.
• Yerel depolama (NAS): Ağa bağlı depolama cihazları, hızlı yerel kurtarma için kullanışlıdır.
• Yedekleme yazılımları: Sunucu ve cihazları zamanlanmış şekilde yedekleyip geri yükleyen araçlar.
• Veri merkezi yedeklemesi: Büyük ölçekli kuruluşlar için yüksek kapasiteli, yedekli altyapı.
• Hibrit yedekleme: Yerel hız ile bulutun coğrafi güvenliğini birleştirir; 3-2-1 kuralını uygulamanın en pratik yoludur.

Hangi çözümü seçerseniz seçin, kuralın özü değişmez: yedeğin coğrafi olarak ayrı bir kopyası olmalı ve geri yükleme düzenli test edilmelidir.

Alastyr ile felaket kurtarma altyapısı

Felaket kurtarma planının ne kadar iyi olduğu, dayandığı altyapı kadar sağlamdır. Alastyr, İzmir’de yer alan kendine ait (kiralık değil) veri merkezinde, N+1 yedekli güç ve soğutma altyapısıyla Tier III standartlarında hizmet sunar. Tüm hosting paketlerinde günlük otomatik yedekleme standarttır; böylece bir aksaklık anında geri dönülecek bir kopyanız her zaman hazırdır.

İkincil ortam ve esnek kaynak ölçekleme ihtiyacı için bulut sunucu ve VPS sunucu çözümleri, kritik sistemlerinize warm/hot standby kurgusu için zemin sağlar. Depolama tarafında Dell EMC Unity 650F all-flash ünitesi ve 10’lu yüksek erişilebilirlik (HA) cluster mimarisi, donanım arızalarının hizmete yansımasını en aza indirir. Güvenlik katmanında Imunify360 ve CageFS ile fidye yazılımı ve kötü amaçlı yazılımlara karşı koruma, Voxility tabanlı 1 Tbps üzeri L3-L4 anti-DDoS ile de hacimsel saldırılara karşı savunma sağlanır.

%99.9 uptime taahhüdü, ücretsiz SSL, ücretsiz taşıma ve 7/24 Türkçe destek ile altyapınızı yalnızca felaket anında değil, her gün koruma altında tutarsınız. 2002’den bu yana %100 Türk sermayesiyle hizmet veren Alastyr, RIPE NCC üyesi bağımsız ağı (AS3188) ve 40 Gbit yedekli bağlantısıyla iş sürekliliğini altyapı seviyesinde destekler.

Sıkça Sorulan Sorular

Disaster recovery ile yedekleme arasındaki fark nedir?

Yedekleme, verilerin bir kopyasını almaktır ve felaket kurtarmanın yalnızca bir parçasıdır. Disaster recovery ise yedekleri, sunucuları, ağı, uygulamaları ve süreçleri bir araya getirerek işi yeniden çalışır hale getirmenin bütününü kapsar. Kısacası her DR planı yedekleme içerir, ama her yedekleme tek başına DR sayılmaz.

RTO ve RPO ne anlama gelir?

RTO (Recovery Time Objective), bir kesintiden sonra sistemlerin en geç ne kadar sürede ayağa kalkması gerektiğini gösterir. RPO (Recovery Point Objective) ise göze alınabilecek maksimum veri kaybını zaman cinsinden ifade eder. Örneğin RPO 15 dakika ise, yedeklemenin en az 15 dakikada bir alınması gerekir.

3-2-1 yedekleme kuralı nedir?

3-2-1 kuralı, verinin 3 kopyasının tutulmasını, bu kopyaların 2 farklı ortamda saklanmasını ve en az 1 kopyanın tesis dışında (offsite) bulundurulmasını öngörür. Bu sayede birincil tesis tamamen kaybolsa veya yerel yedek bozulsa bile, geri dönülecek dokunulmamış bir kopya kalır.

Felaket kurtarma planı ne sıklıkla test edilmeli?

Plan en az yılda bir kez gerçek bir failover tatbikatıyla test edilmelidir. Altyapıda önemli bir değişiklik yapıldığında ise testi beklemeden plan güncellenmelidir. Test edilmemiş bir DR planı, gerçek bir kesinti anında çoğu zaman beklenildiği gibi çalışmaz.

Yüksek erişilebilirlik (HA) ile disaster recovery aynı şey mi?

Hayır. Yüksek erişilebilirlik, tek bir donanımın anlık arızasını tolere ederek hizmetin kesintisiz devam etmesini sağlar. Disaster recovery ise yangın, sel veya tüm veri merkezinin etkilenmesi gibi büyük felaketlerden sonra hizmeti geri getirmeyi planlar. İkisi birbirini tamamlar.

Soğuk, ılık ve sıcak yedek arasındaki fark nedir?

Soğuk yedekte sadece veri saklanır ve sunucu felaket sonrası kurulur; RTO saatler-günler düzeyindedir. Ilık yedekte ikincil ortam kısmen hazır bekler. Sıcak yedekte ise ikincil ortam birebir ayna olarak çalışır, veri sürekli replike edilir ve devralma saniyeler içinde gerçekleşir. Hız arttıkça maliyet de artar.

Küçük bir işletmenin felaket kurtarma planına ihtiyacı var mı?

Evet. Veri kaybı ölçekten bağımsızdır; bir fidye yazılımı veya disk arızası küçük bir işletmeyi de günlerce durdurabilir. Küçük işletmeler için bulut tabanlı otomatik yedekleme ve basit bir geri yükleme prosedürü bile ciddi bir koruma sağlar.

Fidye yazılımına karşı disaster recovery işe yarar mı?

Yararlar, ancak yedeklerin saldırıdan etkilenmeyecek şekilde izole ve değiştirilemez (immutable) tutulması şartıyla. Coğrafi olarak ayrı, çevrimdışı veya yazma korumalı bir kopyaya sahipseniz, şifrelenen sistemi temiz yedekten geri yükleyerek fidye ödemeden iş sürekliliğini sağlayabilirsiniz.

Disaster recovery hizmeti hangi altyapı üzerinde çalışmalı?

İdeal olarak yedekli güç ve soğutmaya sahip (N+1), coğrafi olarak ayrı bir kopya tutabilen ve sürekli erişilebilirlik sunan bir veri merkezi üzerinde çalışmalıdır. Alastyr’in İzmir’deki kendi veri merkezi, günlük otomatik yedekleme, all-flash depolama ve %99.9 uptime taahhüdü bu ihtiyaçları karşılar.