Azure SQL Veritabanı'da otomatik yedeklemeler

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

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ı geri yüklemesinin yapılandırılan saklama süresi içinde belirli bir noktaya 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 yedekleme/geri yükleme süreleri uzun olabilir. Anlık görüntülerin kullanılmasıyla Hiper Ölçek, veritabanı boyutundan bağımsız olarak anlık yedekleme ve hızlı geri yükleme özellikleri 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 değişiklik yedekleri .
• İşlem günlüğü yaklaşık 10 dakikada bir yedekler .

İşlem günlüğü yedeklemelerinin tam sıklığı, işlem boyutuna ve veritabanı etkinliği miktarına bağlıdır. Veritabanını geri yüklerken hangi tam, değişiklik ve işlem günlüğü yedeklerinin geri yüklenmesi gerektiği hizmet tarafından belirlenir.

Hiper Ölçek mimarisi tam, değişiklik veya günlük yedeklemeleri gerektirmez. Daha fazla bilgi edinmek için bkz . Hiper Ölçek yedeklemeleri.

Yedekleme alanı yedekliliği

Depolama yedekliliği mekanizması, verilerinizin planlı ve plansız olaylardan korunması için birden çok kopyasını depolar. 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ı yeni veritabanları yedekleri eşleştirilmiş bir bölgeye çoğaltılan coğrafi olarak yedekli depolama bloblarında depolar. 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ılınabilir. 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, işlem için ilk ayarı da değiştirir, ancak bu geçersiz kılınabilir. Aksi takdirde İş yükü ortamı seçeneğinin lisanslama veya diğer veritabanı yapılandırma ayarları üzerinde hiçbir etkisi yoktur.

Yedeklemelerinizin veritabanınızın dağıtıldığı bölge içinde kalmasını sağlamak için yedekleme depolama yedekliliğini varsayılan coğrafi olarak yedekli depolamadan, verilerinizi bölge içinde tutan diğer depolama türleriyle değiştirebilirsiniz. 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 yedekliliğini yapılandırabilir ve daha sonra güncelleştirebilirsiniz. Var olan 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 düşük 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 bunu önermiyoruz.

  

• 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 üç zaman uyumlu kopya.
  • Eşleştirilmiş bölgede, birincil bölgeden ikincil bölgeye zaman uyumsuz olarak kopyalanan üç zaman uyumlu kopya.

  

Yedekleme kullanımı

Aşağıdaki senaryolarda otomatik olarak oluşturulan yedeklemeleri kullanabilirsiniz:

• 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ı yalnızca özgün veritabanını oluşturduğunuz sunucuya geri yüklenebilir. Bir veritabanını silmeden önce hizmet, veri kaybını önlemek için son işlem günlüğü yedeğini alır.

• Veritabanını başka bir coğrafi bölgeye geri yükleyebilirsiniz. Coğrafi geri yükleme, birincil bölgedeki veritabanınıza veya yedeklemelerinize erişemiyorsanız bölgesel bir kesintiden kurtarmanıza olanak tanır. 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 veritabanı için coğrafi çoğaltmalı yedekleme kullanmıyorsanız yedekleme depolama alanının yedekliliğini yapılandırarak bunu değiştirebilirsiniz.

• Veritabanı bir LTR ilkesiyle yapılandırılmışsa, veritabanını tek veya havuza alınmış bir veritabanının belirli bir uzun vadeli yedeğinden geri yükleyin. 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.

İkincil çoğaltmalarda otomatik yedeklemeler

Otomatik yedeklemeler artık İş Açısından Kritik hizmet katmanındaki ikincil bir çoğaltmadan alınıyor. 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ındaki otomatik yedeklemeler çoğu zaman ikincil çoğaltmadan alınır. İkincil çoğaltmada otomatik yedekleme başarısız olursa, yedekleme hizmeti yedeklemeyi birincil çoğaltmadan alır.

İkincil çoğaltmalarda otomatik yedeklemeler:

• Varsayılan olarak etkindir.
• Hizmet katmanının fiyatından daha fazla ek ücret ödemeden dahil edilir.
• İş Açısından Kritik hizmet katmanına gelişmiş performans ve öngörülebilirlik getirin.

Özellikleri 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.

¹ 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

Geri yükleme gerçekleştirmek için bkz . Veritabanını yedeklerden geri yükleme. Aşağıdaki örnekleri kullanarak yedekleme yapılandırması ve geri yükleme işlemlerini inceleyebilirsiniz.

Veritabanını dışarı aktarma

Azure hizmeti tarafından alınan otomatik yedeklemeler doğrudan indirilemez veya erişim sağlanmaz. Bunlar yalnızca Azure aracılığıyla geri yükleme işlemleri için kullanılabilir.

