Azure SQL Veritabanı'da otomatik yedeklemeler

Şunlar için geçerlidir:Azure SQL Veritabanı

• Azure SQL Veritabanı
• Azure SQL Yönetilen Örnek

Bu makalede, Azure SQL Veritabanı için otomatik yedekleme özelliği açıklanmaktadır.

Yedekleme ayarlarını değiştirmek için bkz . Ayarları değiştirme. Yedeklemeyi geri yüklemek için bkz . Otomatik veritabanı yedeklemelerini kullanarak kurtarma.

Veritabanı yedeklemesi nedir?

Veritabanı yedeklemeleri, verilerinizin bozulmaya veya silinmeye karşı korunmasına yardımcı olduğundan, iş sürekliliği ve olağanüstü durum kurtarma stratejilerinin önemli bir parçasıdır. Bu yedeklemeler, veritabanının yapılandırılan saklama süresi içinde belirli bir zamana kadar geri yüklenmesini sağlar. Veri koruma kurallarınız yedeklemelerinizin uzun süre (10 yıla kadar) kullanılabilir olmasını gerektiriyorsa, hem tek hem de havuza alınan veritabanları için uzun süreli saklama (LTR) yapılandırabilirsiniz.

Hiper Ölçek dışındaki hizmet katmanları için Azure SQL Veritabanı verileri yedeklemek ve geri yüklemek için SQL Server altyapı teknolojisini kullanır. Hiper ölçek veritabanları, depolama anlık görüntülerine göre yedekleme ve geri yükleme kullanır. Geleneksel SQL Server yedekleme teknolojisiyle, daha büyük veritabanlarının uzun yedekleme ve geri yükleme süreleri vardır. Anlık görüntüler kullanarak, Hyperscale veritabanı büyüklüğü fark etmeksizin anında yedekleme ve hızlı geri yükleme yetenekleri sağlar. Daha fazla bilgi edinmek için bkz . Hiper Ölçek yedeklemeleri.

Yedekleme sıklığı

Azure SQL Veritabanı oluşturur:

• Her hafta tam yedekleme.
• Her 12 veya 24 saatte bir farklı yedeklemeler.
• İşlem günlüğü yedeklemeleri yaklaşık her 10 dakikada bir yapılır.

İşlem günlüğü yedeklemelerinin tam sıklığı, hesaplama boyutuna ve veritabanı faaliyet miktarına bağlıdır. Bir veritabanını geri yüklediğinizde, Azure SQL Veritabanı hangi tam, diferansiyel ve işlem günlüğü yedeklerinin geri yükleneceğini belirler.

Hiperskala mimarisi tam, farklı veya günlük yedeklemeleri gerektirmez. Daha fazla bilgi edinmek için bkz . Hiper Ölçek yedeklemeleri.

Yedekleme alanı yedekliliği

Depolama yedeklik mekanizması, verilerinizin birden fazla kopyasını saklar, böylece planlı ve planlanmamış olaylardan korunur. Bu olaylar geçici donanım arızalarını, ağ veya güç kesintilerini ya da büyük doğal afetleri içerebilir.

Varsayılan olarak, Azure SQL Veritabanı'ndaki yeni veritabanları, coğrafi olarak yedekli depolama bloblarında yedeklenir ve bu yedekler eşleştirilmiş bir bölgeye çoğaltılır. Coğrafi yedeklilik, birincil bölgedeki yedekleme depolama alanını etkileyen kesintilere karşı korumaya yardımcı olur. Ayrıca bölgesel bir kesinti durumunda veritabanlarınızı farklı bir bölgede geri yüklemenize de olanak tanır.

Azure portalı, bazı yapılandırma ayarlarını önceden ayarlamaya yardımcı olan bir İş Yükü ortamı seçeneği sağlar. Bu ayarları geçersiz kılabilirsiniz. Bu seçenek yalnızca SQL Veritabanı portalı oluştur sayfası için geçerlidir.

• Geliştirme iş yükü ortamının seçilmesi, Yedekleme depolama yedekliliği seçeneğini yerel olarak yedekli depolama kullanacak şekilde ayarlar. Yerel olarak yedekli depolama daha az maliyete neden olur ve bölge veya coğrafi olarak çoğaltılmış depolamanın yedekliliğini gerektirmeyen üretim öncesi ortamlar için uygundur.
• Üretim iş yükü ortamının seçilmesi, Yedekleme depolama yedekliliğini varsayılan olarak coğrafi olarak yedekli depolamaya ayarlar.
• İş Yükü ortamı seçeneği de hesaplama için ilk ayarını değiştirir, ancak bu ayarı geçersiz kılabilirsiniz. Aksi takdirde İş yükü ortamı seçeneğinin lisanslama veya diğer veritabanı yapılandırma ayarları üzerinde hiçbir etkisi yoktur.

Yedeklerinizin veritabanınızın konuşlandırıldığı bölgede kalmasını sağlamak için, yedek depolama yedekliğini varsayılan coğrafi yedekli depolamadan verilerinizi bölge içinde tutan diğer depolama türlerine değiştirin. Yapılandırılan yedekleme depolama yedekliliği hem kısa süreli saklama (STR) yedeklemelerine hem de LTR yedeklemelerine uygulanır. Depolama yedekliliği hakkında daha fazla bilgi edinmek için bkz . Veri yedekliliği.

Veritabanınızı oluştururken yedekleme depolama yedekliğini yapılandırabilir ve bunu daha sonra güncelleyebiliyorsunuz. Mevcut bir veritabanında yaptığınız değişiklikler yalnızca gelecekteki yedeklemeler için geçerlidir. Mevcut bir veritabanının yedekleme depolama yedekliliğini güncelleştirdikten sonra değişikliklerin uygulanması 48 saate kadar sürebilir.

Yedeklemeler için aşağıdaki depolama yedekliliklerinden birini seçebilirsiniz:

