Azure SQL Yönetilen Örneğinde otomatik yedeklemeler

Şunlar için geçerlidir: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. Azure SQL Yönetilen Örneği için otomatik yedekleme ayarlarını değiştirme. Yedeklemeyi geri yüklemek için bkz. Azure SQL Yönetilen Örneği'nde bir yedeklemeden veritabanını geri yükleme.

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 ile SQL Server veritabanı altyapısı yedeklemeleri Microsoft tarafından otomatik olarak yönetilir ve Microsoft tarafından yönetilen Azure depolama hesaplarında depolanır.

Veritabanınızı yapılandırılan saklama süresi içinde belirli bir noktaya (35 güne kadar) geri yüklemek için bu yedeklemeleri kullanın. Ancak, veri koruma kurallarınız yedeklemelerinizin uzun süre (10 yıla kadar) kullanılabilir olmasını gerektiriyorsa, her veritabanı için uzun süreli saklama (LTR) ilkeleri yapılandırabilirsiniz.

Yedekleme sıklığı

Azure SQL Yönetilen Örnek oluşturur.

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

Dikkat

Otomatik tam yedeklemeler, Microsoft tarafından belirlenen bir zamanlamaya göre haftada bir başlatılır. Kullanıcı tarafından başlatılan yedeklemeler otomatik tam yedeklemelere göre önceliklidir, bu nedenle uzun süre çalışan bir yalnızca kopya yedeklemesi sonraki otomatik tam yedeklemenin zamanlamasını etkileyebilir.

Bir veritabanı veya SQL yönetilen örneği silinmeden önce her seferinde kuyruk günlüğü yedeklemesi alınır.

Sistem veritabanları otomatik olarak yedeklenir (fiziksel master veritabanı hariç), ancak bu yedeklemeler şu anda msdb içinde kaydedilmemektedir.

Yedekleme alanı yedekliliği

Varsayılan olarak, Azure SQL Yönetilen Örneği yedekleri, eşleştirilmiş bir bölgeye çoğaltılan coğrafi yedekli depolama bloblarında saklar. 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 vadeli koruma politikaları, politika 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 geçerliliğini korur.

Not

Yedekleme yedekliliğini değiştirmek, yük devretmeyi başlatan bir güncelleştirme yönetimi işlemidir .

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.

    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 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ç:

    • Tek bir kullanılabilirlik alanı içindeki birincil bölgede üç zaman uyumlu kopya.
    • Eşleştirilmiş bölgedeki tek bir kullanılabilirlik alanında bulunan üç zaman uyumlu kopya, birincil bölgeden ikincil bölgeye zaman uyumsuz olarak kopyalanmıştır.

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

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

    Coğrafi alanlar arası yedekli depolama (GZRS) 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ğ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:

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

Otomatik yedeklemeler artık İş Açısından Kritik hizmet katmanındaki ikincil bir çoğaltmadan alınıyor. Veriler her düğümdeki SQL Veritabanı Altyapısı 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. İ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.

Not

Örneğiniz için bu özelliği devre dışı bırakmak için bir Azure destek isteği 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.

Yedekleme özellikleri PITR Coğrafi konumdan veri geri yükleme LTR
SQL yedekleme türleri Tam, farklı 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 sürebilir. 1 Bir hafta (veya kullanıcı politikası).
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 yedekli veya coğrafi bölge yedekli (GZRS) 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
güncelleştirme ilkesi3 Uyum sağlamalı veya yükseltilmelidir Uyum sağlamalı veya yükseltilmelidir Uyum sağlamalı veya yükseltilmelidir
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 4 Desteklenmiyor 4
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 Veritabanı yedeklemeleri yalnızca eşleşen güncelleştirme ilkelerine sahip örneklere veya SQL Server'ın daha yüksek bir sürümünün güncelleştirme ilkesine geri yüklenebilir. Örneğin, SQL Server 2022 güncelleştirme ilkesine sahip bir örnekten alınan veritabanı yedeklemesi, SQL Server 2022, SQL Server 2025 veya Always-up-to-date güncelleştirme ilkesine sahip bir örneğe geri yüklenebilir.
4 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. Azure SQL Yönetilen Örneği'nde bir veritabanını yedekten geri yükleme. Aşağıdaki örnekleri kullanarak yedekleme yapılandırması ve geri yükleme işlemlerini deneyebilirsiniz.

