Azure SQL Yönetilen Örneği'de otomatik yedeklemeler

Şunlar için geçerlidir:Azure SQL Yönetilen Örneği

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

Bu makalede, Azure SQL Yönetilen Örneği 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.

Otomatik veritabanı yedeklemeleri 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. Azure SQL Yönetilen Örneği tamamen yönetilen ve otomatik SQL Server veritabanı altyapısı yedeklemeleri sağlar. Bu yedeklemeler, veritabanı geri yüklemesinin yapılandırılan saklama süresi içinde belirli bir noktaya (35 güne kadar) gerçekleşmesini sağlar. Ancak, veri koruma kurallarınız yedeklemelerinizin uzun süre (10 yıla kadar) kullanılabilir olmasını gerektiriyorsa, veritabanı başına uzun süreli saklama (LTR) ilkeleri yapılandırabilirsiniz.

Yedekleme sıklığı

Azure SQL Yönetilen Örneği oluşturur:

• Her hafta tam yedekleme.
• Değişiklik yedeklemeleri 12 saatte bir gerçekleştirilir.
• İşlem günlüğü yaklaşık 10 dakikada bir yedekler .

İşlem günlüğü yedeklemelerinin sıklığı işlem boyutuna ve veritabanı etkinliği miktarına bağlıdır. İşlem günlükleri yaklaşık olarak her 10 dakikada bir alınır, ancak farklılık gösterebilir. Bir veritabanını geri yüklerken, hizmet hangi tam, fark ve işlem günlüğü yedeklemelerinin ilgili sırayla geri yüklenmesi gerektiğini belirler.

Yedekleme alanı yedekliliği

varsayılan olarak, Azure SQL Yönetilen Örneği verileri 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 olağanüstü durum durumunda örneğinizi farklı bir bölgeye geri yüklemenize de olanak tanır.

Depolama yedekliliği mekanizması, verilerinizin planlı ve plansız olaylardan korunması için birden çok kopyasını depolar. Bu olaylar geçici donanım hataları, ağ veya güç kesintileri ya da büyük doğal afetler olabilir.

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. Depolama yedekliliği hakkında daha fazla bilgi edinmek için bkz . Veri yedekliliği.

Örneğinizi oluştururken yedekleme depolama yedekliliğini yapılandırabilir ve daha sonra örnek düzeyinde güncelleştirebilirsiniz. Var olan bir örnekte yaptığınız değişiklikler yalnızca gelecekteki yedeklemeler için geçerlidir. Mevcut bir örneğin yedekleme depolama yedekliliğini güncelleştirdikten sonra değişikliklerin uygulanması 24 saat kadar sürebilir. Yedekleme depolama yedekliliği için yapılan değişiklikler yalnızca kısa süreli yedeklemeler için geçerlidir. Uzun süreli saklama ilkeleri, ilke oluşturulduğunda kısa süreli yedeklemelerin yedeklilik seçeneğini devralır. Yedeklilik seçeneği, kısa süreli yedeklemeler için yedeklilik seçeneği daha sonra değişse bile uzun süreli yedeklemeler için kalıcı olur.

Dekont

Yedek yedeklilik değişikliğinin yük devretmeyi başlatan bir yükseltme adımına neden olduğunu lütfen unutmayın.

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 çoğaltma seçeneğidir ancak yüksek kullanılabilirlik veya dayanıklılık 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 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ç:

  • Tek bir kullanılabilirlik alanı içindeki birincil bölgede üç zaman uyumlu kopya.
  • Eşleştirilmiş bölgede, birincil bölgeden ikincil bölgeye zaman uyumsuz olarak kopyalanan üç zaman uyumlu kopya.

  

• Coğrafi alanlar arası yedekli depolama (GZRS): Kullanılabilirlik alanları arasında yedeklilik tarafından sağlanan yüksek kullanılabilirliği coğrafi çoğaltma tarafından sağlanan bölgesel kesintilere karşı korumayla birleştirir. GZRS hesabındaki veriler birincil bölgedeki üç Azure kullanılabilirlik alanına kopyalanır. Veriler ayrıca bölgesel olağanüstü durumlardan korunmak için ikincil bir coğrafi bölgeye çoğaltılır. Bu bölgede, birincil bölgeden ikincil bölgeye zaman uyumsuz olarak kopyalanan tek bir kullanılabilirlik alanında üç zaman uyumlu kopyanız da vardır.

  

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, yalnızca tek bir kullanılabilirlik alanı sağlayan ve ZRS veya GZRS'yi desteklemeyen bazı bölgeler vardır.

Yedekleme kullanımı

Bu yedeklemeleri kullanarak şunları yapabilirsiniz:

• Azure portalını, Azure PowerShell'i, Azure CLI'yi veya REST API'yi kullanarak bekletme süresi içinde mevcut veritabanını geçmişteki bir noktaya geri yükleyin. Bu işlem, özgün veritabanıyla aynı örnekte veya aynı abonelikte ve bölgede farklı bir örnekte yeni bir veritabanı oluşturur. Özgün veritabanının üzerine yazılmasını önlemek için farklı bir ad kullanır. Azure portalını kullanarak belirli bir noktaya veritabanı yedeklemenizi kaynak örneğinizden farklı bir abonelikteki örneğe geri yükleyebilirsiniz.

  Geri yükleme tamamlandıktan sonra özgün veritabanını silebilirsiniz. Alternatif olarak, hem özgün veritabanını yeniden adlandırabilir hem de 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ı yedeklemenin alındığı yönetilen örneğe veya aynı örnekteki başka bir örneğe ya da kaynak örneğe farklı bir aboneliğe geri yükleyebilirsiniz. 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şememenize neden olan coğrafi olağanüstü durumdan kurtarmanıza olanak tanır. Herhangi bir Azure bölgesindeki mevcut yönetilen örneklerde 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ının yapılandırılmış bir LTR ilkesi varsa veritabanının uzun süreli 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 Uzun süreli saklamaya genel bakış sayfasını gözden geçirin.

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

Yedekleme özellikleri	PITR	Coğrafi geri yükleme	LTR
SQL yedekleme türleri	Tam, değişiklik ve işlem günlüğü yedeklemeleri.	PITR yedeklerinin çoğaltılmış kopyaları.	Yalnızca tam yedeklemeler.
Kurtarma noktası hedefi (RPO)	İşlem boyutuna ve veritabanı etkinliği miktarına göre yaklaşık 10 dakika.	Coğrafi çoğaltmaya göre 1 saate kadar. 1	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	1 ile 35 gün.	Varsayılan olarak etkindir, kaynakla aynıdır. 2	Varsayılan olarak etkin değildir. Saklama süresi 10 yıla kadardır.
Azure depolama alanı	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.
Yedeklemeleri sabit olarak yapılandırma	Desteklenmez	Desteklenmez	Desteklenmez
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	Desteklenir	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

^{1 Büyük veritabanları gerektiren ve iş sürekliliğini sağlaması gereken iş açısından kritik uygulamalar için bkz . yük devretme grupları.}

^{2 Tüm PITR yedeklemeleri varsayılan olarak coğrafi olarak yedekli depolamada depolanır; bu da coğrafi geri yüklemenin varsayılan olarak etkinleştirildiği anlamına gelir.}