• Yerel olarak yedekli depolama (LRS):Yedeklerinizi birincil bölgedeki tek bir fiziksel konumda zaman uyumlu olarak üç kez kopyalar. LRS en uygun maliyetli depolama seçeneğidir, ancak bölgesel kesintilere dayanıklılık veya yüksek veri dayanıklılığı garantisi gerektiren uygulamalar için önerilmez.

  

• Alanlar arası yedekli depolama (ZRS):Yedeklerinizi birincil bölgedeki üç Azure kullanılabilirlik alanına zaman uyumlu olarak kopyalar. Şu anda yalnızca belirli bölgelerde kullanılabilir.

  

• Coğrafi olarak yedekli depolama (GRS):LRS kullanarak yedeklerinizi birincil bölgedeki tek bir fiziksel konumda zaman uyumlu olarak üç kez kopyalar. Ardından verilerinizi eşleştirilmişikincil bölgedeki tek bir fiziksel konuma zaman uyumsuz olarak üç kez kopyalar.

  Sonuç:

  • Birincil bölgede üç eşzamanlı kopya.
  • Eşleştirilmiş bölgede, birincil bölgeden ikincil bölgeye asenkron şekilde kopyalanmış üç eşzamanlı kopya.

  

• Geo-Zone yedekli depolama (GZRS):Coğrafi alanlar arası yedekli depolama (GZRS), kullanılabilirlik alanları arasında yedeklilik (ZRS) tarafından sağlanan yüksek kullanılabilirliği coğrafi çoğaltma (GRS) tarafından sağlanan bölgesel kesintilere karşı koruma ile birleştirir. GZRS'de Azure, yedeklerinizi birincil bölgedeki üç Azure kullanılabilirlik bölgesine senkron olarak kopyalar, eşli ikincil bölgedeki tek bir fiziksel konuma ise üç kez asenkron olarak kopyalar.

  Microsoft, olağanüstü durum kurtarma için maksimum tutarlılık, dayanıklılık ve kullanılabilirlik, mükemmel performans ve dayanıklılık gerektiren uygulamalar için GZRS kullanılmasını önerir.

  Sonuç:

  • Birincil bölgede bulunan Kullanılabilirlik Alanları arasında yapılan üç eşzamanlı kopya.

  • Eşleştirilmiş bölgede bulunan üç zaman uyumlu kopya, birincil bölgeden ikincil bölgeye zaman uyumsuz olarak kopyalanır.

    Aşağıdaki diyagramda verilerinizin GZRS veya RA-GZRS ile nasıl çoğaltıldığı gösterilmektedir:

  

Uyarı

• Coğrafi geri yükleme , veritabanı yerel olarak yedekli veya alanlar arası yedekli depolama kullanacak şekilde güncelleştirildiği anda devre dışı bırakılır.
• Depolama yedekliliği diyagramları, birden çok kullanılabilirlik alanına (multi-az) sahip bölgeleri gösterir. Ancak bazı bölgeler sadece tek bir kullanılabilirlik bölgesi sunuyor ve ZRS'yi desteklemiyor.
• Hyperscale veritabanları için yedekleme depolama yedekliğini yalnızca oluşturulma sırasında ayarlayabilirsiniz. Kaynak sağlandıktan sonra bu ayarı değiştiremezsiniz. Mevcut Hyperscale veritabanının yedekleme depolama yedeklilik ayarlarını en düşük kapalı kalma süresiyle güncelleştirmek için etkin coğrafi çoğaltmayı kullanın. Alternatif olarak, veritabanı kopyasını kullanabilirsiniz. Hiper Ölçek yedeklemeleri ve depolama yedekliliği hakkında daha fazla bilgi edinin.

Yedekleme kullanımı

Aşağıdaki durumlarda otomatik olarak oluşturulan yedeklemeleri kullanın:

• Azure portalını, Azure PowerShell'i, Azure CLI'yı veya REST API'yi kullanarak mevcut veritabanını bekletme süresi içinde belirli bir noktaya geri yükleyin. Bu işlem özgün veritabanıyla aynı sunucuda yeni bir veritabanı oluşturur, ancak özgün veritabanının üzerine yazılmasını önlemek için farklı bir ad kullanır.

  Geri yükleme tamamlandıktan sonra, isteğe bağlı olarak özgün veritabanını silebilir ve geri yüklenen veritabanını özgün veritabanı adıyla yeniden adlandırabilirsiniz. Alternatif olarak, özgün veritabanını silmek yerine yeniden adlandırabilir ve sonra geri yüklenen veritabanını özgün veritabanı adıyla yeniden adlandırabilirsiniz.

• Silinen veritabanını, silme süresi de dahil olmak üzere saklama süresi içinde belirli bir noktaya geri yükleyin. Silinen veritabanını yalnızca orijinal veritabanını oluşturduğunuz aynı sunucuda geri getirebilirsiniz. Veritabanını silmeden önce, Azure SQL Veritabanı herhangi bir veri kaybını önlemek için nihai işlem günlüğü yedeklemesini alır.

• Veritabanını başka bir coğrafi bölgeye geri yükleyebilirsiniz. Geo-restore, veritabanınıza veya birincil bölgedeki yedeklere erişemediğinizde bölgesel bir kesintiden sonra iyileşmenize yardımcı olur. Herhangi bir Azure bölgesindeki mevcut sunucularda yeni bir veritabanı oluşturur.

  Önemli

  Coğrafi geri yükleme yalnızca coğrafi olarak yedekli yedekleme depolama alanıyla yapılandırılmış veritabanları için kullanılabilir. Şu anda bir veritabanı için coğrafi olarak çoğaltılmış yedeklemeler kullanmıyorsanız, yedek depolama yedekliğini yapılandırarak bu ayarı değiştirebilirsiniz.

• Veritabanı LTR politikası ile yapılandırılmışsa, tek veya havuzlu bir veritabanının belirli uzun vadeli yedeklemesinden bir veritabanını geri yüklemek. LTR, bir uyumluluk isteğini karşılamak veya uygulamanın eski bir sürümünü çalıştırmak için Azure portalını, Azure CLI'yı veya Azure PowerShell'i kullanarak veritabanının eski bir sürümünü geri yüklemenize olanak tanır. Daha fazla bilgi için bkz. Uzun süreli saklama.

