Microsoft, 28 Ekim 2026’da Azure Backup Cross Tenant Restore özelliğini public preview olarak duyurdu. Kaynak tenantın erişimi kaybedildiğinde, önceden eşlenmiş bir vault üzerinden VM yedeğini başka bir tenantta geri yüklemek artık denenebiliyor. Bu haber, özellikle kimlik ortamı ele geçirildiğinde yedeklerinize nasıl ulaşacağınızı planlıyorsanız ilginizi çekmeli. Ben duyuruyu mevcut kurtarma planını sınamak için yeni bir seçenek olarak okuyorum. Önce hangi VM yedeğinin bu seçeneğe uygun olduğuna bakacağım, sonra vault eşlemesi ile hedef tenantın yetkilerini ve restore provasını nasıl kontrol edeceğinizi anlatacağım.
Yedek var, peki hangi recovery point?
Microsoft’un kapsam açıklaması Azure VM için Recovery Services vault’u işaret ediyor. Restore yalnızca vaulted recovery point üzerinden ve alternate location restore olarak yapılabiliyor. Kaynak VM’nin yerinde üzerine yazma seçeneği yok, hedef tenantta başka bir konum hazırlıyorsunuz. Vault’ta görünen bir recovery point, hedef tenantta restore edilip VM açılana kadar kurtarma planında yalnızca bir aday.
Azure VM yedekleme akışında önce snapshot oluşur, veri daha sonra vault’a aktarılır. Yedekleme ekranında bir recovery point görmek, onun vault katmanına geçtiğini tek başına kanıtlamaz. Snapshot-only recovery point bu özellikte kullanılamıyor, archive-tier recovery point de Azure VM için kapsam dışında. En güncel noktayı seçeceğinizi varsayıp geçmeyin, restore provasında seçilecek noktanın katmanını kontrol edin.
Azure Blob Storage üzerinde MSSQL DB yedekleme yazımda yedeği alıp container içinde varlığını kontrol etme adımını anlatmıştım. Aynı kontrol mantığı burada da geçerli, ama bu kez başka tenantta geri yüklenen VM’nin çalışıp çalışmadığını doğrulamak gerekiyor. Projelerde yedek kontrolü konuşulurken hep bu ayrımı öne çıkarırım. Dosyanın veya recovery point’in varlığıyla geri dönüşün sonucunu aynı kutuya koymayın.
Bir de VM’nin nasıl korunduğuna bakın. Destek sınırlarında Confidential VM ve Azure Disk Encryption ile şifrelenmiş VM açıkça dışarıda. Azure Backup’ın başka bir senaryoda bu makinelerin yedeğini alabilmesi, tenantlar arası restore için de destek verdiği anlamına gelmiyor. Envanterinizde bu tip makineler varsa onları bu plana dahil etmeyin, ayrı bir kurtarma yolu tasarlayın.
Korunan VM’leri bir tabloya dökmek burada vakit kazandırır. Her satırda VM türünü ve şifreleme durumunu, Recovery Services vault’un region bilgisini, kullanılabilir vaulted recovery point’in tarihini ayrı ayrı görün. Kayıtların bir kısmı yalnızca snapshot gösteriyorsa o VM’leri prova listesinde uygun diye işaretlemeyin. Bu kadar basit bir ayrım bile olay sırasında yanlış kurtarma noktasına bakarak saat kaybetmenizi önleyebilir.
Eşlemeyi kilitlenmeden önce kurun
Cross Tenant Restore’da kaynak vault ile hedef vault arasında bir eşleme kuruyorsunuz. Kurulum rehberine göre iki vault aynı Azure region’da bulunmalı. Hedef vault farklı tenantta ve bir Resource Guard ile ilişkili olmalı. Resource Guard, eşleme gibi hassas işlemler için ikinci bir yetki kontrolü koyuyor. Vault üzerinde Backup Contributor rolünüz olsa bile korunan işlemi tamamlamak için Resource Guard tarafında ayrıca yetki gerekir; multi-user authorization modeli bu ayrım üzerine kurulu.
Hedef tenantta Resource Guard’ın cross-tenant restore işlemini koruyacak şekilde ayarlanması ve iki tenantta gerekli rol atamalarının yapılması da önkoşul. Rol atamasını olay sırasında istemek, onay sürecini en kötü anda başlatmak demek. Özellikle kaynak tenantın ele geçirildiği senaryoda yeni eşleme kurabilmek için gereken kaynak yetkisine güvenemezsiniz. Bu yüzden yetki ve eşlemeyi olaydan önce tamamlayın, hedef taraftan görülebildiğini de kaydedin.
Hedef vault’a erişebiliyor olmanız kaynak vault ile eşleme oluşturma izniniz olduğunu göstermiyor. Microsoft’un rol atama adımlarında eşlemeyi kuran kişi ile restore’u yapan kişinin gereksinimleri ayrı anlatılıyor. Kurulumu yapan hesapların iki tenantta neye erişebildiğini önceden teyit edin. Kaynak tarafındaki yetkili erişimi kaybettikten sonra hedef tarafta birinin hazırlığı sıfırdan tamamlayacağını varsaymak iyi bir tatbikat planı olmaz.
Kaynak Recovery Services vault’un Properties bölümündeki Cyber recovery settings ekranında Cross Tenant Restore ayarını kontrol edersiniz. Bu ekran hazırlığın ilk adımını gösterir. VM’nin hedef tenantta açıldığını ayrıca doğrulayın. Ekran görüntüsü alacaksanız kendi test ortamınızı kullanın ve tenant, subscription ile vault kimliklerini gizleyin.
Hedef tarafta neyi sınayacaksınız?
Eşleme kurulduktan sonra hedef vault’un Backup items bölümündeki Cross Tenant mapped vaults görünümünden kaynak vault’un korunan öğelerine ulaşırsınız. Recovery point’i seçip restore ayarlarında hedef konumu belirlersiniz, işi başlattıktan sonra sonucu hedef vault’un Backup jobs bölümünden izlersiniz. Microsoft’un adım adım rehberi bu akışı gösteriyor. Kaynak vault ve korunan öğe restore sırasında hala mevcut olmalı. Hedefte eşleme görünüyor diye silinmiş bir kaynaktan kurtarma beklemeyin.
Kritik web uygulamaları için Azure servisleri yazımda, web katmanını iki bölgede kurup veritabanını tek bölgede bırakmanın korumayı eksik bıraktığını anlatmıştım. Mimariyi değerlendirirken burada da aynı soruyu sorarım. Korunduğunu düşündüğünüz VM, ihtiyaç duyacağınız koşulda gerçekten geri gelebiliyor mu? Region failover başka bir konu, tenant erişimini kaybetmek başka. Bu preview aynı region şartını koruyarak tenant sınırını aşan bir restore yolu açıyor.
Provada yalnızca işlemin başlatıldığını kaydetmekle yetinmeyin. Uygun vaulted recovery point’i seçin, hedefte restore işinin bitmesini bekleyin ve çıkan VM’nin açılıp açılmadığını kontrol edin. Ardından ağ erişimi ile uygulamanın ihtiyaç duyduğu bağımlılıkları gözden geçirin. Diskler geri gelmiş olabilir; DNS kaydı, NSG kuralı veya veritabanı bağlantısı eksikse iş yükü yine çalışmaz.
Hedef tenantta VM’nin hangi ağa bağlanacağını ve kimlerin oraya erişeceğini de prova başlamadan yazın. Bir uygulama sunucusunu geri yükleyip veritabanına ulaşamadığında başarılı restore işi ile çalışan hizmet arasında boşluk kalır. Web uygulaması mimarilerini kontrol ederken bağımlılıkları tek tek sayma alışkanlığım var, burada da hedefte her birini sınamanızı öneririm. Aynı region şartı yüzünden bölgesel kesinti planınızı ayrıca tutun. Tenant erişimi ile region kesintisini tek tatbikat sonucuyla kapatamazsınız.
Kurtarma süresi için masa başında rakam vermem. Public preview, belirli bir süre veya otomatik failover vaadi vermiyor. Restore’un ne kadar sürdüğünü kendi VM boyutunuz ve seçtiğiniz recovery point ile ölçün. Testin tarihini, seçilen noktayı ve hedefte gözlediğiniz sonucu kayda geçirin. Bir sonraki denemede aynı koşulları sağlayıp sağlayamadığınızı böyle anlarsınız.
Tenant kilitlenmeden yapılacak kontrol
- VM’nin vaulted recovery point’i var mı, snapshot-only veya archive-tier noktalara mı dayanıyorsunuz?
- Kaynak ve hedef vault aynı region’da mı? Hedef tenantta Resource Guard, rol atamaları ve vault eşlemesi hazır mı?
- Hedef vault’tan restore denemesi yapıp VM’nin açıldığını ve iş yükünün erişilebilir olduğunu gördünüz mü?
Hedef tenantta açıldığını görmediğim VM’yi kurtarma planında hazır diye işaretlemem.
Sizin kurtarma provanızda hangi kontrol adımı en çok zaman aldı? Yorumlarda konuşalım.
