RPO · Recovery Point Objective
En fazla ne kadar veri kaybını kabul edebilirim?
İş hedefidir: arızadan ne kadar eski bir veri noktasına dönülebilir? Daha yeni temiz bir nokta, daha küçük veri kaybı penceresi demektir.
Azure üzerinde iş sürekliliği
Dayanıklılığı görünür kılın.
Korumaları seçin, arızayı başlatın, hangi katmanın neyi kurtardığını görün.
HA + DR + BACKUP
Availability Zone kaybı
Sistem sağlıklı
Mimarinin tamamı için şemayı yatay kaydırın →
Hizmet sağlıklı; koruma katmanları arızaya hazır.
Hizmet trafiğiReplikasyonBackupEtkilenen bileşen
Uygulama + veri HA · senkron onay, kapasite ve quorum varsayılır
UYGULAMA DURUMU
Çalışıyor
West Europe · birincil region
KESİNTİ SÜRESİ / RTO
—
Hedef: 5 dk · henüz arıza yok
VERİ GERİLİĞİ / RPO
—
Hedef: 1 dk · henüz kurtarma yok
KAYBOLAN SİPARİŞ
—
Onaylanmış, kurtarılamayan kayıtlar
Bu rakamlar ne anlatıyor? Veri kaybını ve hizmet kesintisini zaman çizelgesinde ayırın.
Hazırsanız ilk arızayı başlatın.
Availability Zone kaybıyla başlayın. HA açıkken ikinci zone'un hizmeti nasıl devraldığını gözlemleyin.
Hedef region'a geçiş · temsili 2 dk
Seçilen temiz nokta · temsili 10 dk
Yalnız VM arızası · temsili 90 sn
Saldırganın yeterli yetkisi olduğu ve soft delete / MUA gibi diğer kontrollerin devrede olmadığı varsayılır. Kilitli immutability bu işlemi engeller.
Olay günlüğü
Simüle saatMüşteriye anlatın
Ana mesaj“Çalışıyor” olması,
“kurtarılabilir” olması değildir.
HA hizmeti sürdürür, DR başka bir lokasyonda kurtarır, Backup geçmişteki temiz veriye döndürür.
Son yedek—
Son replika—
Simülasyon iş yükü6 onaylı sipariş / dk
Bir arıza. İki farklı iş hedefi.
Veriden ne kaybettik?
Ne kadar süre durduk?
RPO geçmişe, RTO hizmetin geri dönüşüne bakar. Aynı canlı senaryoyu iki ayrı pencerede izleyin.
RTO · Recovery Time Objective
Hizmet ne kadar süre kapalı kalabilir?
İş hedefidir: arızadan doğrulanmış hizmet dönüşüne kadar izin verilen süre. Karar beklemek de bu süreye dahildir.
Arızadan önceki veri. Arızadan sonraki kesinti.
Bir örnek seçinRPO penceresiGeçmişe dönüş
—
Kurtarma noktası henüz seçilmedi.
Temiz veri noktası—Arıza anı—
—
RTO penceresiHizmetin geri dönüşü
—
Henüz arıza yok.
Arıza anı—Hizmetin döndüğü an—
—
Çizgiler kavramsaldır; sol ve sağ pencerenin ölçeği aynı değildir. Hedefler iş kararıdır, ekrandaki ölçülen sonuçlar garanti değildir. Hedefi değiştirmek veriyi veya kurtarma süresini değiştirmez.
Tespit + karar / bekleme—RTO'ya dahildir
Kurtarma + doğrulama—Failover, restore veya HA geçişi
Kurtarılamayan onaylı sipariş—Kesintide reddedilen yeni siparişler değil
Müşteriye anlatın
Hızlı geri dönmek, sıfır veri kaybı demek değildir.
DR örneğini başlatın. Veri noktasının arızadan önce, hizmet dönüşünün ise arızadan sonra olduğunu gösterin.
Aynı replika. Daha geç karar. Ne değişir?
Bu kontrollü karşılaştırma DR + region arızasını kullanır. Diğer koşullar aynı tutulur; yalnız operatör beklemesi değişir.
| Operatör beklemesi | Ölçülen kesinti | Veri geriliği | Kayıp sipariş |
|---|
Region erişilemediği için replika bu örnekte güncellenmez. Diğer arızalarda, replikasyon devam edebilir veya bozuk veri yayılabilir.
Microsoft Azure · servis ve yetenek rehberi
Azure ne sunuyor?
Özelliği seçin. Farkı deneyin.
Backup, DR, HA ve depolama seçeneklerini kapsamları, ön koşulları ve kaynaklarıyla keşfedin. Her kartın kendi arıza simülasyonu var.
—Servis / yetenek profili
Kaynak tarihi: 07.09.2026
Kaynak tarihi: 07.09.2026
Her servis sabit bir RPO/RTO garantisi vermez.
Dokümandaki hedef, yedek sıklığı, availability SLA ve demo süresi farklı şeylerdir. Kartlar bunları ayırır. SKU, region ve iş yükü desteğini kaynaklardan doğrulayın. Bu rehber başlıca Azure seçeneklerini kapsar; tüm ürün ve SKU'ların eksiksiz envanteri değildir.
HA dağıtım tipleri: Zone-redundant, Zonal, Non-zonal
Bunlar ayrı Azure ürünleri değil, kaynağın dağıtım tipleridir. Bir tipe tıklayarak özellik kartını ve zone arızası simülasyonunu açın.
| Dağıtım tipi | Bir zone arızasında davranış |
|---|---|
| Servis kaynağı birden fazla zone'a dağıtır; zone arızasında failover'ı Microsoft yönetir. Desteği ve etkinleştirme koşulları servise bağlıdır. | |
| Kaynak seçtiğiniz tek zone'a sabitlenir. O zone erişilemezse kaynak da etkilenir; başka zone'a geçiş kendiliğinden sağlanmaz. | |
| Yerleşimi Azure belirler; müşteri zone seçmez. Kaynak arızalı zone'da olabilir ve etkilenebilir. Non-zonal olmak zone-redundant olmak değildir. |
Birden fazla zonal kaynağı farklı zone'lara yerleştirerek dayanıklı bir uygulama kurabilirsiniz; replication, kapasite, routing ve failover tasarımı sizin sorumluluğunuzdadır. Bu, servis tarafından yönetilen zone-redundant kaynakla aynı model değildir.
RPO
RTO
Öne çıkan özellikler
Ön koşullar / tasarım kararları
Servise özel mikro-simülasyon
Bu deney ana laboratuvardan bağımsızdır. Aşağıdaki süreler öğretim örneğidir; Microsoft taahhüdü değildir.
Bu seçim sadece örnek sonucu değiştirir; gerçek bir non-zonal kaynağın zone yerleşimini seçme özelliği değildir.
01 · Arıza
02 · Korumanın tepkisi
03 · Sonuç
Demo veri geriliği—Demo kurtarma süresi—
LRS, ZRS, GRS, GZRS: ne korunuyor?
RA eki, ikincil kopyadan okuma ekler; ikincil region'a yazma veya otomatik uygulama failover'ı sağlamaz.
| Seçenek | Birincil kopyalar | İkincil region | Zone arızası | Region arızası |
|---|
Bu matris desteklenen Azure Storage hesap türleri için kavramsaldır. Redundancy, yanlış silme veya bozulmaya karşı geçmiş bir yedek değildir. GRS/GZRS'nin ikincil kopyası asenkrondur; Last Sync Time sonrasındaki yazmalar kaybolabilir.
Üç katman birbirinin alternatifi değil, tamamlayıcısıdır. Bu örnekte HA aynı region'daki zone'lar arasındadır. Çok region'lı active-active tasarımlar da HA sağlayabilir; HA her zaman “tek region” demek değildir.
Hizmeti sürdür
High Availability
Bir bileşen veya zone arızalandığında sağlıklı bileşenlerle hizmeti sürdürmeyi amaçlar.
Bu laboratuvardaÜç zone, health probe, yeterli kapasite ve senkron veri. Temsili devralma: 15 sn.
Neyi çözmez?Bu tek-region tasarımında region kaybını çözmez. Mantıksal veri bozulmasını da çoğaltabilir.
Neyi çözmez?Bu tek-region tasarımında region kaybını çözmez. Mantıksal veri bozulmasını da çoğaltabilir.
Başka lokasyonda kurtar
Disaster Recovery
Büyük bir kesintiden sonra uygulamayı alternatif lokasyonda yeniden kullanılabilir hale getirir.
Bu laboratuvardaAzure Site Recovery, asenkron VM disk replikasyonu ve hazırlanan ağ/bağımlılık runbook'u.
Neyi çözmez?Son replika, bozuk veriyi de içerebilir. ASR geçmiş noktaları sunabilir; uzun süreli yedek politikasının yerine geçmez.
Neyi çözmez?Son replika, bozuk veriyi de içerebilir. ASR geçmiş noktaları sunabilir; uzun süreli yedek politikasının yerine geçmez.
Geçmiş veriyi geri getir
Backup
Silinmiş veya bozulmuş veriyi, saklanan ve doğrulanan geçmiş bir kurtarma noktasından geri getirir.
Bu laboratuvardaAzure Backup, zamanlanmış VM yedekleri, kilitli immutable vault ve isteğe bağlı CRR.
Neyi çözmez?Çalışan ikinci bir uygulama değildir. Restore, altyapı, uygulama doğrulama ve yönlendirme zaman alır.
Neyi çözmez?Çalışan ikinci bir uygulama değildir. Restore, altyapı, uygulama doğrulama ve yönlendirme zaman alır.
Aynı arıza. Farklı mimariler.
Aşağıdaki sonuçlar canlı laboratuvarla aynı simülasyon motorundan hesaplanır.
| Mimari | Kurtarma yolu | RTO | RPO | Kayıp sipariş | Hedef değerlendirmesi |
|---|
HA hemen devreye girer. Operatör beklemesi RPO & RTO bölümünden ayarlanır ve RTO'ya dahildir. Öncelik: veri kayıpsız VM restart → temiz son DR replikası → en yeni temiz yedek. Fidye yazılımında yedek silme girişimi 20. saniyede yapılır. Otomatik demo, Azure'da DR'nin kendiliğinden başladığı anlamına gelmez; ASR geçmiş noktaları bu modelde yoktur.
RPO: Veride ne kadar geriye dönebilirim?
Recovery Point Objective, kabul edilen veri kaybı penceresi için iş hedefidir. Sonuçta gösterilen değer, arıza ile kullanılan veri noktası arasındaki süredir.
Temiz veri noktasıVeri geriliğiArıza
Örnek: 10:00 yedeği, 10:25 arızası → 25 dk geriye dönüş. Bu süredeki onaylı işlemler kaybolabilir.
RTO: Hizmet ne kadar süre kapalı kalabilir?
Recovery Time Objective, kabul edilen kesinti için iş hedefidir. Ölçülen sonuç, arızanın başlangıcından doğrulanmış hizmet dönüşüne kadar geçen süredir.
ArızaHizmet kesintisiHizmet döndü
Tespit + karar + failover/restore + bağımlılıklar + yönlendirme + doğrulama. Yalnız VM açılma süresi değildir.
10 dakikalık müşteri konuşması
Önce sorun. Sonra arızayı gösterin.
Her adım, ilgili mimariyle yeni bir deney yükler. Gerçek bir Azure kaynağına dokunulmaz.
01
HA: Bir zone giderse?
Yalnızca HA ile zone arızasını başlatın; ikinci zone otomatik devralır. “Arızayı durdur” ile başlangıca dönün, HA'yı kapatıp aynı arızayı tekrarlayın.
“Bir datacenter problemi yaşandığında müşterilerinizin ne kadar beklemesini kabul edersiniz?”
02
DR: Bütün region giderse?
DR açıkken region arızasını başlatın. Demo, operatör kararını ve ardından hedef VM, bağımlılıklar ve trafik geçişini otomatik canlandırır. Kartlardaki RTO ve RPO'yu karşılaştırın.
“Başka region'da disk kopyanız var. Peki uygulamayı ayağa kaldıran, denenmiş bir planınız var mı?”
03
Backup: Yanlış veri de çoğalır.
Tüm korumalar açıkken veri bozulmasını başlatın. Bozulmanın replikaya ulaşmasını ve temiz yedekten otomatik demo kurtarmasını izleyin; RPO ile kayıp siparişleri konuşun.
“Replikanızın çalışması yeterli mi, yoksa dünün doğru verisine de dönebilmeniz gerekiyor mu?”
04
Cyber recovery: Yedeği kim koruyor?
Fidye yazılımını başlatın. Demo yedek silmeyi dener; kilitli immutability engeli görünür. Arızayı durdurun, immutability'yi kapatın ve sonucu karşılaştırın.
“Yönetici hesabınız ele geçirilse bile doğrulanmış, temiz bir kurtarma noktanız kalır mı?”
Demo sonunda müşteriden netleştirin
İş hedefiHangi uygulama için kaç dakika kesinti ve ne kadar veri kaybı kabul edilebilir? Aynı hedef her iş yükü için geçerli mi?
Uçtan uca bağımlılıklarKimlik, DNS, ağ, veri tabanı, sırlar, kapasite, erişim ve operasyon ekibi ikinci lokasyonda hazır mı?
Kanıtlanmış kurtarmaSon restore / DR tatbikatı ne zaman yapıldı? Uygulama doğrulaması, reprotect ve failback adımları kimde?