Uyarı

Bir veritabanını geri yüklerken, kaynak yedek depolama artıklığı Coğrafi Bölge Yedekli Depolama (GZRS) olarak yapılandırılmışsa, yedek depolama artıklığı yapılandırmasını açıkça belirtmediğiniz sürece yeni veritabanı kaynak yedek depolama yapılandırmasını devralır. Bu miras, noktada zamanda geri yükleme, veritabanı kopyalama, coğrafi geri yükleme ve uzun vadeli yedeklemeden geri yükleme gibi herhangi bir geri yükleme işlemi için geçerlidir. Bu işlem sırasında, hedef Azure bölgesi belirli yedekleme depolama yedekliliğini desteklemiyorsa, geri yükleme işlemi uygun bir hata mesajıyla başarısız olur. Bu hatayı bölge için mevcut depolama seçeneklerini açıkça belirterek azaltabilirsiniz.

İkincil çoğaltmalarda yedekleme işlemleri otomatik olarak yapılır.

Business Critical servis katmanı, ikincil bir kopyadan otomatik yedeklemeler alır. Veriler her düğümdeki SQL Server işlemleri arasında çoğaltıldığı için yedekleme hizmeti, yedekleri okunamayan ikincil çoğaltmalardan alır. Bu tasarım, birincil çoğaltmanın ana iş yükünüz için ayrılmış kalmasını ve okunabilir ikincil çoğaltmanın salt okunur iş yüklerine ayrılmış olmasını sağlar. İş Açısından Kritik hizmet katmanında otomatik yedeklemeler genellikle ikincil çoğaltmadan alınır. Otomatik yedekleme ikincil bir replikada başarısız olursa, yedekleme hizmeti yedekleri birincil kopyadan alır.

İkincil çoğaltmalarda otomatik yedeklemeler:

• Varsayılan olarak etkindir.
• Hizmet katmanı ücretine ek olarak herhangi bir ek ücret olmadan dahildir.
• İş Açısından Kritik hizmet katmanına gelişmiş performans ve öngörülebilirlik getirin.

Not

Örneğinizin özelliğini devre dışı bırakmak için bir Microsoft destek bileti oluşturun.

Yetenekleri ve özellikleri geri yükleme

Bu tabloda belirli bir noktaya geri yükleme (PITR), coğrafi geri yükleme ve uzun süreli saklama özelliklerinin özellikleri özetlenmiştir.

Kurtarma süreleri hakkında bilgi için bkz. RTO ve RPO.

Backup özelliği	PITR	Coğrafi geri yükleme	LTR
SQL yedekleme türleri	Tam, diferansiyel, günlük.	PITR yedeklemelerinin coğrafi olarak çoğaltılmış en son kopyaları.	Yalnızca tam yedeklemeler.
Bekletme	Varsayılan olarak 7 gün, 1 ile 35 gün arasında yapılandırılabilir (1 ile 7 gün arasında yapılandırılabilen Temel veritabanları hariç).	Varsayılan olarak, kaynakla aynı şekilde etkindir.2	Varsayılan olarak etkin değildir. Saklama süresi 10 yıla kadardır.
Azure Depolama	Varsayılan ayarda coğrafi olarak yedeklidir. İsteğe bağlı olarak alanlar arası yedekli veya yerel olarak yedekli depolama yapılandırabilirsiniz.	PITR yedekleme depolama yedekliliği coğrafi yedekli veya coğrafi bölge yedekli (GZRS) olarak ayarlandığında kullanılabilir. PITR yedekleme depolama bölge yedekli veya yerel yedekli olduğunda kullanılamaz.	Varsayılan ayarda coğrafi olarak yedeklidir. Alanlar arası yedekli veya yerel olarak yedekli depolama yapılandırabilirsiniz.
Yedeklemeleri sabit olarak yapılandırma	Desteklenmez	Desteklenmez	Supported
Aynı bölgedeki yeni veritabanını geri yükleme	Desteklenir	Desteklenir	Desteklenir
Başka bir bölgedeki yeni veritabanını geri yükleme	Desteklenmez	Tüm Azure bölgelerinde desteklenir	Tüm Azure bölgelerinde desteklenir
Başka bir abonelikteki yeni veritabanını geri yükleme	Desteklenmez	Desteklenmiyor 3	Desteklenmiyor 3
Azure portalı aracılığıyla geri yükleme	Evet	Evet	Evet
PowerShell aracılığıyla geri yükleme	Evet	Evet	Evet
Azure CLI aracılığıyla geri yükleme	Evet	Evet	Evet

¹ Büyük veritabanları gerektiren ve iş sürekliliğini sağlaması gereken iş açısından kritik uygulamalar için yük devretme gruplarını kullanın.
² Tüm PITR yedeklemeleri varsayılan olarak coğrafi olarak yedekli depolamada depolanır, bu nedenle coğrafi geri yükleme varsayılan olarak etkinleştirilir.
³ Geçici çözüm, yeni bir sunucuya geri yüklemek ve sunucuyu başka bir aboneliğe taşımak için Kaynak Taşıma'yı kullanmak veya abonelikler arası veritabanı kopyası kullanmaktır.

Veritabanını yedekten geri yükleme

Veritabanını geri yükleme hakkında daha fazla bilgi için Yedeklemelerden veritabanını geri yükleme bölümünü inceleyebilirsiniz. Yedek yapılandırma ve geri yükleme işlemlerini incelemek için aşağıdaki örnekleri kullanın.