Azure SQL Veritabanı dışarı aktarmanın alternatifleri vardır. Veritabanını arşivleme veya başka bir platforma taşıma amacıyla dışarı aktarmanız gerektiğinde, veritabanı şemasını ve verilerini bir BACPAC dosyasına aktarabilirsiniz. BACPAC dosyası, veritabanındaki meta verileri ve verileri içeren BACPAC uzantısına sahip bir ZIP dosyasıdır. BACPAC dosyası Azure Blob depolama alanında veya şirket içi bir konumdaki yerel depolamada depolanabilir ve daha sonra Azure SQL Veritabanı, Azure SQL Yönetilen Örneği veya SQL Server örneğine geri aktarılabilir.

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şturulduktan veya geri yüklendikten hemen sonraya zamanlanır. Bu yedekleme genellikle 30 dakika içinde tamamlanır, ancak veritabanı büyük olduğunda daha uzun sürebilir. Örneğin, geri yüklenen bir veritabanında veya veritabanı kopyasında ilk yedekleme daha uzun sürebilir ve bu genellikle yeni bir veritabanından daha büyük olur.

İlk tam yedeklemeden sonra, diğer tüm yedeklemeler otomatik olarak zamanlanır ve yönetilir. Tüm veritabanı yedeklemelerinin tam zamanlaması, genel sistem iş yükünü dengelediği için SQL Veritabanı hizmeti tarafından belirlenir. Yedekleme işlerinin zamanlamasını değiştiremez veya devre dışı bırakamazsı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 zamanlar. Tüm saklama süresi içinde PITR sağlamak için, sistemin yapılandırılan saklama süresinden bir haftaya kadar daha uzun süre boyunca ek tam, fark ve işlem günlüğü yedeklerini depolaması gerekir.

Başka bir deyişle, bekletme süresi boyunca herhangi bir zaman noktası için, saklama süresinin en eski zamanından daha eski bir tam yedekleme olmalıdır. Ayrıca, bir sonraki tam yedeklemeye kadar bu tam yedeklemeden değişiklik ve işlem günlüğü yedeklemelerinden oluşan kesintisiz bir zincir de 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ı.

PITR işlevselliği sağlamak için artık gerekli olmayan yedeklemeler otomatik olarak silinir. Değişiklik yedeklemeleri ve günlük yedeklemeleri geri yüklenebilir olması için daha önceki bir tam yedekleme gerektirdiği için, her üç yedekleme türü de haftalık kümelerde birlikte temizlenir.

TDE ile şifrelenmiş veritabanları da dahil olmak üzere tüm veritabanlarında, yedekleme depolama sıkıştırmasını ve maliyetlerini azaltmak için tüm tam ve değişiklik yedeklemeleri sıkıştırılır. Ortalama yedekleme sıkıştırma oranı 3 ile 4 kez arasındadı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.

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

Tüketimi izleme

Azure SQL Veritabanı sanal çekirdek veritabanları için, her yedekleme türünün (tam, fark ve günlük) tükettiği depolama alanı, veritabanı izleme bölmesinde ayrı bir ölçüm olarak raporlanır. Aşağıdaki ekran görüntüsünde, tek bir veritabanı için yedekleme depolama tüketiminin nasıl izleneceği gösterilmektedir.

Hiper Ölçek'te tüketimi izleme yönergeleri için bkz . Hiper Ölçek yedekleme tüketimini izleme.

Yedekleme depolama alanı tüketiminde hassas ayarlamalar yapma

Veritabanı için maksimum veri boyutuna kadar yedekleme depolama alanı tüketimi ücretlendirilmiyor. Fazla yedekleme depolama alanı tüketimi, iş yüküne ve tek tek veritabanlarının maksimum boyutuna bağlıdır. Yedekleme depolama alanı tüketiminizi azaltmak için aşağıdaki ayarlama 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 fazla yedekleme depolama maliyetleriniz varsa, yedekleme depolamadan tasarruf etmek için veri depolama alanını artırmayı düşünebilirsiniz.
• 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 süreli saklama, PITR'nin veritabanı için saklama süresi içinde tutulmasını sağlar. 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 kopyalanan veritabanları için, Azure SQL Veritabanı varsayılan olarak son 7 gün içinde PITR'ye izin vermek için yeterli yedeklemeleri korur. Hizmet, veritabanlarının veritabanı için tanımlanan saklama süresi içinde herhangi bir noktaya geri yüklenebilmesini sağlamak için düzenli olarak tam, değişiklik ve günlük yedeklemeleri alır.

