SQL Server'ın her zaman kullanılabilirlik gruplarını yedekleme

Azure Backup, SQL Server Always On kullanılabilirlik gruplarını (AG) yedeklemek için, tüm düğümler Kurtarma Hizmetleri kasasıyla aynı bölgede ve abonelikte olduğu sürece uçtan uca destek sunar. Ancak AG düğümleri bölgelere/aboneliklere/şirket içi ve Azure'a yayılmışsa dikkat edilmesi gereken birkaç nokta vardır.

Bugün desteklediğimiz yedekleme ve geri yükleme senaryolarını görüntülemek için destek matrisine bakın. Sık sorulan sorular için sık sorulan sorulara bakın.

SQL Server sürümüne göre yedekleme tercih davranışı

İkincil çoğaltmalarda tam ve değişiklik yedekleme desteği SQL Server sürüme bağlıdır. AG yedekleme tercihi ve SQL Server sürümü, her yedekleme türü için seçilen düğümü belirler.

SQL Server 2022 ve öncesi

Azure Backup SQL AG tarafından kullanılan yedekleme tercihi, yalnızca birincil çoğaltıcıdan tam ve farklılık yedeklemelerini destekler. Bu nedenle, yedekleme tercihi ne olursa olsun bu yedekleme işleri her zaman Birincil düğümde çalışır. Yalnızca kopya tam ve işlem günlüğü yedeklemeleri için, yedeklemenin çalıştırılacağı düğüme karar verilirken AG yedekleme tercihi dikkate alınır.

SQL Server 2025 ve üzeri

SQL Server 2025 ve sonraki sürümlerde ikincil çoğaltmalar tam ve değişiklik yedeklemelerini de destekler. Yedekleme tercihi artık her iki yedekleme türünü de tekdüzen olarak yönetir. Yalnızca İkincil veya İkincili Tercih Et ayarını seçtiğinizde, tam ve diferansiyel yedeklemeler artık birincil düğüme ihtiyaç duymaz.

bir düğümü Azure Backup hizmetine kaydettiğinizde, bu düğüme iş yükü yedekleme uzantısını yüklersiniz. Bir AG veritabanını yedekleme için yapılandırdığınızda, yedekleme zamanlamaları AG'nin tüm kayıtlı düğümlerine gönderilir. Zamanlamalar tüm AG düğümlerinde tetiklenir ve bu düğümlerdeki iş yükü yedekleme uzantıları, hangi düğümün yedeklemeyi gerçekleştirebileceğine karar vermek için kendi aralarında senkronize olur. Düğüm seçimi, yedekleme türüne ve SQL Server sürümüne göre yedekleme tercihi davranışı bölümünde açıklanan yedekleme tercihine bağlıdır.

Seçili düğüm yedekleme görevine devam ederken, diğer düğümlerde tetiklenen iş işlemden vazgeçiyor, yani işi atlıyor.

AG düğümlerini Kurtarma Hizmetleri deposuna kaydetme

Kurtarma Hizmetleri kasası, veritabanlarının yalnızca kasayla aynı bölgedeki ve abonelikteki VM'lerden yedeklerini destekler.

SQL Server 2022 ve öncesi:

• Birincil düğümü kasaya kaydedin (aksi takdirde tam yedeklemeler gerçekleşemez).
• Yedekleme tercihi yalnızca ikincilse kasaya en az bir ikincil düğüm kaydedin (aksi takdirde günlük/yalnızca kopyalama tam yedeklemeleri gerçekleşemez).

AG veritabanları için yedeklemeleri yapılandırma işlemi, yukarıdaki koşullar karşılanmazsa FabricSvcBackupPreferenceCheckFailedUserError hata koduyla başarısız olur.

SQL Server 2025 ve üzeri:

• AG yedekleme yapılandırması için birincil düğüm kaydı artık zorunlu değildir . Tam ve diferansiyel yedeklemeler artık ikincil çoğaltmalar üzerinde çalışabildiğinden, yedekleme tercihi Yalnızca İkincil veya İkincil Tercih Et olduğunda yedeklemeleri yalnızca ikincil düğümler kayıtlıyken yapılandırabilirsiniz.
• Birincil yedekleme tercihi için birincil düğümün hala kayıtlı olması gerekir.
• Seçilen yedekleme tercihini karşılayan en az bir düğüm kaydedin.

Şimdi aşağıdaki AG dağıtımını bir referans noktası olarak ele alalım.

Verilen örnek AG dağıtımına bağlı olarak, aşağıda dikkat edilmesi gereken çeşitli noktalar verilmiştir:

• Birincil düğüm bölge 1 ve abonelik 1'de olduğundan, bu AG'yi korumak için Kurtarma Hizmetleri kasasının (Kasa 1) Bölge 1 ve Abonelik 1'de olması gerekir.
• VM3 farklı bir abonelikte olduğundan Vault 1'e kaydedilemez.
• VM4 farklı bir bölgede olduğundan Vault 1'e kaydedilemez.
• Yedekleme tercihi yalnızca ikincilse VM1 (Birincil) ve VM2 (İkincil) öğesini Kasa 1'e kaydedin. SQL Server 2022 ve önceki sürümlerinde, tam yedeklemeler birincil düğümü gerektirir, bu nedenle her iki düğümü de kaydeder; SQL Server 2025 ve sonraki sürümlerde vm2 tek başına yeterlidir. Diğer yedekleme tercihleri için VM1'i (Birincil) Kasa 1'e kaydedin; VM2 isteğe bağlıdır.
• VM3’ü 2. abonelikteki 2 numaralı kasaya kaydedebilirsiniz; bu durumda AG veritabanları 2 numaralı kasada koruma amacıyla görünür hâle gelir, ancak 2 numaralı kasada birincil düğüm bulunmadığından SQL Server 2022 ve önceki sürümlerde yedeklemeleri yapılandırma işlemi başarısız olur. SQL Server 2025 ve sonraki sürümlerde, yedekleme tercihi Yalnızca İkincil veya İkincil Tercih ise kasa 2'de yedeklemeleri yapılandırabilirsiniz.
• Benzer şekilde, VM4'i bölge 2'deki kasa 4'e kaydedebilirsiniz ancak birincil düğüm kasa 4'e kaydedilmediğinden yedeklemeleri yapılandırma işlemi 2022 SQL Server ve önceki sürümlerde başarısız olur. SQL Server 2025 ve sonraki sürümlerde, yedekleme tercihi Yalnızca İkincil veya İkincil Tercih ise kasa 4'te yedeklemeleri yapılandırabilirsiniz.

Yük devretmeyi yönetme

AG, ikincil düğümlerden birine geçiş yaptıktan sonra:

• SQL Server 2022 ve öncesi: Kasaya kayıtlıysa tam ve değişiklik yedeklemeleri yeni birincil düğümden devam eder.
• SQL Server 2025 ve üzeri: Tam ve değişiklik yedeklemeleri, yedekleme tercihini karşılayan düğümden devam eder. Yalnızca İkincil veya İkincil'i Tercih Et için bu yedeklemeler ikincil çoğaltmada çalıştırılabilir.
• Günlük yedeklemeler ve yalnızca kopyalama tam yedeklemeler, yedekleme tercihine bağlı olarak birincil veya ikincil düğümden yapılmaya devam edecektir.

Yukarıdaki örnek AG dağıtımına bağlı olarak, çeşitli yük devretme olasılıkları aşağıda listelenmiştir.

• VM2'ye yük devretme
  • VM2'den tam ve diferansiyel yedeklemeler yapılacaktır.
  • Yedekleme tercihlerine bağlı olarak VM1 veya VM2 tarafından günlük ve yalnızca kopya tam yedeklemeler yapılacaktır.