İşlem	Azure portalı	Azure Komut Satırı Arayüzü (Azure CLI)	Azure PowerShell
Yedek saklamayı değiştirme	SQL Veritabanı SQL Yönetilen Örnek	SQL Veritabanı SQL Yönetilen Örnek	SQL Veritabanı SQL Yönetilen Örnek
Uzun süreli yedekleme koruma süresini değiştirme	SQL Veritabanı SQL Yönetilen Örnek	SQL Veritabanı SQL Yönetilen Örnek	SQL Veritabanı SQL Yönetilen Örnek
Veritabanını belirli bir noktadan geri yükleme	SQL Veritabanı SQL Yönetilen Örnek	SQL Veritabanı SQL Yönetilen Örnek	SQL Veritabanı SQL Yönetilen Örnek
Silinen veritabanını geri yükleme	SQL Veritabanı SQL Yönetilen Örnek	SQL Veritabanı SQL Yönetilen Örnek	SQL Veritabanı SQL Yönetilen Örnek

Not

Hiper Ölçek hizmet katmanı ile Azure SQL Veritabanı diğer hizmet katmanları arasında veritabanlarının geri yüklenmesi şu anda desteklenmemektedir.

Veritabanını dışarı aktarma

Azure servisi tarafından alınan otomatik yedeklemeleri indiremezsiniz veya doğrudan erişemezsiniz. Azure, bu yedeklemeleri yalnızca geri yükleme işlemleri için kullanır.

Bir Azure SQL Veritabanı'i dışa aktarmak için başka alternatifleri düşünün.

• Arşivleme veya başka bir platforma taşımak için bir veritabanı dışa aktarmanız gerektiğinde, veritabanı şemasını ve veriyi bir BACPAC dosyasına aktarın. BACPAC dosyası, veritabanındaki meta verileri ve verileri içeren BACPAC uzantısına sahip bir ZIP dosyasıdır. BACPAC dosyasını Azure Blob depolama alanında veya şirket içi bir konumdaki yerel depolama alanında saklayabilirsiniz. Daha sonra Azure SQL Veritabanı, Azure SQL Yönetilen Örneği veya bir SQL Server örneğine geri aktarabilirsiniz.
• Ayrıca özel bağlantı kullanarak bir Azure SQL Veritabanı içeri veya dışarı aktarabilir ya da Azure hizmetlerinin sunucuya erişmesine izin vermeden Azure SQL Veritabanı içeri veya dışarı aktarabilirsiniz.

Yedekleme zamanlaması

İlk tam yedekleme, yeni bir veritabanı oluşturduğunuzda veya geri yüklemenizden hemen sonra planlanır. Bu yedekleme genellikle 30 dakika içinde tamamlanır, ancak veritabanı büyük olduğunda daha uzun sürebilir. Örneğin, geri getirilen bir veritabanında veya veritabanı kopyasında ilk yedekleme daha uzun sürebilir.

İlk tam yedeklemeden sonra, Azure otomatik olarak tüm sonraki yedeklemeleri planlar ve yönetir. SQL Veritabanı servisi, tüm veritabanı yedeklemelerinin tam zamanlamasını belirler ve genel sistem iş yükünü dengeler. Yedekleme işlerinin zamanlamasını değiştiremez veya devre dışı bırakamazsınız.

Önemli

• Yeni, geri yüklenen veya kopyalanan bir veritabanı için, ilk tam yedeklemeyi izleyen ilk işlem günlüğü yedeklemesi oluşturulduğunda belirli bir noktaya geri yükleme özelliği kullanılabilir hale gelir.
• Hiper ölçek veritabanları, ilk yedeklemenin zaman aldığı diğer veritabanlarından farklı olarak oluşturulduktan hemen sonra korunur. Hiperölçekli veritabanı büyük miktarda veriyle kopyalama veya geri yükleme yoluyla oluşturulmuş olsa bile koruma anında gerçekleşir. Daha fazla bilgi için Hiper ölçekli otomatik yedeklemeler sayfasına bakınız.

Yedekleme depolama tüketimi

SQL Server yedekleme ve geri yükleme teknolojisiyle veritabanını belirli bir noktaya geri yüklemek için kesintisiz bir yedekleme zinciri gerekir. Bu zincir bir tam yedeklemeden, isteğe bağlı olarak bir değişiklik yedeğinden ve bir veya daha fazla işlem günlüğü yedeğinden oluşur.

Azure SQL Veritabanı her hafta bir tam yedekleme programlar. PITR sağlama süresinin tamamı içinde, Azure ek tam, diferansiyel ve işlem günlüğü yedeklemelerini yapılandırma süresinden bir haftaya kadar daha uzun süre depolamalıdır.

Saklama süresi boyunca herhangi bir zamanda, saklama süresinin en eski tarihinden daha eski bir tam yedekleme bulunmalıdır. Ayrıca, bir sonraki tam yedeklemeye kadar bu tam yedeklemeden diferansiyel ve işlem günlüğü yedeklerinden oluşan kesintisiz bir zincir olmalıdır.

Hiper ölçek veritabanları farklı bir yedekleme zamanlama mekanizması kullanır. Daha fazla bilgi için bkz . Hiper Ölçek yedekleme zamanlaması.

Azure, artık PITR işlevselliği sağlamak için gerekli olmayan yedeklemeleri otomatik olarak siler. Diferansiyel yedeklemeler ve günlük yedeklemeler geri getirilebilir olmak için daha önce tam bir yedekleme gerektirdiğinden, Azure üç yedekleme türünü hepsini haftalık setlerde birlikte temizler.

TDE ile şifrelenmiş veritabanları da dahil olmak üzere tüm veritabanları için, Azure tüm tam ve farklı yedeklemeleri sıkıştırarak yedekleme depolama sıkıştırmasını ve maliyetlerini azaltır. Ortalama yedek sıkıştırma oranı üç ila dört kattır. Ancak, verilerin doğasına ve veritabanında veri sıkıştırmanın kullanılıp kullanılmadığına bağlı olarak daha düşük veya daha yüksek olabilir.

Önemli

TDE ile şifrelenmiş veritabanları için Azure, performans nedeniyle günlük yedekleme dosyalarını sıkıştırmaz. TDE ile şifrelenmeyen veritabanları için işlem günlüğü yedekleri sıkıştırılır.