Değişiklik yedeklemeleri, 12 saatte bir veya 24 saatte bir gerçekleşecek şekilde yapılandırılabilir. 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 yedekleme depolama yedekliliği seçeneğinizi belirtebilir ve daha sonra değiştirebilirsiniz. Veritabanınız oluşturulduktan sonra yedekleme yedekliliği seçeneğinizi değiştirirseniz, yeni yedeklemeler yeni yedeklilik seçeneğini kullanır. Önceki STR yedekliliği seçeneğiyle yapılan yedekleme kopyaları taşınmaz veya kopyalanmamıştır. Saklama süresi dolana kadar özgün depolama hesabında bırakılırlar ve bu süre 1 ile 35 gün 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, sistem yedekleri belirli bir saklama süresine sahip çevrimiçi bir veritabanı için aynı şekilde tutar. Silinen bir veritabanının yedekleme saklama süresini değiştiremezsiniz.

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 ilkesi yapılandırıldıktan sonra, tam yedeklemeler otomatik olarak haftalık olarak farklı bir depolama kapsayıcısına kopyalanır.

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

Mevcut bir veritabanı için yedekleme depolama yedekliliğini güncelleştirmek, değişikliği yalnızca gelecekte alınan yedeklemelere uygular ve mevcut yedeklemeler için geçerli olmaz. 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. Uzun süreli saklama depolama maliyetleriyle ilgili tahmin oluşturmak için uzun süreli saklama fiyatlandırma hesaplayıcıyı kullanabilirsiniz.

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ında ölçeği okuyun, veritabanını 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 geçirilen Hiper Ölçek veritabanları için uzun süreli saklama etkinleştirilebilir. 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 süreli yedekleme saklamayı etkinleştirmek için lütfen Microsoft desteğine ulaşın." Bu durumda, Microsoft desteğine ulaşın ve çözmek 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. Yedekleme depolama alanı, her ay tüketilen gigabaytlar temelinde ve tüm yedeklemeler için aynı ücrete göre ücretlendirilir.

Yedekleme depolama yedekliliği yedekleme maliyetlerini aşağıdaki şekilde etkiler:

• Locally redundant price = published price
• Zone-redundant price = published price x 1.25
• Geo-redundant price = published price x 2

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

DTU modeli

DTU modelinde veritabanları ve elastik havuzlar için 7 gün ve sonrasında varsayılan saklama için PITR yedekleme depolaması için ek ücret alınmaz. PITR yedekleme depolama alanı fiyatı, veritabanının veya havuz fiyatının bir parçasıdır.

Sanal çekirdek modeli

Azure SQL Veritabanı toplam faturalanabilir yedekleme depolama alanınızı tüm yedekleme dosyalarında birikmeli değer olarak hesaplar. Saatte bir bu değer Azure faturalama işlem hattına bildirilir. İşlem hattı, her ayın sonunda yedekleme depolama alanı tüketiminizi almak için bu saatlik kullanımı toplar.

Veritabanı silinirse, eski yedeklemeler eskidikçe ve silindikçe yedekleme depolama alanı tüketimi kademeli olarak azalır. Değişiklik yedeklemeleri ve günlük yedeklemeleri geri yüklenebilir olması için daha önceki bir tam yedekleme gerektirdiği için, her üç yedekleme türü de haftalık kümelerde birlikte temizlenir. Tüm yedeklemeler silindikten sonra faturalama durdurulur.

Hiper Ölçek veritabanları için yedekleme depolama maliyeti farklı hesaplanır. Daha fazla bilgi için bkz . Hiper Ölçek yedekleme depolama maliyetleri.

Tek veritabanları için, veritabanı için maksimum veri depolama boyutunun yüzde 100'lerine eşit bir yedekleme depolama alanı tutarı ek ücret ödemeden sağlanır. Toplam faturalanabilir yedekleme depolama alanı kullanımını hesaplamak için aşağıdaki denklem kullanılır:

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

Elastik havuzlar için, havuz depolama boyutu için maksimum veri depolama alanının yüzde 100'lerine eşit bir yedekleme depolama alanı miktarı ek ücret ödemeden sağlanır. Havuza alınan veritabanları için faturalanabilir yedekleme depolama alanının toplam boyutu havuz düzeyinde toplanır ve aşağıdaki gibi 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 faturalanabilir yedekleme depolama alanı, kullandığınız yedekleme depolama yedekliliği oranına göre aylık gigabayt olarak ücretlendirilir. 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. Bu yedeklemelerin boyutu değiştirilen veri miktarıyla orantılı olduğundan, yoğun olarak değiştirilmiş veritabanlarında daha büyük farklar ve günlük yedeklemeleri vardır. Bu nedenle, bu tür veritabanları daha yüksek yedekleme ücretlerine sahiptir.

