Azure SQL Veritabanında otomatik yedeklemeler

  • Makale

Ş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ısı 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 anında yedekleme ve hızlı geri yükleme özellikleri sağlar. Daha fazla bilgi edinmek için bkz. Hiper Ölçek yedeklemeleri.

Yedekleme sıklığı

veritabanı Azure SQL oluşturur:

İş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

Varsayılan olarak, Azure SQL Veritabanı 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ölgeye geri yüklemenize de olanak tanır.

Depolama yedekliliği mekanizması, verilerinizin planlı ve plansız olaylardan korunması için verilerinizin 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.

Yedeklemelerinizin veritabanınızın dağıtıldığı bölgede 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ürlerine 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 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.

    Yerel olarak yedekli depolama (LRS) seçeneğini gösteren diyagram.

  • 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.

    Alanlar arası yedekli depolama (ZRS) seçeneğini gösteren diyagram.

  • 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 bulunan ve birincil bölgeden ikincil bölgeye zaman uyumsuz olarak kopyalanan üç zaman uyumlu kopya.

    Coğrafi olarak yedekli depolama (GRS) seçeneğini gösteren diyagram.

Uyarı

  • Coğrafi geri yükleme , veritabanı yerel olarak yedekli veya alanlar arası yedekli depolama kullanacak şekilde güncelleştirildiğinde devre dışı bırakılır.
  • Depolama yedekliliği diyagramlarının tümü birden çok kullanılabilirlik alanına (multi-az) sahip bölgeleri gösterir. Ancak, yalnızca tek bir kullanılabilirlik alanı sağlayan ve ZRS'yi desteklemeyen bazı bölgeler vardır.
  • Hiper Ölçek veritabanları için yedekleme depolama yedekliliği yalnızca oluşturma sırasında ayarlanabilir. Kaynak sağlandıktan sonra bu ayarı değiştiremezsiniz. Mevcut hiper ölçek 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ı

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

  • Azure portal, Azure PowerShell, Azure CLI veya REST API'yi kullanarak mevcut veritabanını saklama 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 ardından geri yüklenen veritabanını özgün veritabanı adıyla yeniden adlandırabilirsiniz.

  • Silinen veritabanını saklama süresi içinde belirli bir noktaya geri yükleyin ve silme zamanı da dahil olmak üzere. Silinen veritabanı yalnızca özgün veritabanını oluşturduğunuz sunucuya geri yüklenebilir. 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ılan 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, uyumluluk isteğini karşılamak veya uygulamanın eski bir sürümünü çalıştırmak için Azure portal, Azure CLI veya Azure PowerShell 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.

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

Backup özelliği  PITR Coğrafi geri yükleme LTR
SQL yedekleme türleri Tam, diferansiyel, günlük. PITR yedeklerinin çoğaltılmış kopyaları. Yalnızca tam yedeklemeler.
Kurtarma noktası hedefi (RPO)  İşlem boyutuna ve veritabanı etkinliği miktarına göre 10 dakika.   Coğrafi çoğaltmaya göre 1 saate kadar.*  Bir hafta (veya kullanıcı ilkesi).
Kurtarma süresi hedefi (RTO) Geri yükleme genellikle 12 saatten kısa sürer, ancak boyuta ve etkinliğe bağlı olarak daha uzun sürebilir. Bkz. Kurtarma.  Geri yükleme genellikle 12 saatten kısa sürer, ancak boyuta ve etkinliğe bağlı olarak daha uzun sürebilir. Bkz. Kurtarma. Geri yükleme genellikle 12 saatten kısa sürer, ancak boyuta ve etkinliğe bağlı olarak daha uzun sürebilir. Bkz. Kurtarma.
Bekletme Varsayılan olarak 7 gün, 35 güne kadar yapılandırılabilir.  Varsayılan olarak etkindir, kaynakla aynıdır.** 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 olarak yedekli olarak ayarlandığında kullanılabilir. PITR yedekleme depolama alanı alanlar arası yedekli veya yerel olarak yedekli olduğunda kullanılamaz.  Varsayılan ayarda coğrafi olarak yedeklidir. Alanlar arası yedekli veya yerel olarak yedekli depolama yapılandırabilirsiniz.
Aynı bölgede yeni bir 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** Desteklenmiyor**
Azure portal aracılığıyla geri yükleme Yes Yes Yes
PowerShell aracılığıyla geri yükleme Yes Yes Yes
Azure CLI aracılığıyla geri yükleme Yes Yes Yes