Azure SQL Veritabanı toplam kullanılan yedekleme depolama alanınızı birikmeli değer olarak hesaplar. Azure, bu değeri her saat faturalama işlem hattına bildirir. İşlem hattı, her ayın sonunda tüketiminizi hesaplamak için bu saatlik kullanımı toplamaktan sorumludur. Bir veritabanını sildikten sonra, yedeklemeler yaşlanıp silindikçe tüketim azalır. Tüm yedeklemeler silindikten ve PITR artık mümkün olmadığında faturalama durdurulur.

Önemli

Azure, veritabanını silseniz bile PITR sağlamak için veritabanının yedeklerini korur. Veritabanını silmek ve yeniden oluşturmak depolama ve işlem maliyetlerinden tasarruf etse de yedekleme depolama maliyetlerini artırabilir. Bunun nedeni, Azure’un sildiğiniz her veritabanı için yedekleri saklamasıdır.

Tüketimi izleme

Azure SQL Veritabanı'deki vCore veritabanları için, veritabanı izleme paneli, her yedekleme türünün (tam, diferansiyel ve günlük) tükettiği depolamayı ayrı bir metrik olarak bildirir. Aşağıdaki ekran görüntüsünde, tek bir veritabanı için yedekleme depolama tüketiminin nasıl izleneceği gösterilmektedir.

Hyperscale'da tüketimi izleme yönergeleri için Hyperscale yedekleme tüketimini izleme bölümüne bakın.

Yedekleme depolama alanı tüketiminde hassas ayarlamalar yapma

Bir veritabanı için maksimum veri boyutuna kadar yedek depolama tüketimi için ücret alınmaz. Yedek depolama tüketiminizi azaltmak için aşağıdaki ayar tekniklerinden bazılarını göz önünde bulundurun:

• İhtiyaçlarınız için yedekleme saklama süresini en aza düşürün.
• Dizin yeniden derlemeleri gibi büyük yazma işlemlerini ihtiyaç duyduğunuzdan daha sık yapmaktan kaçının.
• Büyük veri yükleme işlemleri için kümelenmiş columnstore dizinlerini kullanmayı ve ilgili en iyi yöntemleri takip etmeyi göz önünde bulundurun. Ayrıca, kümelenmemiş dizin sayısını azaltmayı da göz önünde bulundurun.
• Genel Amaçlı hizmet katmanında, sağlanan veri depolama alanı yedekleme depolama alanının fiyatından daha ucuzdur. Sürekli yüksek fazla yedekleme depolama maliyetleriniz varsa, yedekleme depolamasında tasarruf etmek için veri depolamayı artırmayı düşünün.
• Geçici sonuçları veya geçici verileri depolamak için uygulama mantığınızda kalıcı tablolar yerine kullanın tempdb .
• Mümkün olduğunda yerel olarak yedekli yedekleme depolama alanı kullanın (örneğin geliştirme/test ortamları).

Yedekleme dosyası saklama

Azure SQL Veritabanı, yedeklemelerin hem kısa hem de uzun süreli saklama olanağı sağlar. Kısa vadeli saklama, veritabanı için saklama süresi boyunca PITR'nin gerçekleştirilmesine olanak tanır. Uzun süreli saklama, çeşitli uyumluluk gereksinimleri için yedeklemeler sağlar.

Kısa süreli saklama

Tüm yeni, geri yüklenen ve kopyalanmış veritabanları için, Azure SQL Veritabanı varsayılan olarak son yedi gün içinde PITR çalıştırmasına izin verecek kadar yeterli yedekleme sağlar. Azure SQL Veritabanı, veritabanlarının veritabanının saklanma süresi içinde herhangi bir zamanda geri getirilebilmesini sağlamak için düzenli tam, diferansiyel ve günlük yedeklemeleri alır.

Diferansiyel yedeklemeleri 12 saatte bir veya 24 saatte bir olacak şekilde ayarlayabilirsiniz. 24 saatlik değişiklik yedekleme sıklığı, veritabanını geri yüklemek için gereken süreyi 12 saatlik sıklık ile karşılaştırıldığında artırabilir. Sanal çekirdek modelinde, değişiklik yedeklemeleri için varsayılan sıklık 12 saatte bir kezdir. DTU modelinde varsayılan sıklık 24 saatte bir olur.

Veritabanınızı oluştururken STR için yedek depolama yedeklik seçeneğinizi belirleyebilir ve sonra değiştirebilirsiniz. Mevcut bir veritabanında yedek yedekleme seçeneğinizi değiştirirseniz, yeni yedekler yeni yedek seçeneğini kullanır. Azure, önceki kısa süreli yedek seçenekleriyle yapılan yedek kopyaları taşımaz veya kopyalamıyor. Azure, onları orijinal depolama hesabında tutar, bu süre 1 ila 35 gün arasında olabilir.

1 ile 7 gün arasında yapılandırılabilen Temel veritabanları dışında, her etkin veritabanı için yedekleme saklama süresini 1 ile 35 gün arasında değiştirebilirsiniz. Yedekleme depolama tüketimi bölümünde açıklandığı gibi, PITR'yi etkinleştirmek için depolanan yedeklemeler saklama süresinden daha eski olabilir. Yedeklemeleri 35 günlük en uzun kısa süreli saklama süresinden daha uzun süre saklamanız gerekiyorsa, uzun süreli saklamayı etkinleştirebilirsiniz.

Bir veritabanını silerseniz, Azure da belirli saklama süresine sahip çevrimiçi veritabanı için yedekleri aynı şekilde tutar. Silinen bir veritabanının yedekleme saklama süresini değiştiremezsiniz.

Önemli

Mantıksal bir Azure SQL sunucusunu silerseniz, o mantıksal sunucudaki tüm veritabanlarını da silersiniz. Silinen veritabanlarını kurtaramazsınız. Silinen mantıklı sunucuyu geri getiremezsiniz. Ama bir veritabanı için uzun vadeli tutma yapılandırdıysanız, LTR yedeklemeleri silinmez. Daha sonra bu yedeklemeleri, aynı abonelik içindeki farklı bir mantıksal sunucu üzerindeki veritabanlarını bir LTR yedeğinin alındığı zamandaki durumlarına geri yüklemek için kullanabilirsiniz. Daha fazla bilgi için Uzun vadeli yedeklemeyi geri yükleme bölümünü inceleyebilirsiniz.