Basitleştirilmiş bir örnek olarak, bir veritabanının 744 GB yedekleme depolama alanı biriktirdiğini ve veritabanı tamamen boşta olduğundan bu miktarın tüm ay boyunca sabit kaldığını varsayalım. 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). veritabanının saatte 1 GB PITR yedeklemesi tüketerek sabit bir hızda Azure faturalama işlem hattına rapor SQL Veritabanı. Azure faturalaması bu tüketimi toplar ve tüm ay için 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ı 1 ile 372 (ayın ilk yarısı) saatleri için 1 GB kullanım bildirilir. Kullanımı 373 ile 744 saatleri (ayın ikinci yarısı) için 2 GB olarak rapor eder. Bu kullanım, aylık 1.116 GB'lık son faturaya toplanır.

Gerçek yedekleme faturalama senaryoları daha karmaşıktır. Veritabanındaki değişikliklerin oranı iş yüküne bağlı olduğundan ve zaman içinde değişken olduğundan, her değişiklik ve günlük yedeklemesinin 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, değişiklik ve günlük yedeklemeleri 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. Daha sonra dizin yeniden derlemesinin yaptığı değişiklikler dahil edilecek:

• İşlem günlüğünde, yeniden oluşturma süresi boyunca alınan yedeklemeler.
• Sonraki değişiklik yedeklemesinde.
• Bir sonraki tam yedekleme gerçekleşene kadar alınan her değişiklik yedeğinde.

Daha büyük veritabanlarındaki son senaryo için, hizmetteki bir iyileştirme, değişiklik yedeğinin aşırı büyük olması durumunda değişiklik yedeği yerine tam yedekleme oluşturur. Bu, aşağıdaki tam yedeklemeye kadar tüm değişiklik yedeklemelerinin boyutunu küçültü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 bir veritabanı veya elastik veritabanı havuzu için tek/elastik havuz pitr yedekleme depolama alanını seçin. Ölçümler yalnızca yedekleme depolama alanı tüketimi varsa 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. Ölçümler yalnızca yedekleme depolama alanı tüketimi varsa gösterilir.

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

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

Şifrelenmiş yedeklemeler

Veritabanınız TDE ile şifrelenirse, LTR yedeklemeleri de dahil olmak üzere bekleyen yedeklemeler 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ı mühendislik ekibi otomatik veritabanı yedeklemeleri için otomatik geri yükleme testleri yürütür. Belirli bir noktaya geri yükleme sırasında veritabanları DBCC CHECKDB bütünlük denetimleri de alır.

Bütünlük denetimi sırasında bulunan sorunlar, mühendislik ekibine uyarı gönderilmesine neden olur. Daha fazla bilgi için bkz. SQL Veritabanı'da veri bütünlüğü.

Tüm veritabanı yedeklemeleri, ek yedekleme bütünlüğü sağlamak için CHECKSUM seçeneğiyle birlikte alınır.

Uyumluluk

Veritabanınızı DTU tabanlı bir hizmet katmanından sanal çekirdek tabanlı hizmet katmanına geçirdiğinizde, uygulamanızın veri kurtarma ilkesinin tehlikeye atılmadığından emin olmak için PITR saklama süresi korunur. Varsayılan saklama, uyumluluk gereksinimlerinizi karşılamıyorsa PITR saklama süresini değiştirebilirsiniz. Daha fazla bilgi için bkz . PITR yedekleme saklama süresini değiştirme.

Yedekleme depolama yedekliliğini zorlamak için Azure İlkesi kullanma

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 alanlar arası yedekli veya yerel olarak yedekli yedeklemeler uygulamak isteyebilirsiniz.

Azure İlkesi, Azure kaynaklarına kural uygulayan ilkeler oluşturmak, atamak ve yönetmek için kullanabileceğiniz bir hizmettir. Azure İlkesi, bu kaynakları kurumsal standartlarınız ve hizmet düzeyi sözleşmelerinizle uyumlu tutmanıza yardımcı olur. Daha fazla bilgi için bkz. Azure İlkesi genel bakış.

Yerleşik yedekleme depolama yedekliliği ilkeleri

Veri yerleşimi gereksinimlerini kuruluş düzeyinde zorunlu kılmak için Azure portalını veya Azure PowerShell'i kullanarak bir aboneliğe ilke atayabilirsiniz.

Örneğin, "Azure SQL DB GRS yedeklemesini kullanmaktan kaçınmalıdır" ilkesini etkinleştirirseniz, veritabanları varsayılan depolama alanıyla genel olarak yedekli depolama olarak oluşturulamaz ve kullanıcıların GRS'yi "Yedekleme depolama hesabı türünü 'Standard_RAGRS' olarak yapılandırma veritabanı oluşturma veya güncelleştirme sırasında başarısız oldu" hata iletisiyle birlikte kullanmaları engellenir.

SQL Veritabanı için yerleşik ilke tanımlarının tam listesi için ilke başvuruyu gözden geçirin.

İ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 saklamayı yönetme.
• Azure SQL Yönetilen Örneği için bkz. SQL Yönetilen Örneği için otomatik yedeklemeler.