* Büyük veritabanları gerektiren ve iş sürekliliğini sağlaması gereken iş açısından kritik uygulamalar için otomatik 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.

İşlem Azure portal 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 saklamayı 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

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.

Ö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çek veritabanı kopyalama veya geri yükleme yoluyla büyük miktarda veriyle oluşturulmuş olsa bile koruma hemen gerçekleşir. Daha fazla bilgi edinmek için Hiper Ölçek otomatik yedeklemelerini gözden geçirin.

Yedekleme depolama alanı 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 hafta daha uzun süre boyunca ek tam, fark ve işlem günlüğü yedeklerini depolaması gerekir.

Başka bir deyişle, saklama 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 yedekleri 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 alanı tüketimini ve maliyetlerini azaltmak için yedeklemeler 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 önemli ölçüde 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.

Önemli

Veritabanı silinmiş olsa bile PITR sağlamak için veritabanının yedekleri korunur. Veritabanının silinmesi ve yeniden oluşturulması depolama ve işlem maliyetlerinden tasarruf etse de yedekleme depolama maliyetlerini artırabilir. Bunun nedeni, hizmetin silinen her veritabanı için yedekleri her silindiğinde tutmasıdır.

Tüketimi izleme

Azure SQL Veritabanındaki 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.

Azure portal veritabanı yedekleme tüketimini izlemeye yönelik seçimleri gösteren ekran görüntüsü.

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

Bir veritabanı için maksimum veri boyutuna kadar yedekleme depolama alanı tüketimi ücretlendirilmez. Fazla yedekleme depolama alanı tüketimi, iş yüküne ve tek tek veritabanlarının en büyük 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:

  • Yedek saklama süresini ihtiyaçlarınız için minimuma düşürün.
  • Dizin yeniden derlemeleri gibi büyük yazma işlemlerini ihtiyacınızdan daha sık gerçekleştirmekten kaçının.
  • Büyük veri yükleme işlemleri için kümelenmiş columnstore dizinlerini kullanmayı ve ilgili en iyi yöntemleri izlemeyi 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 vadeli hem de uzun süreli saklama 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ı, PITR'ye varsayılan olarak son 7 gün içinde izin vermek için yeterli yedekleri tutar. 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.

Hiper Ölçek veritabanları için 1 ile 35 günlük kısa süreli yedekleme saklama artık önizleme aşamasındadır. Daha fazla bilgi edinmek için Hiper Ölçek'te yedekleme saklamayı yönetme bölümünü gözden geçirin.

Değişiklik yedekleri, 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 birdir. 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 yedeklilik seçeneğiyle yapılan yedekleme kopyaları taşınmaz veya kopyalanmaz. Saklama süresi dolana kadar özgün depolama hesabında kalırlar ve bu süre 1 ile 35 gün olabilir.

Temel veritabanları dışında, her etkin veritabanının 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 olduğu gibi tutar. Silinen bir veritabanının yedekleme saklama süresini değiştiremezsiniz.

Önemli

Bir sunucuyu silerseniz, o sunucudaki tüm veritabanları da silinir ve kurtarılamaz. Silinen bir sunucuyu geri yükleyemezsiniz. Ancak bir veritabanı için uzun süreli saklama yapılandırdıysanız, LTR yedeklemeleri silinmez. Daha sonra bu yedeklemeleri kullanarak aynı abonelikteki farklı bir sunucudaki veritabanlarını LTR yedeklemesinin alındığı zamana geri yükleyebilirsiniz. Daha fazla bilgi edinmek için Uzun süreli yedeklemeyi geri yükleme bölümünü gözden geçirin.

Uzun vadeli bekletme

SQL Veritabanı için, Azure Blob Depolama 10 yıla kadar tam 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 sonraki yedeklemelere uygular ve mevcut yedeklemeler için geçerli değildir. Veritabanı için tüm mevcut LTR yedeklemeleri mevcut depolama blobunda yer alır. 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.

Yedekleme depolama maliyetleri