^{3 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ı 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 deneyebilirsiniz.

İşlem	Azure portal	Azure CLI	Azure PowerShell
Yedek saklamayı değiştirme	/ SQL Veritabanı SQL Yönetilen Örneği	/ SQL Veritabanı SQL Yönetilen Örneği	/ SQL Veritabanı SQL Yönetilen Örneği
Uzun süreli yedekleme saklamayı değiştirme	/ SQL Veritabanı SQL Yönetilen Örneği	/ SQL Veritabanı SQL Yönetilen Örneği	/ SQL Veritabanı SQL Yönetilen Örneği
Veritabanını belirli bir noktadan geri yükleme	/ SQL Veritabanı SQL Yönetilen Örneği	/ SQL Veritabanı SQL Yönetilen Örneği	/ SQL Veritabanı SQL Yönetilen Örneği
Silinen veritabanını geri yükleme	/ SQL Veritabanı SQL Yönetilen Örneği	/ SQL Veritabanı SQL Yönetilen Örneği	/ SQL Veritabanı SQL Yönetilen Örneği
veritabanını Azure Blob Depolama'dan geri yükleme			SQL Yönetilen Örneği

Otomatik yedekleme zamanlaması

Azure SQL Yönetilen Örneği tam, değişiklik ve işlem günlüğü yedeklemeleri oluşturarak yedeklemeleri otomatik olarak yönetir. Bu işlem bir iç zamanlama tarafından yönetilir.

İlk yedekleme

• Yeni veritabanları: Bir veritabanı oluşturulduktan, geri yüklendikten veya yedekleme yedekliliği değişikliklerinden hemen sonra ilk tam yedekleme başlatılır. Bu yedekleme genellikle 30 dakika içinde tamamlanabilir, ancak daha büyük veritabanları için daha uzun sürebilir.

• Geri yüklenen veritabanları: Geri yüklenen veritabanları için ilk yedeklemenin süresi değişir ve veritabanı boyutuna bağlıdır. Geri yüklenen veritabanları veya genellikle daha büyük olan veritabanı kopyaları, ilk yedekleme için daha fazla zaman gerektirebilir.

Zamanlanmış tam yedeklemeler

• Haftalık Zamanlama: Sistem, örneğin tamamı için haftalık bir tam yedekleme penceresi ayarlar.
• Tam Yedekleme Penceresi: Bu, tam yedeklemelerin gerçekleştirildiğinde belirlenen bir dönemdir. Sistem bu pencere içinde tam yedeklemeleri tamamlamayı hedeflese de, gerekirse yedekleme tamamlanana kadar zamanlanan süreden fazla devam edebilir.
• Uyarlamalı Zamanlama: Yedekleme algoritması, cpu kullanımı ve G/Ç aktarım hızını gösterge olarak kullanarak yedekleme penceresinin iş yükü üzerindeki etkisini haftada yaklaşık bir kez değerlendirir. Önceki haftanın iş yüküne bağlı olarak, tam yedekleme penceresi ayarlanabilir.
• Kullanıcı Yapılandırması: Kullanıcıların yedekleme zamanlamasını değiştiremeyeceğini veya devre dışı bırakamayacağını unutmayın.

Ö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 (PITR) özelliği kullanılabilir hale gelir.

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 Yönetilen Örneği yedekleme zamanlamaları her hafta bir tam yedekleme içerir. 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.

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 önemli ölçüde daha düşük veya daha yüksek olabilir.

Önemli

TDE ile şifrelenmiş veritabanları için günlük yedekleme dosyaları performans nedeniyle sıkıştırılmaz. TDE ile şifrelenmemiş veritabanları için günlük yedeklemeleri sıkıştırılır.

Azure SQL Yönetilen Örneği 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

Silinen bir veritabanı için yedeklemeler belirli bir noktaya geri yükleme (PITR) için tutulur ve bu da veritabanı silinmiş olsa bile yedeklemeler tutuldukçe depolama maliyetlerini artırabilir. Maliyetleri azaltmak için yedekleme saklama süresini 0 gün olarak ayarlayabilirsiniz, ancak yalnızca silinen veritabanları için. Normal veritabanları için en düşük saklama süresi 1 gündür.

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:

• Veritabanı yedekleme saklama süresini ihtiyaçlarınız için en düşük değere 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 Yönetilen Örneği, 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 Yönetilen Örneği varsayılan olarak son 7 gün içinde PITR'ye izin vermek için yeterli yedeklemeleri korur. Bu yapılandırma 1 ile 35 gün arasında değiştirilebilir . Hizmet, veritabanlarının veritabanı veya yönetilen örnek 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.

Örneğinizi oluştururken STR için yedekleme depolama yedekliliği seçeneğinizi belirtebilir ve daha sonra değiştirebilirsiniz. Örneğiniz 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. Yedekleme depolama tüketimi bölümünde açıklandığı gibi, PITR'yi etkinleştirmek için depolanan yedeklemeler, kesin veri geri yükleme sağlamak için saklama süresinden daha eski olabilir.

Bir veritabanını silerseniz, sistem yedekleri belirli bir saklama süresine sahip çevrimiçi bir veritabanı için olduğu gibi tutar. Ancak silinen bir veritabanı için saklama süresi 1-35 günden 0-35 güne güncelleştirilir ve bu da yedeklemeleri el ile silmeyi mümkün hale getirir. 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.

Önemli

Yönetilen örneği silerseniz, yönetilen örnekteki tüm veritabanları da silinir ve kurtarılamaz. Silinen yönetilen örneği geri yükleyemezsiniz. Ancak yönetilen bir örnek için uzun süreli saklama yapılandırdıysanız LTR yedeklemeleri silinmez. Daha sonra bu yedeklemeleri kullanarak veritabanlarını aynı abonelikteki farklı bir yönetilen örneğe, bir LTR yedeklemesinin alındığı zamana geri yükleyebilirsiniz. Daha fazla bilgi edinmek için Bkz . Uzun süreli yedeklemeyi geri yükleme.

Uzun süreli saklama (LTR)

SQL Yönetilen Örneği ile, Azure Blob Depolama'da 10 yıla kadar tam LTR yedeklemelerini depolamayı yapılandırabilirsiniz. LTR ilkesi yapılandırıldıktan sonra, tam yedeklemeler otomatik 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, Y=0 aylık bir LTR kopyası oluşturur. LTR hakkında daha fazla bilgi için bkz . Uzun süreli saklama.

Azure SQL Yönetilen Örneği'daki LTR yedekleme depolama yedekliliği, LTR ilkesinin tanımlandığı sırada STR tarafından kullanılan yedekleme depolama yedekliliğinden devralınır. İLERIde STR yedekleme depolama yedekliliği değişse bile bunu değiştiremezsiniz.

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

Azure SQL Yönetilen Örneği 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.

Yedekleme depolama alanı fiyatı farklılık gösterir. Seçtiğiniz yedekleme depolama yedekliliği seçeneğine ve bölgenize 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
• Geo-zone-redundant price = published price x 3.4

Fiyatlandırma için Azure SQL Yönetilen Örneği fiyatlandırma sayfasını gözden geçirin.

Dekont

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ıyorsanız Azure faturası yalnızca 1,8 TB gösterir çünkü yalnızca kullandığınız fazla yedekleme depolama alanı için ücretlendirilirsiniz.

Yönetilen örnekler için faturalanabilir yedekleme depolama alanının toplam boyutu örnek düzeyinde toplanır ve aşağıdaki gibi hesaplanır:

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

Varsa toplam faturalanabilir yedekleme depolama alanı, kullandığınız yedekleme depolama yedekliliği oranına göre her bölge için aylık gigabayt olarak ücretlendirilir. Yedekleme depolama alanı tüketimi, tek tek veritabanlarını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ı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). SQL Yönetilen Örneği, veritabanının saatte 1 GB PITR yedeklemesi tüketerek sabit bir hızda Azure faturalama işlem hattına rapor göndermesini sağlar. 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 Yönetilen Örneği 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. Bekletme maliyetleri hemen artmıyor. Yedeklemeler 14 günlük maksimum saklama süresine ulaşana kadar büyüdüklerinden, her gün kademeli olarak artarlar.

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 oluşturma 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.