Uzun vadeli bekletme

SQL Veritabanı için, Azure Blob Depolama'da 10 yıla kadar tam uzun süreli saklama (LTR) yedeklemeleri yapılandırabilirsiniz. LTR politikasını yapılandırdıktan sonra, Azure otomatik olarak yedekleri haftalık olarak farklı bir depolama konteynerine kopyalar.

Çeşitli uyumluluk gereksinimlerini karşılamak için, haftalık, aylık ve yıllık tam yedeklemeler için farklı tutma süreleri seçin. Sıklık ilkeye bağlıdır. Örneğin, ayar W=0, M=1 ile aylık bir LTR kopyası oluşturulur. LTR hakkında daha fazla bilgi için bkz . Uzun süreli saklama.

Mevcut bir veritabanı için yedek depolama yedekliliğini güncellemek, değişikliği yalnızca gelecekte alınan sonraki yedeklemelere uygulanır, mevcut yedeklemelere uygulanmaz. Veritabanı için tüm mevcut LTR yedeklemeleri mevcut depolama blobunda yer almaya devam eder. Yeni yedeklemeler, yapılandırılan yedekleme depolama yedekliliğine göre çoğaltılır.

Kullanılan depolama alanı, uzun süreli saklama yedeklerinin seçilen sıklığına ve saklama süresine göre değişir. LTR depolama maliyetini tahmin etmek için LTR fiyatlandırma hesaplayıcısını kullanın.

LtR yedeklemesinden hiper ölçek veritabanı geri yüklenirken okuma ölçeği özelliği devre dışı bırakılır. Etkinleştirmek için, geri yüklenen veritabanındaki ölçeği okuyun ve veritabanı oluşturulduktan sonra güncelleştirin. BIR LTR yedeklemesinden geri yüklerken hedef hizmet düzeyi hedefini belirtmeniz gerekir.

Diğer hizmet katmanlarından oluşturulan veya taşınan Hiperscale veritabanları için uzun vadeli tutumu etkinleştirebilirsiniz. Henüz desteklenmediği bir Hiper Ölçek veritabanı için LTR'yi etkinleştirmeye çalışırsanız şu hatayı alırsınız: "Bu veritabanı için uzun süreli yedekleme saklama etkinleştirilirken bir hata oluştu. Uzun vadeli yedekleme için lütfen Microsoft destek ekibine ulaşın." Bu durumda, Microsoft destek ekibiyle iletişime geçip çözüm için bir destek bileti oluşturun.

Yedekleme depolama maliyetleri

Yedekleme depolama fiyatı değişir ve satın alma modelinize (DTU veya sanal çekirdek), seçilen yedekleme depolama yedekliliği seçeneğine ve bölgeye bağlıdır. Yedek depolama için aylık gigabaytlara göre ödeme yaparsınız, tüm yedeklemeler için aynı oranda.

Fiyatlandırma için Azure SQL Veritabanı fiyatlandırma sayfasına bakın.

Not

Azure faturası, yedekleme depolama tüketiminin tamamını değil yalnızca fazla yedekleme depolama alanı tüketimini gösterir. Örneğin, varsayımsal bir senaryoda, 4 TB veri depolama sağlarsanız, 4 TB boş yedek depolama alanı elde edersiniz. Toplamda 5.8 TB yedek depolama alanı kullanıyorsanız, Azure faturası sadece 1,8 TB gösterir, çünkü sadece kullandığınız fazla yedekleme depolama için ödeme yaparsınız.

DTU modeli

DTU modelinde, veritabanları ve elastik havuzlar için PITR yedekleme depolama için varsayılan olarak yedi gün ve daha fazla sürede ekstra ücret alınmaz. PITR yedekleme depolamasının fiyatı, veritabanı veya havuz fiyatının bir parçasıdır.

DTU modelinde, LTR yedeklemelerinin tükettiği gerçek depolama miktarına göre veritabanları ve elastik havuzlar için LTR yedekleme depolama ücreti ödenir.

Sanal çekirdek modeli

Azure SQL Veritabanı, tüm yedek dosyaları boyunca toplam faturalandırılabilir yedekleme depolamanızı kümülatif değer olarak hesaplar. Azure, her saat bu değeri faturalama hattına gönderir. Pipeline, bu saatlik kullanımı toplayarak, her ayın sonunda yedek depolama tüketiminizi belirler.

Bir veritabanını silerseniz, eski yedeklemeler yaşlanıp silindikçe yedek depolama tüketimi yavaş yavaş azalır. Diferansiyel yedeklemeler ve günlük yedeklemeler geri getirilebilir olmak için daha önce tam bir yedekleme gerektirdiğinden, Azure üç yedekleme türünü hepsini haftalık setlerde birlikte temizler. Tüm yedeklemeler silindikten sonra faturalama durdurulur.

Hiper ölçekli veritabanları, yedekleme depolama maliyetlerini hesaplamak için farklı bir yöntem kullanır. Daha fazla bilgi için bkz . Hiper Ölçek yedekleme depolama maliyetleri.

Tek veritabanları için, ek ücret ödemeden veritabanı için en yüksek veri depolama boyutuna eşit olan bir yedek depolama alanı miktarı sağlanır. Aşağıdaki denklem, toplam faturalandırılabilir yedek depolama kullanımını hesaplar:

Total billable backup storage size = (size of full backups + size of differential backups + size of log backups) – maximum data storage

Elastik havuzlar için, havuzun depolama boyutu için belirlenen en yüksek veri depolama miktarına eşit bir yedek depolama alanı ek ücret ödemeden sağlanır. Ortak veritabanları için faturalandırılabilir yedekleme depolama alanının toplam miktarı havuz düzeyinde hesaplanır ve şu şekilde hesaplanır:

Total billable backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - maximum pool data storage

Varsa, toplam faturalandırılabilir yedek depolama için, yedek depolama yedekliliğine göre ayda gigabayt başına ödeme yaparsınız. Bu yedekleme depolama alanı tüketimi, tek tek veritabanlarının, elastik havuzların ve yönetilen örneklerin iş yüküne ve boyutuna bağlıdır. Yoğun şekilde değiştirilmiş veritabanlarında, bu yedeklemelerin boyutu değiştirilen veri miktarıyla orantılı olduğundan daha büyük boyutlarda differansiyel ve günlük yedeklemeler bulunur. Bu nedenle, bu tür veritabanları daha yüksek yedekleme ücretlerine sahiptir.

Basitleştirilmiş bir örnek olarak, bir veritabanının 744 GB yedek depolama biriktirdiğini ve veritabanının tamamen boş kaldığı için bu miktarın tüm ay boyunca sabit kaldığını varsayın. Bu toplu depolama tüketimini saatlik kullanıma dönüştürmek için 744,0'a bölün (ayda 31 gün, günde 24 saat). SQL Veritabanı, veritabanının her saat başına 1 GB PITR yedekleme tükettiğini ve bunun sabit bir hızda olduğunu Azure faturalama işlem hattına rapor eder. Azure faturalandırması bu tüketimi toplar ve tüm ay boyunca 744 GB kullanım gösterir. Maliyet, bölgenizdeki aylık gigabayt oranına bağlıdır.

İşte başka bir örnek. Aynı boşta olan veritabanının bekletme süresini ayın ortasında 7 günden 14 güne çıkardığını varsayalım. Bu artış, toplam yedekleme depolama alanının iki katına çıkararak 1.488 GB'a çıkarılmasına neden olur. SQL Veritabanı, ayın ilk yarısında 1 ile 372 saatler arasında 1 GB kullanım raporu verir. 373 ila 744. saatler (ayın ikinci yarısı) için kullanımı 2 GB olarak bildirir. Bu kullanım aylık 1.116 GB nihai faturaya ulaşıyor.

Gerçek yedekleme faturalama senaryoları daha karmaşıktır. Veritabanındaki değişim oranı iş yüküne bağlı ve zamanla değişken olduğundan, her diferansiyel ve günlük yedeklemenin boyutu da değişir. Yedekleme depolamasının saatlik tüketimi buna göre dalgalı.

Her değişiklik yedeği, son tam yedeklemeden sonra veritabanında yapılan tüm değişiklikleri de içerir. Bu nedenle, tüm fark yedeklemelerinin toplam boyutu bir hafta boyunca kademeli olarak artar. Daha sonra, eski bir tam, diferansiyel ve günlük yedekleme kümesi eskidikten sonra keskin bir şekilde düşer.

Örneğin, dizin yeniden derlemesi gibi yoğun bir yazma etkinliğinin tam yedekleme tamamlandıktan hemen sonra çalıştığını varsayalım. Endeks yeniden yapısının yaptığı değişiklikler şunları içerir:

• Yeniden oluşturma süresi boyunca alınan işlem günlüğü yedeklemelerinde.
• Bir sonraki diferansiyel yedeklemede.
• Bir sonraki tam yedekleme yapılana kadar alınan her diferansiyel yedeklemede.

Daha büyük veritabanlarındaki son senaryoda, Azure’daki bir optimizasyon, diferansiyel yedekleme aksi takdirde aşırı büyük olacaksa diferansiyel yedek yerine tam yedek oluşturur. Bu optimizasyon, tüm diferansiyel yedeklemelerin boyutunu bir sonraki tam yedeklemeye kadar azaltır.

İzleme tüketimi bölümünde açıklandığı gibi, zaman içinde her yedekleme türü (tam, fark, işlem günlüğü) için toplam yedekleme depolama tüketimini izleyebilirsiniz.

Maliyetleri izleme

Yedekleme depolama maliyetlerini anlamak için Azure portalında Maliyet Yönetimi + Faturalama'ya gidin. Maliyet Yönetimi'ne ve ardından Maliyet analizi'ne tıklayın. Kapsam için istediğiniz aboneliği seçin ve ilgilendiğiniz zaman aralığı ve hizmet için aşağıdaki gibi filtreleyin:

1. Hizmet adı için bir filtre ekleyin.

2. Açılan listede tek bir veritabanı veya elastik veritabanı havuzu için sql veritabanı'nı seçin.

3. Ölçüm alt kategorisi için başka bir filtre ekleyin.

4. PITR yedekleme maliyetlerini izlemek için açılan listeden tek veritabanı veya elastik veritabanı havuzu için tek veritabanı/elastik havuz pitr yedekleme depolama alanını seçin. Yedekleme depolama alanı tüketimi varsa göstergeler yalnızca o durumda gösterilir.

   LTR yedekleme maliyetlerini izlemek için açılan listeden tek bir veritabanı veya elastik veritabanı havuzu için ltr yedekleme depolama alanını seçin. Yedekleme depolama alanı tüketimi varsa göstergeler yalnızca o durumda gösterilir.

Depolama ve işlem alt kategorileri de ilginizi çekebilir, ancak bunlar yedekleme depolama maliyetleriyle ilişkili değildir.

Önemli

Ölçümler yalnızca şu anda kullanımda olan sayaçlar için görünür. Sayaç kullanılamıyorsa, büyük olasılıkla kategori şu anda kullanılmıyor olabilir. Örneğin, depolama sayacı, depolama tüketmeyen kaynaklar için görünür değildir. PITR veya LTR yedek depolama tüketimi yoksa bu sayaçlar görünmez.

Daha fazla bilgi için bkz Azure SQL Veritabanı maliyet yönetimi.

Şifrelenmiş yedeklemeler