Yedek depolamanın 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ı hızda ü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.

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 alanı sağladıysanız 4 TB boş yedekleme depolama alanı elde edersiniz. Toplam 5,8 TB yedekleme depolama alanı kullanırsanız Azure faturası yalnızca 1,8 TB gösterir çünkü yalnızca kullandığınız fazla yedekleme depolama alanı için ücretlendirilirsiniz.

DTU modeli

DTU modelinde veritabanları ve elastik havuzlar için varsayılan saklama süresi 7 gün ve daha fazla olan 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.

Önemli

DTU modelinde veritabanları ve elastik havuzlar, LTR yedeklemeleri tarafından tüketilen gerçek depolama alanına göre LTR yedekleme depolaması için ücretlendirilir.

Sanal çekirdek modeli

Azure SQL Veritabanı, toplam faturalandırılabilir yedekleme depolama alanınızı tüm yedekleme dosyaları arası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 yedekleri 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 yedek depolama 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 cinsinden ü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 sahip olur.

Basitleştirilmiş bir örnek olarak, bir veritabanında 744 GB yedekleme depolama alanı biriktirildiğ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 bunu 744,0'a (ayda 31 gün, günde 24 saat) bölün. SQL Veritabanı, veritabanının sabit bir hızda saatte 1 GB PITR yedeklemesi tükettığını Azure faturalama işlem hattına bildirir. Azure faturalaması bu tüketimi toplar ve tüm ay için 744 GB'lık bir kullanım gösterir. Maliyet, bölgenizdeki aylık gigabayt oranına göre ayarlanı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 1.488 GB'a iki katına çıkar. SQL Veritabanı 1 ile 372 (ayın ilk yarısı) saatleri için 1 GB kullanım bildirilir. 373 ile 744 (ayın ikinci yarısı) saatleri için kullanımı 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 hızı 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 depolama alanının saatlik tüketimi buna göre dalgalanır.

Her değişiklik yedeği, veritabanında son tam yedeklemeden sonra yapılan tüm değişiklikleri de içerir. Bu nedenle, tüm değişiklik yedeklerinin 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 ağır bir yazma etkinliğinin tam yedekleme tamamlandıktan hemen sonra çalıştığını varsayalım. Dizin yeniden derlemesinin yaptığı değişiklikler daha sonra 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 azaltır.

Tüketimi izleme 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 alanı tüketimini izleyebilirsiniz.

Maliyetleri izleme

Yedekleme depolama maliyetlerini anlamak için Azure portal 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 ardından 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.

Yedekleme depolama maliyetlerinin analizini gösteren ekran görüntüsü.

Ö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ıyordur. Örneğin, depolama sayaçları depolama alanı kullanmayan kaynaklar için görünmez. PITR veya LTR yedekleme depolama alanı tüketimi yoksa bu ölçümler görünmez.

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

Ş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 işleminde veritabanları DBCC CHECKDB bütünlük denetimleri de alır.

Bütünlük denetimi sırasında bulunan sorunlar, mühendislik ekibine bir uyarı gönderilmesine neden olur. Daha fazla bilgi için bkz. SQL Veritabanı 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.

Not

Otomatik yedekleme ayarlarını değiştirme makalesi, kişisel verilerin cihazdan veya hizmetten nasıl silineceği hakkında adımlar sağlar ve GDPR kapsamındaki yükümlülüklerinizi desteklemek için kullanılabilir. GDPR hakkında genel bilgi için Microsoft Güven Merkezi'nin GDPR bölümüne ve Hizmet Güveni portalının GDPR bölümüne bakın.

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 veyaAzure PowerShell kullanarak bir aboneliğe ilke atayabilirsiniz. Örneğin, aşağıdaki yerleşik ilkeyi atarsanız, abonelikteki kullanıcılar Azure portal veya Azure PowerShell aracılığıyla coğrafi olarak yedekli depolama alanına sahip bir veritabanı oluşturamaz: SQL Veritabanı GRS yedekleme yedekliliğini kullanmaktan kaçınmalıdır.

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

Önemli

T-SQL aracılığıyla veritabanı oluştururken Azure ilkeleri zorunlu tutulmaz. T-SQL kullanarak veritabanı oluştururken veri yerleşimini belirtmek için CREATE DATABASE deyimindeki BACKUP_STORAGE_REDUNDANCY parametresine giriş olarak LOCAL veya ZONE kullanın.

Sonraki adımlar