• VM3'e yük devretme (başka bir abonelik)
  • Kasa 2'de yedeklemeler yapılandırılmamış olduğundan yedekleme gerçekleşmez.
  • SQL Server 2022 ve önceki sürümlerde yedekleme tercihi yalnızca ikincil değilse, birincil düğüm bu kasada kayıtlı olduğundan artık Kasa 2'de yedeklemeleri yapılandırabilirsiniz. SQL Server 2025 ve sonraki sürümlerde, Vault 2'deki kayıtlı düğüm seçilen yedekleme tercihini karşıladığında yedeklemeleri de yapılandırabilirsiniz. Bu koşul çakışmalara veya yedekleme hatalarına yol açabilir. Daha fazla bilgi için bkz. Çok bölgeli AG için yedeklemeleri yapılandırma.
• Başka bir bölgedeki VM4'e yük devretme
  • Kasa 4'te yedeklemeler yapılandırılmamış olduğundan yedekleme gerçekleşmez.
  • SQL Server 2022 ve önceki sürümlerde yedekleme tercihi yalnızca ikincil değilse, birincil düğüm bu kasada kayıtlı olduğundan artık Kasa 4'te yedeklemeleri yapılandırabilirsiniz. SQL Server 2025 ve sonraki sürümlerde, Vault 4'teki kayıtlı düğüm seçilen yedekleme tercihini karşıladığında yedeklemeleri de yapılandırabilirsiniz. Bu koşul çakışmalara veya yedekleme hatalarına yol açabilir. Daha fazla bilgi için bkz. Çok bölgeli AG için yedeklemeleri yapılandırma.

Çok bölgeli AG için yedeklemeleri yapılandırma

Kurtarma hizmetleri kasası abonelikler arası veya bölgeler arası yedeklemeleri desteklemez. Bu bölümde, abonelikleri veya Azure bölgelerini kapsayan AG'ler için yedeklemelerin nasıl etkinleştirileceği ve ilgili önemli noktalar özetlenir.

• Tüm düğümlerden yedeklemeleri gerçekten etkinleştirmeniz gerekip gerekmediğini değerlendirin. Bir bölgede/abonelikte AG düğümlerinin çoğu varsa ve diğer düğümlere yük devretme çok nadir gerçekleşirse, yedeklemeyi ilk bölgede ayarlamak yeterli olabilir. Başka bir bölgeye/aboneliğe yük devretme işlemleri sık sık ve uzun süre gerçekleşirse, yedeklemeleri diğer bölgede proaktif olarak da ayarlamak isteyebilirsiniz.

• Yedeklemenin etkinleştirildiği her kasanın kendi kurtarma noktası zincirleri vardır. Bu kurtarma noktalarından geri yüklemeler yalnızca o kasada kayıtlı VM'lere yapılabilir.

• SQL Server 2022 ve önceki sürümler: Tam ve diferansiyel yedeklemeler yalnızca birincil düğümün bulunduğu kasada gerçekleştirilebilir. Diğer kasalardaki bu yedeklemeler sürekli başarısız oluyor. SQL Server 2025 ve sonraki sürümlerde bu davranış, Yalnızca İkincil ve İkincili Tercih Et tercihleri için değişir; bkz. SQL Server 2025: Çok Bölgeli AG yedekleme değişiklikleri.

• Günlük yedeklemeleri, yeni kasada (yeni birincil düğümün bulunduğu kasada) bir günlük yedeklemesi çalıştırılıp eski kasa için günlük zincirini kırana kadar önceki kasada çalışmaya devam eder.

  Uyarı

  Günlük yedeklemelerin başarısız olmaya başlayacağı 15 günlük kesin bir sınır vardır.

• Yalnızca kopya tam yedeklemeler tüm depolarda çalışır.

• Her kasadaki koruma ayrı bir veri kaynağı olarak kabul edilir ve ayrı olarak faturalandırılır.