Veritabanınızı TDE kullanarak şifrelerseniz, LTR yedekleri dahil olmak üzere yedekler beklemede otomatik olarak şifrelenir. Azure SQL Veritabanı’ndaki tüm yeni veritabanları varsayılan olarak TDE etkin şekilde yapılandırılır. TDE hakkında daha fazla bilgi için bkz. SQL Veritabanı ile saydam veri şifreleme.

Yedekleme bütünlüğü

Azure SQL Veritabanı, gerektiğinde yerleşik teknikler kullanarak belirli veri bozulmalarını otomatik olarak ele alır ve herhangi bir veri kaybı yaşanmaz. Azure SQL Veritabanı'te, SQL Database Engine, hizmet yönetimli yedeklemeler sırasında ve her geri yükleme işlemi sırasında sayfa doğrulaması gerçekleştirir. Bütünlük denetimi sırasında bulunan sorunlar, mühendislik ekibine uyarı gönderilmesine neden olur.

Ekstra bir koruma katmanı olarak, yedek geri yüklemeyi test edebilir ve bütünlük kontrolleri yapabilirsiniz. Daha fazla bilgi için bkz. Data integrity in Azure SQL Veritabanı.

Tüm veritabanı yedeklemeleri, ekstra yedekleme bütünlüğü sağlamak için bu CHECKSUM seçeneği kullanır.

Yedekleme koruması

Microsoft'a ait Azure abonelikleri, Azure SQL Veritabanı yedeklemelerini güvenli, dahili Azure Depolama hesapları kullanarak yönetir. Bu yedeklemelere dışarıdan erişemezsiniz, bu yüzden güçlü veri izolasyonu ve koruması sağlarlar. Microsoft içinde, yalnızca arka uç servisleri bu yedeklemelere erişebilir, oluşturabilir, kopyalayabilir veya geri getirebilir. Geliştiriciler de dahil olmak üzere Microsoft mühendislerinin sürekli erişimi yoktur. Microsoft, maruz kalmayı en aza indirmek ve güvenliği en üst düzeye çıkarmak için, belirli müşteri sorunlarını gidermek kesinlikle gerekliyse, katı denetim kontrolleri altında sadeceIn-Time (JIT) erişimi elde edebilir.

Yedekler, saklama süresi bittikten sonra otomatik olarak silinir.

Yedek saklama yoluyla uyumluluk

Varsayılan saklama süresi uyumluluk gereksinimlerinizi karşılamıyorsa, PITR saklama süresini değiştirin. Daha fazla bilgi için bkz . PITR yedekleme saklama süresini değiştirme.

Veritabanınızı DTU tabanlı bir hizmet katmanından vCore tabanlı bir hizmet katmanına taşıdığınızda, geçiş PITR tutma özelliğini koruyarak uygulamanızın veri kurtarma politikasının tehlikesiz olmasını sağlar.

Not

GDPR kapsamındaki yükümlülüklerinizi desteklemek için Azure SQL Veritabanı yedeklemelerinde kişisel verileri silme adımları için Otomatik yedekleme ayarlarını değiştir sayfasına bakınız. GDPR hakkında genel bilgiler için, Microsoft Güven Merkezinin GDPR bölümüne ve Servis güven portalının GDPR bölümüne bakın.

Yedekleme depolama yedekliliğini sağlamak için Azure İlkesi'yi kullanın.

Tüm verilerinizi tek bir Azure bölgesinde tutmanızı gerektiren veri yerleşimi gereksinimleriniz varsa, Azure İlkesi kullanarak SQL veritabanınız için bölge yedekli veya yerel yedekli yedeklemeleri zorunlu kılabilirsiniz.

Azure İlkesi, Azure kaynaklarına kural uygulayan ilkeler oluşturmak, atamak ve yönetmek için kullanabileceğiniz bir hizmettir. Azure İlkesi, bu kaynakların kurumsal standartlarınız ve hizmet seviyesi anlaşmalarınızla uyumlu kalmasını sağlar. Daha fazla bilgi için bkz. Azure İlkesi genel bakış.

Yerleşik yedekleme depolama yedekliliği ilkeleri

Kurumsal düzeyde veri ikamet gereksinimlerini uygulamak için, Azure portalı veya Azure PowerShell kullanarak aboneliğe politika atamak.

Örneğin, "Azure SQL DB GRS yedeklemesini kullanmamalıdır" politikasını etkinleştirirseniz, kullanıcılar varsayılan depolama ile küresel yedek depolama olarak veritabanları oluşturamaz. Bu politika, kullanıcıların GRS kullanmasını engeller ve "Yedek depolama hesabı tipini 'Standard_RAGRS' olarak yapılandırma veritabanı oluşturma veya güncelleme sırasında başarısız oldu" hata mesajını döndürür.

SQL Veritabanı için yerleşik politika tanımlarının tam listesi için politika referansına bakınız.

Önemli

Azure politikaları, T-SQL ile veritabanı oluşturduğunuzda uygulanmaz. T-SQL kullanarak bir veritabanı oluştururken veri yerleşimini belirtmek için, CREATE DATABASE ifadesindeki BACKUP_STORAGE_REDUNDANCY parametresine girdi olarak LOCAL veya ZONE kullanın.

İlgili içerik

• diğer SQL Veritabanı iş sürekliliği çözümleri hakkında bilgi edinmek için bkz. İş sürekliliğine genel bakış.
• Yedekleme ayarlarını değiştirmek için bkz . Ayarları değiştirme.
• Yedeklemeyi geri yüklemek için bkz . Yedeklemeleri kullanarak kurtarma veya PowerShell kullanarak veritabanını belirli bir noktaya geri yükleme.
• Azure Blob Depolama'da otomatik yedeklemelerin uzun süreli saklamasını yapılandırma, yönetme ve geri yükleme hakkında bilgi için bkz. Uzun süreli yedekleme saklamasını yönetme.
• Azure SQL Yönetilen Örneği için SQL Yönetilen Örneği için Otomatik Yedeklemeler bölümüne bakın.
• Azure SQL Veritabanı için değiştirilebilir yapılandırma başvurusu