Tüm fark yedeklemelerinin boyutunu azaltmak için, 750 GB'ı aşan ve veritabanı boyutunun %75'ine eşit olan aşırı büyük değişiklik yedeklemeleri, son tam yedeklemenin 24 saatten uzun bir süre önce alınması durumunda tam yedeklemeye yükseltilir.

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, yönetilen örnek için SQL yönetilen örneği'ni seçin.

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

4. PITR yedekleme maliyetlerini izlemek için açılan listede yönetilen örnek 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 listede sql yönetilen örneği - ltr yedekleme depolaması'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 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ıyordur. Örneğin, yönetilen örneği dağıtılmayan müşteriler için yönetilen örnek sayaçları mevcut olmaz. Benzer şekilde, depolama sayaçları depolama alanı kullanmayan kaynaklar için görünür olmaz. PITR veya LTR yedekleme depolama alanı tüketimi yoksa bu ölçümler görünmez.

Ş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 Yönetilen Örneği ile saydam veri şifreleme.

Yedekleme bütünlüğü

Tüm veritabanı yedeklemeleri, ek yedekleme bütünlüğü sağlamak için CHECKSUM seçeneğiyle birlikte alınır. Azure SQL mühendislik ekibi tarafından otomatik veritabanı yedeklemelerinin otomatik olarak test edilmesi şu anda Azure SQL Yönetilen Örneği için kullanılamamaktadır. İş yükünüzün etrafındaki SQL Yönetilen Örneği veritabanlarınızda test yedekleme geri yükleme ve DBCC CHECKDB zamanlama.

Sistem yedeklemelerin bütünlüğünü doğrulamasa da, yedekleme hizmetiyle ilgili bir sorun olduğunda Microsoft'u uyaran yerleşik yedekleme korumaları vardır. Ayrıca, tam yedekleme yapılmaması, yedekleme hizmetinin takılması, günlük yedeklemesinin SLA'nın dışında olması veya yedekleme donanımının veya yazılımının bozuk olması gibi bir yedeklemeyle ilgili bir sorun oluşursa Microsoft sizi destekler.

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 yönetilen örneğiniz 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, abonelik veya kaynak grubu düzeyinde aşağıdaki yerleşik ilkeyi atarsanız, abonelikteki kullanıcılar Azure portalı veya Azure PowerShell aracılığıyla coğrafi olarak yedekli yedekleme depolaması olan bir yönetilen örnek oluşturamaz: SQL Yönetilen Örneği grs yedekleme yedekliliğini kullanmaktan kaçınmalıdır.

SQL Yönetilen Örneği 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 zorunlu kılmak için CREATE DATABASE deyimindeki BACKUP_STORAGE_REDUNDANCY parametresine giriş olarak LOCAL veya ZONE kullanın.

Uyumluluk

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.

Dekont

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

Sonraki adımlar

• İş sürekliliğine genel bakış
• Azure portalını kullanarak uzun süreli yedekleme saklamayı yönetme
• Otomatik veritabanı yedeklemelerini kullanarak kurtarma
• SQL Yönetilen Örneği yedekleme depolama alanı tüketimi açıklandı
• SQL Yönetilen Örneği'da yedekleme depolama maliyetlerini ayarlama