İki kasa arasında günlük yedekleme çakışmalarını önlemek için yedekleme tercihini Birincil olarak ayarlamanızı öneririz. Ardından, hangi kasa birincil düğüme sahipse günlük yedeklemelerini de alır.

SQL Server 2025: Çok bölgeli AG yedekleme değişiklikleri

SQL Server 2025 ile birlikte, tam ve diferansiyel yedeklemeler artık birincil düğümü gerektirmez. Bu değişiklik şu anlama gelir:

• Birincil düğüm kaydı gerekli değildir — Yedekleme tercihiniz Yalnızca İkincil veya İkincil Tercih ise, birincil düğüm farklı bir bölgede veya abonelikte olsa bile herhangi bir kayıtlı ikincil düğümden yedekleme yapılandırabilir ve çalıştırabilirsiniz.

• Azaltılmış yük devretme etkisi — Farklı bir bölgedeki bir düğüme yük devretme işleminden sonra yedekleme tercihini karşılayan kayıtlı bir düğüm kullanılabilir olduğu sürece yedeklemeler özgün kasada devam edebilir.

Ancak temel çapraz kasa koordinasyon sınırlaması devam etmektedir; yedeklemeler birden çok kasa arasında koordine edilemez. AG düğümlerini farklı bölgelerdeki farklı kurtarma kasalarına kaydederseniz, eşzamanlı yedekleme zamanlamaları çakışabilir ve günlük zincirinin bozulmasına veya yinelenen yedeklemelere neden olabilir.

Kasalar arası çakışmaları önlemeye yönelik öneri:

• 2 düğümlü AG: Yedekleme tercihini Yalnızca İkincil veya Birincil olarak ayarlayın.
• 3+ düğüm AG: Yedekleme tercihini Birincil olarak ayarlayın.

Bu yapılandırma, aynı anda yalnızca bir kasaya ait düğümün yedekleme için uygun olmasını sağlar.

Yukarıdaki örnek AG dağıtımına bağlı olarak, tüm düğümlerden yedeklemeyi etkinleştirme adımları şunlardır. Varsayım, yedekleme tercihinin tüm adımlarda karşılanmasıdır.

1. Adım: Bölge 1, Abonelik 1'de (Kasa 1) yedeklemeleri etkinleştirme

Birincil düğüm bölge ve abonelikte olduğundan, yedeklemeleri etkinleştirmeye yönelik olağan adımlar çalışır.

2. Adım: Bölge 1, Abonelik 2'de (Kasa 2) yedeklemeleri etkinleştirme

1. AG'nin birincil düğümün Kasa 2'de yer alması için VM3'e geçiş yapması.
2. Vault 2'deki AG veritabanları için yedeklemeleri yapılandırın.
3. Bu noktada:
   1. Kayıtlı düğümlerden hiçbiri bu yedeklemeyi gerçekleştiremediği için Kasa 1'de tam veya değişiklik yedeklemeleri başarısız olur.
   2. Günlük yedeklemeler, Vault 2'de bir günlük yedekleme çalıştırılıp Vault 1 için günlük zincirini kırana kadar Vault 1'de başarılı olacaktır.
4. AG'yi VM1'e yeniden çalıştırın.

3. Adım: Bölge 2, Abonelik 1'de (Kasa 4) yedeklemeleri etkinleştirme

2. Adımla aynı.

Azure ile şirket içi ortamı kapsayan bir AG'yi yedekleme

SQL Server için Azure Backup şirket içinde çalıştırılamaz. Birincil düğüm Azure'daysa ve yedekleme tercihi Azure'daki düğümler tarafından karşılanıyorsa, Azure'daki çoğaltmalar için yedeklemeleri etkinleştirmek üzere çok bölgeli AG için yukarıdaki yönergeleri izleyebilirsiniz. Şirket içi düğüme yük devretme gerçekleşirse, Azure'de tam ve farklı yedeklemeler başarısız olur. Günlük zincirinin kopması veya 15 gün geçmesi durumuna kadar günlük yedeklemeler devam edebilir.