İş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 vadeli yedekleme saklamasını 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
veritabanını Azure Blob Depolama'dan geri yükleme SQL Yönetilen Örnek

Otomatik yedekleme zamanlaması

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

Veritabanı oluşturulduktan, geri yüklendikten veya yedek yedeklilik değişikliklerine geçtikten hemen sonra ilk tam yedekleme başlatılır. Bu yedekleme genellikle 30 dakika içinde tamamlanabilir ancak daha uzun sürebilir. Geri yüklenen veritabanları için ilk yedeklemenin süresi değişir ve veritabanı boyutuna bağlıdır. Daha büyük geri yüklenen veritabanları veya veritabanı kopyaları, ilk yedekleme için daha fazla zaman gerektirebilir.

Önemli

Yeni bir veritabanı için ilk tam yedekleme diğer veritabanı yedeklemelerinden önceliklidir, bu nedenle ilk tam yedekleme penceresi sırasında alınan ilk yedeklemedir. Tam yedekleme penceresi zaten etkinse ve diğer veritabanları yedekleniyorsa, yeni veritabanı için ilk tam yedekleme, başka bir veritabanının tam yedeklemesi tamamlandıktan hemen sonra alınır.

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 yedekleme zamanlamasını değiştiremez veya devre dışı bırakamaz .

Önemli

Başlangıçtaki tam yedeklemeden sonra ilk işlem günlüğü yedeklemesi tamamlandığında, yeni, geri yüklenen veya kopyalanan bir veritabanı için 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, saklama süresinin herhangi bir anında, saklama süresinin başlangıcından daha eski bir tam yedekleme olmalıdır. Ayrıca, bir sonraki tam yedeklemeye kadar bu tam yedeklemeden diferansiyel 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ılamaz. 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ı toplamaktan 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 imkanı sunar. Kısa süreli saklama, veritabanı için belirtilen saklama süresi içinde PITR'ye imkan 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 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 kopyalanmaz. 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

İstenmeyen şekilde silinen bir SQL yönetilen örneğinden veritabanlarını geri yüklemeniz gerekiyorsa, silme işlemini izleyen 5 gün içinde Microsoft destek ekibine başvurun.

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

Azure SQL Yönetilen Örneği'ndeki LTR yedek depolama yedekliliği, LTR ilkesinin tanımlandığı sırada STR tarafından kullanılan yedek 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 alanı yedekliliği, yedekleme maliyetlerini aşağıdaki şekilde etkiler:

  • Locally-redundant price (LRS) = Zone-redundant price (ZRS) = published price
  • Geo-redundant price (GRS) = Geo-zone-redundant price (GZRS) = published price x 2

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

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ı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 her saat sabit bir hızda 1 GB PITR yedeği tükettiğini Azure faturalama işlem hattına rapor eder. 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 Örnek, ilk 372 saat (ayın ilk yarısı) boyunca 1 GB kullanım bildirebilir. 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. Saklama 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, fark ve günlük yedekleme kümesi eskidikçe 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:

  • Yeniden oluşturma süresi boyunca alınan işlem günlüğü yedeklemeleri.
  • Sonraki farklı yedeklemede.
  • Bir sonraki tam yedekleme gerçekleşene kadar alınan her diferansiyel yedeklemede.

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çılır listeden bir yönetilen örnek için SQL yönetilen örnek'i 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çılır listeden 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 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ıyor olabilir. Örneğin, yönetilen bir örnek dağıtılmamış olan müşteriler için yönetilen örnek sayaçları mevcut olmaz. Benzer şekilde, depolama sayaçları da depolama alanı tüketilmeyen 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 şifrelendiyse, LTR yedekleri de dahil olmak üzere beklemede olan tüm 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.

