İş Sürekliliği & Felaket Kurtarma
Azure Backup ve Azure Site Recovery ile veri kaybına ve kesintiye karşı kurumunuzu dirençli hale getiriyorum.
İş sürekliliği ve felaket kurtarma danışmanlığı hizmetimde, kurumunuzun veri kaybı ve hizmet kesintisi risklerini iş etki analiziyle ölçüp Azure'un yerleşik dayanıklılık hizmetleriyle kapatırım. İlk adım her zaman iş birimleriyle birlikte RTO (kurtarma süresi hedefi) ve RPO (kabul edilebilir veri kaybı) değerlerini belirlemektir; teknoloji seçimi bu hedeflere göre şekillenir. Kritiklik katmanlarına ayrılmış iş yükleri için maliyet ile dayanıklılık arasında dengeli bir koruma stratejisi tasarlarım.
Azure Backup tarafında sanal makineler, SQL veritabanları, dosya paylaşımları ve şirket içi sunucular için merkezi yedekleme politikaları kurarım. Ransomware tehdidine karşı immutable (değiştirilemez) vault, soft delete ve çok kullanıcılı yetkilendirme (MUA) katmanlarını devreye alırım; yedeklerin kendisinin de saldırı yüzeyi olduğu gerçeğinden hareketle yedek altyapısını ayrı güvenlik sınırına taşırım. Azure Site Recovery ile kritik iş yüklerinizi ikincil Azure bölgesine veya şirket içinden Azure'a sürekli çoğaltır, felaket anında dakikalar içinde ayağa kalkan bir kurtarma planı hazırlarım.
Kağıt üzerinde kalan DR planı plan değildir: düzenli kurtarma tatbikatlarıyla (DR drill) planın gerçekte çalıştığını kanıtlar, tatbikat sonuçlarını yönetime raporlarım. Azure Monitor ile yedekleme başarısı, çoğaltma sağlığı ve kurtarma noktası yaşı sürekli izlenir; sapmalar otomatik uyarıya bağlanır. KVKK ve sektörel düzenlemelerin (BDDK, SPK) veri saklama ve süreklilik gereksinimlerini karşılayan denetim izleri oluştururum. Bankacılık senaryolarında BDDK kapsamı, işlem bütünlüğü ve kritik ödeme sistemlerinin düşük RTO/RPO hedefleri; sağlık senaryolarında ise hasta verisi erişilebilirliği, klinik uygulama bağımlılıkları ve KVKK kapsamı ayrı kurtarma katmanlarıyla ele alınır. Her iki sektörde de test failover, iş birimi kabulü ve denetim kanıtı zorunlu teslimatlar arasındadır.
Sonuç: test edilmiş, belgelenmiş ve maliyeti optimize edilmiş bir iş sürekliliği çatısı.
Kritiklik Katmanlaması: Dengeli Koruma Nasıl Tasarlanır
İş sürekliliği tasarımının en pahalı hatası, her iş yükünü aynı seviyede korumaya çalışmaktır. Tüm sistemlere en yüksek koruma uygulandığında yedekleme ve çoğaltma bütçesi hızla erir; herkese asgari koruma verildiğinde ise çekirdek sistemler felaket anında yetersiz kalır. Doğru yaklaşım, iş etki analizinin (BIA) çıktısını kritiklik katmanlarına dönüştürmektir. BIA, her sürecin durması hâlinde ortaya çıkan finansal kaybı, operasyonel aksamayı ve yasal sonucu ölçer; bu etki büyüdükçe kabul edilebilir kesinti ve veri kaybı penceresi daralır. Her katmana, hedeflenen RTO/RPO değerine uygun bir Azure yöntemi atarım ve böylece koruma yatırımı sistemin iş açısından taşıdığı değerle orantılı hâle gelir.
Katmanlama, RTO (sistemin ne kadar sürede ayağa kalkması gerektiği) ve RPO (ne kadar veri kaybının kabul edilebilir olduğu) hedeflerini somut teknoloji seçimlerine bağlar. Aşağıdaki tablo tipik bir üç katmanlı modeli ve her katmanın tahmini hedef aralığıyla eşleşen Azure koruma yöntemini gösterir; değerler başlangıç referansıdır ve her kurumun BIA sonucuna göre netleştirilir.
Bu katmanlar sabit değildir; yeni bir uygulama devreye girdiğinde veya bir sürecin iş kritikliği değiştiğinde katman ataması yeniden gözden geçirilir. Katmanlama yalnızca teknoloji seçimini değil, tatbikat önceliğini ve bütçe dağılımını da yönlendirir: en düşük RTO hedefine sahip Tier 0 sistemleri hem en güçlü çoğaltma mimarisini hem de en sık kurtarma provasını alır. Bağımlılıkların da katmanla uyumlu olması gerekir; kritik bir uygulama, kendisinden daha zayıf korunan bir veritabanına ya da kimlik servisine bağlıysa gerçek RTO'su en zayıf halkaya göre belirlenir.
| Kritiklik Katmanı | Tahmini RTO / RPO Hedefi | Azure Koruma Yöntemi |
|---|---|---|
| Tier 0 — Kritik (çekirdek işlem, ödeme, hasta kaydı) | RTO: dakikalar · RPO: sıfıra yakın | Site Recovery ile sürekli çoğaltma + sıcak bekleme; bölge-yedekli (zone-redundant) mimari ve ikinci Azure bölgesi |
| Tier 1 — İş açısından önemli (iç uygulamalar, raporlama) | RTO: birkaç saat · RPO: dakikalar–1 saat | Site Recovery çoğaltması (ılık bekleme) + sık aralıklı Azure Backup |
| Tier 2 — Standart / destekleyici (dosya, arşiv, test) | RTO: 1 gün ve üzeri · RPO: 24 saat | Yalnızca Azure Backup (günlük politika) + immutable vault |
Ransomware'e Karşı Kurtarılabilir Yedek Mimarisi
Fidye yazılımı gruplarının ilk hedefi çoğu zaman üretim verisi değil, yedeklerdir. Saldırganlar ortama sızdıktan sonra fark edilmeden geçirdikleri sürede (dwell time) önce yedekleme kataloglarını, saklama politikalarını ve vault'ları bozmaya çalışır; kurtarma yeteneği ortadan kalktığında fidye pazarlık gücü en yükseğe çıkar. Bu nedenle iş sürekliliği tasarımında yedeğin kendisini bir saldırı yüzeyi olarak ele alırım: amaç yalnızca yedek almak değil, saldırı sonrası kanıtlanmış biçimde kurtarılabilir bir kopyaya sahip olmaktır.
Bunun için modern 3-2-1-1-0 kuralını temel alırım: en az üç kopya, iki farklı ortam, bir kopya saha dışında, bir kopya değiştirilemez ya da mantıksal olarak izole ve doğrulamada sıfır hata. Azure tarafında immutable vault, yedekleri belirlenen süre boyunca yönetici dahil hiç kimsenin silemeyeceği veya değiştiremeyeceği hâle getirir; kritik katmanlarda çok kullanıcılı yetkilendirmenin (MUA) Resource Guard bileşenini ayrı bir kiracıya (tenant) ve ayrı yetki sınırına taşırım. Böylece üretim kimlikleri ele geçirilse bile koruma politikalarını gevşetmek tek bir yöneticinin elinde olmaz. Coğrafi yedekli (GRS) depolama ve ikinci bölgeye kopyalama, bölgesel bir olayda dahi temiz kopyanın erişilebilir kalmasını sağlar.
Kurtarılabilirliğin kanıtı ise düzenli geri yükleme provasıdır. Immutable vault bir kopyanın var olduğunu garanti eder; ancak o kopyanın temiz (enfekte olmamış) ve tutarlı olduğunu yalnızca test doğrular. Bu nedenle bilinen-iyi (known-good) kurtarma noktalarını işaretler, geri yükleme sürelerini ölçer ve Microsoft Defender uyarılarını yedekleme izleme akışına bağlayarak şüpheli silme veya şifreleme davranışını erken yakalarım. Saldırı sonrası kurtarma sırası da önceden planlanır: önce kimlik ve ağ temeli, ardından kritiklik katmanına göre iş yükleri temiz kopyadan sıralı biçimde ayağa kaldırılır.
Neden DR Tatbikatı Şart: Ölçülmemiş Kurtarma Süresi Bir Varsayımdır
Bir felaket kurtarma planı, yalnızca gerçek bir tatbikatla çalıştığı kanıtlandığında değer taşır. Belge üzerindeki RTO/RPO hedefleri iyimser varsayımlardır; gerçek kurtarma süresi ancak ölçüldüğünde bilinir. Tatbikat yapılmayan ortamlarda en sık karşılaşılan sürprizler şunlardır: dokümante edilmemiş bir bağımlılık nedeniyle uygulamanın ayağa kalkmaması, süresi dolmuş sertifikalar, eksik ağ kuralları, güncelliğini yitirmiş kurtarma betikleri (runbook) ve kurtarma sırasında hangi adımın kimde olduğunun belirsizliği.
Bu yüzden tatbikatı iş sürekliliği hizmetinin ayrılmaz bir parçası olarak konumlandırırım. Her tatbikat üç şeyi doğrular: ölçülen kurtarma süresinin hedef RTO/RPO ile uyumu, kurtarma adımlarının güncelliği ve ekibin plan üzerindeki pratiği. Ortam sürekli değiştiği için — yeni iş yükleri, yeni bağımlılıklar, mimari güncellemeler — bir kez başarılı olan plan zamanla bozulabilir; düzenli tatbikat bu kaymayı (drift) görünür kılar. Sonuçlar RTO/RPO hedefleriyle karşılaştırılıp yönetime raporlanır ve bulunan boşluklar bir sonraki döngüden önce kapatılır. BDDK ve benzeri düzenlemeler kapsamındaki kurumlarda bu tatbikat kayıtları aynı zamanda zorunlu denetim kanıtıdır.
Doğrulama-önce yaklaşımının pratikte nasıl işlediği, Kurumsal Bankacılık Hibrit Bulut Göçü vaka çalışmasında görülebilir: kritik sistemler üretime taşınmadan önce geliştirme ve test ortamları Azure Site Recovery üzerinden taşınarak süreç doğrulandı, üretim geçişi ancak bu doğrulamadan sonra dalgalı biçimde yapıldı. Aynı disiplin süreklilik tarafında da geçerlidir: bir kurtarma planına gerçek bir olayda güvenmeden önce, onu güvenli bir tatbikatta çalıştırıp ölçmek gerekir. Test failover'ın üretim çoğaltmasını kesintiye uğratmadan izole bir ağda çalışması, bu tatbikatların iş saatleri içinde bile düzenli yapılabilmesini mümkün kılar.
Neler Sunuyoruz
Backup & DR hizmetimizin kapsamındaki temel çalışma alanları
Çalışma Sürecimiz
Başarılı sonuçlar için izlediğimiz kanıtlanmış dört adımlı süreç
İş Etki Analizi
Kritik iş süreçlerini ve bağımlı sistemleri haritalar, her iş yükü için kabul edilebilir kesinti süresi (RTO) ve veri kaybı (RPO) hedeflerini iş birimleriyle belirlerim.
Koruma Stratejisi Tasarımı
Kritiklik katmanlarına göre Azure Backup politikaları, Site Recovery çoğaltma topolojisi ve immutable vault yapısını maliyet dengesiyle tasarlarım.
Kurulum & Otomasyon
Yedekleme ve çoğaltma altyapısını kurar, kurtarma planlarını (recovery plan) betiklerle otomatikleştirir, izleme ve uyarı mekanizmalarını devreye alırım.
Tatbikat & Sürekli Doğrulama
Üretimi etkilemeyen test failover tatbikatları düzenler, sonuçları RTO/RPO hedefleriyle karşılaştırıp raporlar, planı düzenli döngüyle güncel tutarım.
Sık Sorulan Sorular
Backup & DR hakkında en çok merak edilen sorular
Azure Backup ile Azure Site Recovery arasındaki fark nedir?
Azure Backup veri koruması sağlar: dosya, veritabanı veya sanal makinenin belirli andaki kopyasını saklar ve veri kaybına karşı korur. Site Recovery ise hizmet sürekliliği sağlar: iş yükünü ikincil bölgeye sürekli çoğaltır ve felaket anında sistemin dakikalar içinde orada çalışmaya başlamasını sağlar. Kapsamlı bir DR stratejisi genellikle ikisini birlikte kullanır.
Ransomware saldırısında yedekler nasıl korunur?
Modern ransomware saldırıları önce yedekleri hedefler. Immutable vault ile yedekler belirlenen süre boyunca hiç kimse tarafından (yönetici dahil) silinemez veya değiştirilemez hale getirilir. Soft delete, çok kullanıcılı yetkilendirme (MUA) ve yedek altyapısının ayrı güvenlik sınırında tutulması ek koruma katmanları oluşturur.
DR maliyeti nasıl optimize edilir?
Her iş yükü aynı korumayı gerektirmez. Kritiklik katmanlaması ile yüksek öncelikli sistemlere sıcak bekleme (düşük RTO), orta katmana Site Recovery çoğaltması, düşük önceliğe yalnızca yedekleme atanır. Azure'da DR ortamı felaket anına kadar kapalı tutulabildiği için geleneksel ikincil veri merkezine kıyasla önemli tasarruf sağlanır.
DR tatbikatı üretim ortamını etkiler mi?
Hayır. Azure Site Recovery'nin test failover özelliği, kurtarma planını izole bir ağda çalıştırır; üretim çoğaltması kesintisiz devam eder. Bu sayede tatbikatlar iş saatleri içinde bile risksiz yapılabilir ve planın çalıştığı düzenli olarak kanıtlanır.
İş etki analizi (BIA) yapılmadan doğrudan yedekleme kurulamaz mı?
Kurulabilir, ancak sonuç genellikle ya aşırı ya da eksik korumadır. İş etki analizi, her sistemin durması hâlinde iş üzerindeki finansal, operasyonel ve yasal etkiyi ortaya koyar; RTO ve RPO hedefleri bu etkiden türer. BIA olmadan tüm iş yükleri aynı politikaya bağlanır, kritik olmayan sistemlere gereksiz maliyet, kritik sistemlere yetersiz koruma verilir. Bu nedenle teknoloji seçiminden önce her zaman iş birimleriyle birlikte kritiklik katmanlaması yaparım.
DR tatbikatı ne sıklıkta yapılmalı?
Sıklık kritiklik katmanına ve değişim hızına bağlıdır. En düşük RTO hedefine sahip Tier 0 sistemleri için çeyreklik, iş açısından önemli sistemler için altı aylık ile yıllık aralık tipik bir başlangıçtır; ayrıca büyük bir mimari değişiklik, yeni kritik iş yükü veya düzenleyici denetim öncesinde ek tatbikat planlanır. Amaç takvimi doldurmak değil, planın güncel kaldığını ve ölçülen kurtarma süresinin hedeflerle uyumlu olduğunu sürekli kanıtlamaktır.
Diğer Hizmetler
İleri Güvenlik & Uyumluluk
Sıfır Güven Mimarisi ile kurumsal güvenlik duruşunuzu Azure üzerinde güçlendiriyorum.
Detayları GörBulut Göçü & Modernizasyon
Eski sistemlerinizi Azure'a güvenli, kesintisiz ve stratejik biçimde taşıyorum.
Detayları GörAzure Yönetişim & Landing Zone
Cloud Adoption Framework ve Azure Landing Zone ile bulut ortamınızı kontrollü, uyumlu ve ölçeklenebilir bir temele oturtuyorum.
Detayları Gör