AG veritabanında yedekleme işleri için kısıtlama

Şu anda yedekleme kontrolü sınırları tek bir makine düzeyinde geçerlidir. Varsayılan sınır 20'dir; eşzamanlı olarak 20'den fazla yedekleme tetiklenirse, ilk 20 çalıştırılır ve diğerleri kuyruğa alınır. Çalışan işler tamamlandığında, kuyruğa alınan işler çalışmaya başlar.

Eşzamanlı yedeklemeler düğümde bellek/GÇ/CPU zorlanmasına neden oluyorsa bu değeri daha küçük bir değerle değiştirebilirsiniz. Azaltma düğüm düzeyinde olduğu için, AG düğümlerinin dengesiz olması yedekleme eşitleme sorunlarına yol açabilir. Bunu anlamak için örneğin 2 düğüm ag düşünün.

Örneğin, ilk düğümde korunan 50 tek başına veritabanı vardır ve her iki düğümde de 5 AG veritabanı korunur. Düğüm 1'de 55 veritabanı yedekleme işi zamanlanmışken Düğüm 2'de yalnızca 5 tane vardır. Ayrıca, tüm bu yedeklemeler saatte bir aynı anda çalışacak şekilde yapılandırılır. Belirli bir noktada, Düğüm 1 üzerinde 55 yedeklemenin tümü tetiklenir ve bunlardan 35'i kuyruğa alınır. Bunlardan bazıları AG veritabanı yedeklemeleri olabilir. Ancak Node 2'de AG veritabanı yedeklemeleri herhangi bir kuyruğa alınmadan devam eder.

AG veritabanı işleri bir düğümde sıralanıp başka bir düğümde çalıştırıldığından yedekleme eşitlemesi düzgün çalışmaz. Düğüm 2, Düğüm 1’in kapalı olduğunu ve bu nedenle Düğüm 1’den gelen işlerin senkronizasyon için görünmeyeceğini varsayabilir. Her iki düğüm de bağımsız olarak yedek alabildiği için bu sorun günlük zincirinin bozulmasına veya ek yedeklemelere yol açabilir.

Korunan AG veritabanı sayısı darboğaz sınırından fazla ise benzer bir sorun oluşabilir. Bu durumda DB1 için yedekleme Node 1'de kuyruğa alınırken Node 2 üzerinde çalışır.

Bu eşitleme sorunlarını önlemek için aşağıdaki yedekleme tercihlerini kullanmanızı öneririz:

• 2 düğümlük bir AG için Yedekleme Tercihi'ni Birincil veya Yalnızca İkincil olarak ayarlayın; ardından yedeklemeleri yalnızca bir düğüm yapabilir, diğeri her zaman serbest kalır.
• 2'den fazla düğüme sahip bir AG için Yedekleme Tercihi'ni Birincil olarak ayarlayın; ardından yedeklemeleri yalnızca birincil düğüm yapabilir, diğerleri serbest kalır.

AG yedeklemeleri için faturalama

Tek başına SQL örneğiyle aynı şekilde, yedeklenen bir AG örneği tek bir korumalı örnek olarak kabul edilir. Bir örnekteki tüm korumalı veritabanlarının toplam ön uç boyutu ücretlendirilir. Aşağıdaki dağıtımı göz önünde bulundurun:

Korumalı örnekler aşağıdaki gibi hesaplanır:

Korumalı veritabanını AG içinde veya dışında taşıma