Microsoft, hizmet tarafından yönetilen anahtarlara (SMK) sahip veritabanları için anahtarları tutmak ve döndürmekle tamamen sorumludur. SMK özellikli TDE'nin etkinleştirildiği örneklerden alınan PITR veya LTR yedeklemeleri Microsoft tarafından geri yüklenebilir.

Azure tarafından yönetilen depolama hesaplarında depolanan otomatik yedeklemeler, Azure depolama tarafından otomatik olarak şifrelenir. Hareketsiz veriler için Azure Depolama şifrelemesi hakkında daha fazla bilgi edinin.

Müşteri eylemleri nedeniyle otomatik yedeklemelerle ilgili yaygın sorunlar

Azure SQL Yönetilen Örneği, veri koruma ve kurtarma sağlamak için otomatik yedeklemeler sağlarken, bazı müşteri tarafı yapılandırmaları veya eylemleri yedekleme hatalarına yol açabilir. Yaygın senaryolar şunlardır:

  • SQL yönetilen örneği için yetersiz depolama alanı. Örneğinize ayrılan depolama alanı doluysa otomatik yedeklemeler alınmaz.
  • Sistem işlemlerini durduran kullanıcı tanımlı işler veya betikler otomatik yedekleme işlemlerini durdurabilir.
  • Yanlış DNS ayarları, SQL yönetilen örneğinin yedeklemeler için kullanılanlar da dahil olmak üzere gerekli Azure uç noktalarına erişmesini engelleyebilir ve bu da yedekleme hatalarına yol açabilir.
  • Kesme işlemi, yanlış yapılandırılmış çoğaltma, CDC veya tam depolama (örnek seviyesinde) nedeniyle işlem günlüğü dolabilir. İşlem günlüğü doluysa ve kesilemiyorsa, tam ve değişiklik yedeklemeleri başarısız olur, ancak günlük dosyası kesilmeden yapılan günlük yedeklemeleri yine de başarılı olur.

Güvenilir yedeklemeler sağlamak için sistem kaynaklarını izlemek, yapılandırma ayarlarını doğrulamak ve yerleşik hizmet işlemlerine müdahale etmekten kaçınmak önemlidir. Ayrılmış depolamayı izlediğinize, doğru DNS ayarlarına sahip olduğundan emin olun ve özel işleri ve çoğaltma yapılandırmalarını gözden geçirin.

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 veritabanı yedeklemelerinin otomatik test edilmesi şu anda Azure SQL Yönetilen Örneği için kullanılamamaktadır. İş yükünüz etrafında SQL Yönetilen Örneği veritabanlarınızda yedek geri yükleme testini ve DBCC CHECKDB'yi planlayın.

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 uygulamak için Azure Policy 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şvurusunu inceleyin.

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

Yedekleme koruması

Azure SQL Yönetilen Örneği yedeklemeleri, güvenli, iç Azure Depolama hesapları kullanılarak tamamen Microsoft'a ait Azure abonelikleri içinde yönetilir. Bu yedeklemelere dışarıdan erişilemez ve güçlü veri yalıtımı ve koruma sağlanır. Microsoft'ta yalnızca Backup-Restore hizmeti gibi arka uç hizmetleri bu yedeklemeleri oluşturma, kopyalama veya geri yükleme erişimine sahiptir. 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.

Saklama süresi dolduktan sonra yedeklemeler otomatik olarak silinir.

Yedek saklama yoluyla 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.

Not

Azure SQL Yönetilen Örneği için otomatik yedekleme ayarlarını değiştirme makalesi, cihaz veya hizmetten kişisel verilerin 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.

İlgili içerik

  • Last updated on