- Yedekleme ile felaket kurtarma aynı şey değildir
- Birinci adım: RPO, RTO ve iş yükü envanteri
- Azure Backup kurulumu: kasa, politika, koruma, geri yükleme
- Site Recovery kurulumu: çoğaltma, kurtarma planı, tatbikat
- Örnek senaryo: çok katmanlı bir uygulamanın korunması
- İzleme, maliyet bilinci ve sık hatalar
- Mindset programlarında bu beceri nerede çalışılır?
- Sık sorulan sorular
Azure Yedekleme ve Felaket Kurtarma: Backup ile Site Recovery Birlikte Nasıl Kurulur?
Azure'da RPO ve RTO hedeflerinden yola çıkarak yedekleme politikası, kurtarma kasası, Site Recovery replikasyonu, kurtarma planı ve felaket tatbikatı adım adım.
Yedekleme ile felaket kurtarma aynı şey değildir
Azure'da farklı hizmetler farklı problemleri çözer. Azure Backup veriyi korur ve gerektiğinde geri yükler: yanlışlıkla silme, bozulma ve fidye yazılımı gibi durumlara karşı geçmişe dönük kurtarma noktaları üretir. Microsoft belgeleri, Azure Backup'ın veri koruma (yedekleme ve geri yükleme) odaklı olduğunu, felaket kurtarma ve yük devretme orkestrasyonu için ise Azure Site Recovery'nin kullanılması gerektiğini açıkça belirtir.
Azure Site Recovery (ASR) ise iş yüklerini sürekli çoğaltır ve ana konumda kesinti olduğunda ikincil konuma yük devretmenizi sağlar; ana konum düzeldiğinde geri dönüş (failback) yapılabilir. Yani Backup 'dün sabahki sürüme dönmek' içindir, Site Recovery 'bölge çökerse uygulamayı başka yerde ayağa kaldırmak' içindir.
Gerçek bir iş sürekliliği stratejisi genellikle ikisini birlikte içerir. Bir sanal makine hem Site Recovery ile başka bir bölgeye çoğaltılabilir hem de Backup ile geçmişe dönük kurtarma noktalarına sahip olabilir. Çünkü çoğaltma, bozulmuş veriyi de hızla başka konuma taşıyabilir; geçmişe dönük kopya olmadan bu risk karşılanamaz.
Birinci adım: RPO, RTO ve iş yükü envanteri
Kurulumdan önce her iş yükü için hedef çifti belirlenir. RPO (Recovery Point Objective) en fazla ne kadar veri kaybına katlanabileceğinizi, RTO (Recovery Time Objective) ise hizmetin en fazla ne kadar sürede geri gelmesi gerektiğini ifade eder. Bu hedefler iş birimiyle birlikte konuşularak belirlenir; teknik ekibin tahmini yetmez. Muhasebe sistemi ile iç wiki aynı hedefe sahip olmayacaktır.
Envanter çıkarırken şunları not edin: • İş yükü türü: sanal makine, veritabanı, dosya paylaşımı, depolama blobları, kapsayıcı • Kritiklik sınıfı ve iş etkisi • RPO ve RTO hedefleri • Bağımlılıklar: uygulamanın çalışması için hangi diğer sistemlerin de ayakta olması gerekir • Saklama ve uyumluluk gereksinimleri • Ağ ve kimlik bağımlılıkları
Microsoft belgeleri de çoğaltmayı yapılandırmadan önce uygulama bağımlılıklarının, kurtarma gereksinimlerinin, ağ bağlantısının ve hedef ortam kapasitesinin değerlendirilmesini önerir. Hedefleri yüksek olan iş yükleri hem Backup hem Site Recovery ile korunur; düşük kritiklikteki iş yükleri için yalnızca Backup yeterli olabilir.
Azure Backup kurulumu: kasa, politika, koruma, geri yükleme
Azure Backup'ın temel bileşenleri belgelerde şöyle sıralanır: yedekleme verisini ve kurtarma noktalarını saklayan ve güvenlik sınırı olarak çalışan bir kasa (Recovery Services vault ya da Backup vault), yedeklemenin ne zaman çalışacağını ve ne kadar saklanacağını tanımlayan yedekleme politikaları ve iş yüküne göre gerekli olan uzantı ya da ajan.
Akış şöyledir: • Kasayı uygun abonelikte ve bölgede oluşturun; depolama yedeklilik türünü seçin. Belgelere göre coğrafi yedekli depolama (GRS) varsayılan ve önerilen seçenektir; yerel yedekli (LRS) ve bölge yedekli (ZRS) seçenekler de bulunur • Politikayı tanımlayın: yedekleme sıklığı, saklama süresi, kısa ve uzun vadeli saklama gereksinimleri • İş yüklerini politikaya bağlayarak korumayı etkinleştirin • Politikayı Azure Policy ile yönetim grubu düzeyinde zorunlu hale getirmeyi düşünün; böylece yeni oluşan sanal makineler korumasız kalmaz • İlk yedeklemenin başarıyla tamamlandığını izleyin
Güvenlik için belgelenen yerleşik özellikler arasında yedek verinin üretim ortamından yalıtılması, silinen yedeğin belirli süre saklanması (soft delete), kurtarma noktalarının değiştirilemez kilitlenmesi (immutable backup) ve rol tabanlı erişim kontrolü bulunur. Fidye yazılımı senaryolarında yedek erişiminin yetkisini ayrı bir role bölmek önemli bir tasarım kararıdır.
Geri yükleme, dosya, disk, veritabanı ya da tüm iş yükü düzeyinde yapılabilir. Yedeğin değeri geri yüklenebilirliğiyle ölçülür; bu yüzden düzenli geri yükleme denemesi planlayın.
Site Recovery kurulumu: çoğaltma, kurtarma planı, tatbikat
Site Recovery, Azure sanal makinelerinin bir bölgeden diğerine, şirket içi VMware ve Hyper-V makinelerinin ve fiziksel sunucuların Azure'a çoğaltılmasını yönetir. Çoğaltma, uygulama verisini araya girmeden orkestre eder; yük devretmede Azure sanal makineleri çoğaltılan veriden oluşturulur.
Tipik kurulum adımları: • Hedef bölgeyi ve hedef kaynakları (kaynak grubu, sanal ağ, depolama) planlayın • Çoğaltmayı etkinleştirecek makineleri seçin ve çoğaltma ayarlarını yapın • Uygulamayla tutarlı kurtarma noktası gereken iş yüklerinde bu seçeneği değerlendirin • Çok katmanlı uygulamalar için kurtarma planı oluşturun • Hedef ağda IP, yük dengeleyici ve DNS yönlendirmesini tasarlayın • Tatbikat yapın ve sonucu belgeleyin
Kurtarma planı, birden fazla sanal makineden oluşan uygulamanın yük devretme ve kurtarma sırasını tanımlar. Makineleri gruplar, betik ya da elle yapılacak adımlar ekleyebilirsiniz. Örneğin önce veritabanı katmanı, sonra uygulama sunucuları, en sonda ön yüz makineleri başlar. Kurtarma planları Azure Automation runbook'larıyla bütünleştirilebilir.
Tatbikat (test yük devretme), devam eden çoğaltmayı etkilemeden felaket kurtarma denemesi yapmanızı sağlar. Bu, kurulumun belki de en önemli adımıdır: planın kâğıt üzerinde değil gerçekte çalıştığını gösterir. Planlı yük devretme beklenen kesintilerde veri kaybı olmadan, plansız yük devretme ise beklenmedik felaketlerde çoğaltma sıklığına bağlı minimum veri kaybıyla yapılabilir. Ana konum düzeldiğinde geri dönüş yapılır.
Örnek senaryo: çok katmanlı bir uygulamanın korunması
Kurgusal bir senaryo ele alalım: bir şirketin sipariş uygulaması sanal makinelerde çalışıyor; bir ön yüz, bir uygulama katmanı ve bir veritabanı var. İş birimi, sipariş kaybının kabul edilemez olduğunu, hizmet kesintisine ise kısa süreli tahammül edilebildiğini söylüyor.
Tasarım şöyle şekillenir. Veritabanı katmanı için uygulamayla tutarlı yedekleme ve sık kurtarma noktaları planlanır; bu, hem yanlışlıkla silinen kayıtların geri getirilmesi hem de bozulma durumlarında geçmişe dönmek içindir. Tüm sanal makineler Site Recovery ile başka bir bölgeye çoğaltılır. Kurtarma planı, veritabanı önce, ardından uygulama ve ön yüz olacak şekilde sıralanır; ağ ayarları ve DNS değişimi plana betik olarak eklenir. Düzenli aralıklı tatbikat takvime işlenir ve süre ölçülür.
Tatbikat sırasında genellikle şunlar ortaya çıkar: hedef bölgede kota yetersizliği, unutulmuş bir bağımlılık, eksik güvenlik grubu kuralı, DNS yayılma gecikmesi. Bunları gerçek felaketten önce bulmak tatbikatın asıl değeridir. Her tatbikat sonrası kısa bir değerlendirme raporu yazılır ve eksikler giderilir.
İzleme, maliyet bilinci ve sık hatalar
Yedekleme ve çoğaltma sağlığı düzenli izlenmelidir. Recovery Services kasasında yerleşik izleme ve uyarılar bulunur; ölçeği artırmak için Azure Monitor ile entegrasyon kullanılabilir. Başarısız yedekleme işleri, çoğaltma sağlığı uyarıları ve eski kurtarma noktaları için uyarı kuralları kurun.
Sık yapılan hatalar: • Yedeklemeyi felaket kurtarma sanmak (ya da tersi) • RPO ve RTO hedeflerini iş birimiyle konuşmadan tahmin etmek • Yedeklenmeyen sanal makineleri fark etmemek; politika ile zorunlu kılın • Geri yüklemeyi hiç denememek • Kurtarma planını yazıp tatbikat yapmamak • Hedef bölgede kapasite ve kota kontrolü yapmamak • Ağ, DNS ve kimlik bağımlılıklarını planlamamak • Yedek yönetimi yetkisini üretim yöneticilerinden ayırmamak; fidye yazılımı bu yetkiyi hedefler • Maliyeti yalnızca depolama olarak görmek; çoğaltma, hedef kaynaklar ve tatbikat süreçlerini de hesaba katmak
Maliyet kalemlerini kesin fiyat için Microsoft'un güncel fiyatlandırma sayfasından kontrol edin; tasarım kararlarında kritikliğe göre koruma düzeyi seçmek, her iş yükünü en yüksek seviyede korumaktan daha sürdürülebilirdir.
Mindset programlarında bu beceri nerede çalışılır?
Azure Administrator (AZ-104) Hazırlık programının 'İzleme, Yedekleme ve Sınav Hazırlık' modülü, Azure yöneticisinin bu sayfadaki işleriyle doğrudan ilgilidir; program ayrıca sanal makine, ağ ve depolama yönetimi başlıklarını içerir, bunlar yedekleme ve çoğaltma tasarımının zemin bilgisidir. Sistem yöneticileri, bulut operasyon mühendisleri ve altyapı ekipleri için uygundur.
Kurumsal ekipler için pratik değer, ekibin kendi iş yükü envanteriyle RPO ve RTO tartışmasını yapabilmesidir. Programın sınav odaklı bölümü ayrıca sertifikasyon hedefi olan çalışanlara yöneliktir.
İlgili Mindset programı
Azure Administrator (AZ-104) Hazırlık
Sık sorulan sorular
Azure Backup ile Azure Site Recovery birlikte kullanılabilir mi?
Evet, çoğu kritik iş yükü için birlikte kullanılması önerilir. Backup geçmişe dönük kurtarma noktaları sağlar ve silinme ya da bozulmaya karşı korur. Site Recovery ise iş yükünü başka bölgeye çoğaltıp yük devretmeyi sağlar. İkisi farklı riskleri karşıladığı için birbirinin yerini tutmaz.
RPO ve RTO nedir?
RPO, kabul edilebilir en fazla veri kaybıdır ve yedekleme ya da çoğaltma sıklığını belirler. RTO, hizmetin geri gelmesi için kabul edilebilir en uzun süredir ve kurtarma planının hızını belirler. Her iş yükü için iş birimiyle birlikte tanımlanmaları gerekir.
Test yük devretme canlı sistemi etkiler mi?
Microsoft belgelerine göre Site Recovery, felaket kurtarma tatbikatlarını devam eden çoğaltmayı etkilemeden yapmanıza izin verir. Yine de tatbikatı yalıtılmış bir test ağında yapmak ve çakışan IP ya da DNS kayıtlarını kontrol etmek iyi uygulamadır.
Şirket içi sunucuları da korumak mümkün mü?
Evet. Azure Backup, ajanlar aracılığıyla dosya, klasör ve sistem durumu ile Hyper-V ve VMware gibi şirket içi iş yüklerini yedekleyebilir. Site Recovery ise şirket içi VMware ve Hyper-V sanal makinelerini ve fiziksel sunucuları Azure'a çoğaltabilir. Desteklenen sürümleri Microsoft'un uyumluluk matrislerinde kontrol edin.
Yedekleme kasası depolama yedeklilik türü nasıl seçilir?
Seçim, dayanıklılık ihtiyacı ve veri yerleşimi gereksinimine bağlıdır. Coğrafi yedekli depolama bölgesel kesintiye karşı daha yüksek dayanıklılık sağlar ve belgelerde varsayılan olarak önerilir. Bölge yedekli depolama, aynı bölgede kalmak zorunda olan kritik iş yükleri için düşünülür. Yerel yedekli depolama düşük maliyetli ama sınırlı korumadır.
İlgili rehberler
Kategori: DevOps ve Bulut Teknolojileri