Azure Backup SQL örneği veya AG adı\Veritabanı adı'nı veritabanının benzersiz adı olarak kabul eder. Tek başına veritabanı korunduğunda benzersiz adı StandAloneInstanceName\DBName idi. Bir AG altında hareket ettiğinde, benzersiz ad AGName\DBName olarak değişir. Tek başına veritabanının yedeklemeleri şu hata koduyla başarısız olmaya başlayacaktır: UserErrorBackupFailedStandaloneDatabaseMovedInToAG.

Veritabanı, AG'den korunma sağlanacak şekilde yapılandırılmalıdır. Bu, ayrı bir kurtarma noktası zincirine sahip yeni bir veri kaynağı olarak ele alınacaktır. Tek başına veritabanının eski koruması, gelecekteki yedeklemelerin tetiklenip üzerinde başarısız olmasını önlemek için verileri tutarak durdurulabilir. Benzer şekilde, korumalı bir AG veritabanı AG'nin dışına taşınıp tek başına veritabanı haline geldiğinde, yedeklemeleri şu hata koduyla başarısız olur: UserErrorBackupFailedDatabaseMovedOutOfAG.

Veritabanı, bağımsız örnek üzerinden koruma sağlamak amacıyla yapılandırılmalıdır. Bu, ayrı bir kurtarma noktası zincirine sahip yeni bir veri kaynağı olarak ele alınacaktır. AG veritabanının eski koruması, verilerin saklanarak gelecekteki yedeklemelerin tetiklenmesini ve başarısız olmasını önlemek için durdurulabilir.

AG'ye düğüm ekleme veya kaldırma

Yedeklemeler için yapılandırılmış bir AG'ye yeni bir düğüm eklendiğinde, zaten kayıtlı OLAN AG düğümlerinde çalışan iş yükü yedekleme uzantıları AG topolojisi değişikliğini algılar ve bir sonraki zamanlanmış veritabanı bulma işi sırasında Azure Backup hizmetine bildirir. Bu yeni düğüm, diğer mevcut düğümlerle aynı Kurtarma Hizmetleri kasasına yedeklemeler için kaydedildiğinde, Azure Yedekleme hizmeti, AG yedeklemelerini gerçekleştirmek için gerekli meta verilerle bu yeni düğümü yapılandıran bir iş akışını tetikler.

Bu adımdan sonra yeni düğüm AG yedekleme zamanlaması bilgilerini Azure Backup hizmetinden eşitler ve eşitlenen yedekleme işlemine katılmaya başlar. Yeni düğüm yedekleme zamanlamalarını eşitleyemiyor ve yedeklemelere katılamıyorsa, düğümde yeniden kayıt tetiklenmesi, düğümün AG yedeklemeleri için yeniden yapılandırılmasını da zorlar. Benzer şekilde, düğüm kaldırma sırasında iş yükü uzantıları AG topolojisi değişikliğini algılar ve Azure Backup hizmetini bilgilendirir. Hizmet, AG veritabanlarının yedekleme zamanlamalarını temizlemek ve AG ile ilgili meta verileri silmek için kaldırılan düğümde bir düğüm yapılandırma dışı iş akışı başlatır.

AG düğümünün Azure Backup'tan kaydını kaldırın

Bir düğüm, yedekleme için yapılandırılmış bir veya daha fazla veritabanının olduğu bir AG'nin parçasıysa, Azure Backup bu düğümün kaydını kaldırmaya izin vermez. Bu, bu düğüm olmadan yedekleme tercihinin karşılanmaması durumunda gelecekteki yedekleme hatalarını önlemektir. Düğümün kaydını kaldırmak için önce onu AG'den (Uygulama Grubu) çıkarmanız gerekir. Düğüm yapılandırmayı kaldırma iş akışı tamamlandığında, bu düğümü temizleyerek kaydı kaldırabilirsiniz.

Veritabanını Azure Backup'tan AG SQL Kullanılabilirlik Gruplarına geri yükleme, veritabanını doğrudan AG'ye geri yüklemeyi desteklemez. Veritabanının tek başına bir SQL örneğine geri yüklenmesi ve ardından bir AG'ye katılması gerekir.

SQL veritabanı sunucusu için kullanılabilirlik grubu yeniden oluşturma senaryoları

Kullanılabilirlik grubunun (AG), yinelenen AG'lerin ve yedekleme öğelerinin yeniden oluşturulması, aşağıdaki senaryolarda korunabilir öğeler veya korumalı öğeler olarak listelenir:

• Zaten korunan AG'ler yeniden oluşturulduğunda, Yedeklemeyi Yapılandır sayfasında ve Korumalı öğeler listesinde yinelenen AG'ler olarak görünür. Eski AG'de zaten mevcut olan yedekleme verilerini korumak istiyorsanız, yeni AG öğelerinde yedeklemeleri yeniden oluşturmadan ve zamanlamadan önce Korumayı durdur ve verileri koru seçeneğini kullanarak yedeklemeyi durdurun.

  Tasarım gereği Azure Backup, Korumalı öğeler listesindeki yinelenen öğeleri ve Yedeklemeyi Yapılandır sayfasını veya Korunabilir öğe listesini listeler ve yedekleme verilerini korumak isteyene kadar bu öğeleri görüntüler.

• Eski AG'den yedekleme verilerini istemiyorsanız, yeni AG'de yedeklemeleri yeniden oluşturmadan ve zamanlamadan önce eski öğenin Korumayı durdur ve verileri sil seçeneğini kullanarak yedekleme işlemini durdurun.

  Dikkat

  Korumayı durdurma ve verileri silme yıkıcı bir işlemdir.

• Yedekleme hatalarını önlemek için yukarıdaki Korumayı durdurma işleminden birini gerçekleştirdikten sonra AG'yi yeniden oluşturabilirsiniz.

SQL Server 2025 AG yedeklemesinde dikkat edilmesi gerekenler

Yapılandırmadan sonra yedekleme tercihi değişiklikleri

AG yedekleme tercihini değiştirir ancak gerekli düğümü kasaya kaydetmezseniz, yedekleme işlemleri başarısız olur. Örneğin, tercihi Birincil’den Yalnızca İkincil olarak değiştirirseniz, ancak hiçbir ikincil düğüm kaydedilmediyse, günlük ve tam/fark yedeklemeleri başarısız olur. Değişikliği yapmadan önce, yeni yedekleme tercihine uyan düğümlerin kurtarma kasasına kayıtlı olduğundan her zaman emin olun.

Çok bölgeli AG yedekleme koordinasyonu

AG düğümlerini farklı bölgelerde bulunan birden çok kasa genelinde koruduğunuzda, kasalar SQL Server sürümünden bağımsız olarak aralarındaki yedeklemeleri koordine edemez. Bu senaryoda günlük zinciri kesintilerini ve yinelenen yedeklemeleri önleyen yedekleme tercih ayarlarıyla ilgili yönergeler için bkz. SQL Server 2025: Çok Bölgeli AG yedekleme değişiklikleri.

Anlık görüntü yedekleme desteği

Anlık görüntü yedeklemeleri, bir AG'nin ikincil çoğaltmaları üzerinde desteklenmez. Yedekleme ilkesinde anlık görüntü yedeklemeyi etkinleştirdiğinizde, birincil düğüm kaydı SQL Server sürümden bağımsız olarak zorunlu kalır.

Sonraki Adımlar

Nasıl yapılacağını öğrenin:

• Yedeklenen SQL Server veritabanlarını geri yükleme
• Yedeklenen SQL Server veritabanlarını yönetme

İlgili içerik

• REST API aracılığıyla Azure Backup kullanarak Azure VM'lerindeki SQL server veritabanlarını yedekleyin.
• REST API ile Azure VM'lerindeki SQL Server veritabanlarını geri yükleyin.
• Azure portalı, Azure CLI, REST API ile Azure VM'lerindeki SQL server veritabanlarını yönetin.