otomatik yedeklemeler-Azure SQL Veritabanı & Azure SQL yönetilen örneği

Uygulama hedefi: Azure SQL Veritabanı Azure SQL yönetilen örneği

Veritabanı yedeklemesi nedir?

Veritabanı yedeklemeleri her iş sürekliliği ve olağanüstü durum kurtarma stratejisinin temel parçalarıdır çünkü bunlar verilerinizi bozulmalara veya silmelere karşı korur. Bu yedeklemeler, yapılandırılan saklama süresi içinde bir zaman noktasına veritabanı geri yüklemeyi etkinleştirir. Veri koruma kurallarınız yedeklemelerinizin uzun bir süre (10 yıla kadar) kullanılabilir olmasını gerektiriyorsa, hem tek tek hem de havuza alınan veritabanları için uzun süreli saklamayı yapılandırabilirsiniz.

Yedekleme sıklığı

hem SQL Veritabanı hem de SQL yönetilen örnek SQL Server teknolojisini kullanarak her hafta her hafta tam yedeklemeler , fark yedeklemeleri her 12-24 saatte bir ve işlem günlüğü yedeklemelerini her 5 ila 10 dakika oluşturur. İşlem günlüğü yedeklerinin sıklığı işlem boyutuna ve veritabanı etkinliği miktarına göre değişir.

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.

Yedekleme depolama yedekliliği

varsayılan olarak, bir eşleştirilmiş bölgeyeçoğaltılan coğrafi olarak yedekli depolama blobları içinde SQL Veritabanı ve SQL yönetilen örnek deposu verileri. Coğrafi artıklık, birincil bölgedeki yedekleme depolama alanını etkileyen kesintilere karşı korunmaya yardımcı olur ve bir olağanüstü durum durumunda sunucunuzu farklı bir bölgeye geri yüklemenize olanak tanır.

Yedekleme depolama yedekliliği yapılandırma seçeneği, yerel olarak yedekli, bölgesel olarak yedekli veya coğrafi olarak yedekli depolama Blobları arasından seçim esnekliği sağlar. verilerinizin yönetilen örneğinizin veya SQL veritabanınızın dağıtıldığı bölge içinde kalmasını sağlamak için, varsayılan coğrafi olarak yedekli yedekleme depolama yedekliği ' nı değiştirebilir ve yedeklemeler için yerel olarak yedekli ya da bölgesel olarak yedekli depolama bloblarını yapılandırabilirsiniz. Depolama artıklık mekanizmaları, geçici donanım arızası, ağ veya güç kesintileri ya da büyük doğal felaketler dahil, planlı ve plansız olaylardan korunmak üzere verilerinizin birden çok kopyasını depolar. Yapılandırılan yedekleme depolama yedekliliği, uzun vadeli yedeklemeler (LTR) için kullanılan zaman içinde nokta geri yükleme (ıNR) ve uzun süreli bekletme yedeklemeleri için kullanılan kısa süreli yedekleme bekletme ayarlarına uygulanır.

SQL Veritabanı için yedek depolama yedekliliği, veritabanı oluşturma sırasında yapılandırılabilir veya var olan bir veritabanı için güncelleştirilemeyebilir; var olan bir veritabanında yapılan değişiklikler yalnızca gelecekteki yedeklemeler için geçerlidir. Mevcut bir veritabanının yedek depolama yedekliliği güncelleştirildikten sonra, değişikliklerin uygulanması 48 saate kadar sürebilir. Coğrafi geri yükleme, bir veritabanı yerel veya bölgesel olarak yedekli depolamayı kullanacak şekilde güncelleştirildiğinden devre dışı bırakılır.

Yedekleme kullanımı

Bu yedeklemeleri kullanarak şunları yapabilirsiniz:

• Mevcut veritabanının - zaman içindeki bir noktaya geri yüklemesi mevcut bir veritabanını, Azure portal, Azure PowerShell, Azure clı veya REST API kullanarak saklama süresi içinde geçmiş bir noktaya geri yükleyin . SQL Veritabanı için 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 özgün veritabanını silebilirsiniz. Alternatif olarak, özgün veritabanını yeniden adlandırabilir ve sonra geri yüklenen veritabanını özgün veritabanı adıyla yeniden adlandırabilirsiniz. benzer şekilde, SQL yönetilen örnek için bu işlem, aynı abonelikte ve aynı bölgede bulunan aynı veya farklı yönetilen örnekteki veritabanının bir kopyasını oluşturur.
• Silinen veritabanının - zaman içindeki bir noktaya geri yüklemesi Silinen bir veritabanını silme zamanına veya Bekletme dönemi içinde herhangi bir zaman noktasına geri yükleyin. Silinen veritabanı yalnızca özgün veritabanının oluşturulduğu sunucuya veya yönetilen örneğe geri yüklenebilir. Bir veritabanı silinirken, veri kaybını engellemek için, silme işleminden önce hizmet son işlem günlüğü yedeklemesini alır.
• Coğrafi geri yükleme - Veritabanını başka bir coğrafi bölgeye geri yükleyin. Coğrafi geri yükleme, birincil bölgedeki veritabanınıza veya yedeklemelerinize erişene zaman coğrafi bir olağanüstü durumdan kurtulmanızı sağlar. Herhangi bir Azure bölgesindeki var olan herhangi bir sunucuda veya yönetilen örnekte yeni bir veritabanı oluşturur.

  Önemli

  coğrafi geri yükleme yalnızca SQL veritabanları veya coğrafi olarak yedekli yedekleme depolama ile yapılandırılmış yönetilen örnekler için kullanılabilir.

• Uzun vadeli yedeklemeden - geri yükleme Veritabanı uzun süreli bir bekletme ilkesiyle yapılandırılmışsa (LTR), tek bir veritabanı veya havuza alınmış bir veritabanının belirli bir uzun süreli yedeklemesinden veritabanını 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, Azure clı 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.

Azure SQL Veritabanı ve Azure SQL yönetilen örnek 'in yeteneklerini ve özelliklerini geri yükleme

Bu tabloda, zaman içinde nokta geri yükleme (sür), coğrafi geri yüklemeve uzun süreli bekletme yedeklemelerininözellikleri ve özellikleri özetlenmektedir.

* Büyük veritabanları gerektiren iş açısından kritik uygulamalar ve iş sürekliliği sağlamak için otomatik yük devretme gruplarıkullanın.

** Tüm bağımlı yedeklemeler, varsayılan olarak coğrafi olarak yedekli depolama alanında depolanır. Bu nedenle, coğrafi geri yükleme varsayılan olarak etkindir.

*** Geçici çözüm, yeni bir sunucuya geri yükleme ve kaynak taşımayı kullanarak sunucuyu başka bir aboneliğe taşımaya yönelik bir çözümdür.

Bir veritabanını yedeklerden geri yükleme

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

Yedekleme zamanlaması

İlk tam yedekleme yeni bir veritabanı oluşturulduktan veya geri yüklendikten hemen sonra zamanlanır. Bu yedekleme genellikle 30 dakika içinde tamamlanır, ancak veritabanı büyükse daha uzun sürebilir. Örneğin, ilk yedekleme geri yüklenen bir veritabanında veya bir veritabanı kopyasında daha uzun sürebilir, bu da 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ı yedeklerinin tam zamanlaması, genel sistem iş yükünü dengeleyerek SQL Veritabanı veya SQL yönetilen örnek hizmeti tarafından belirlenir. Yedekleme işlerinin zamanlamasını değiştiremez veya devre dışı bırakabilirsiniz.

Yedekleme depolama alanı tüketimi

SQL Server yedekleme ve geri yükleme teknolojisine sahip bir veritabanını bir zaman noktasına geri yüklemek, bir tam yedeklemeden, isteğe bağlı olarak bir değişiklik yedeklemesinden ve bir veya daha fazla işlem günlüğü yedeğinden oluşan kesintisiz bir yedekleme zinciri gerektirir. SQL Veritabanı ve SQL yönetilen örnek yedekleme zamanlaması, her hafta bir tam yedekleme içerir. Bu nedenle, tüm Bekletme dönemi içinde ara r sağlamak için sistem, yapılandırılan saklama süresinden daha uzun bir haftaya kadar ek tam, fark ve işlem günlüğü yedeklemeleri depolaması gerekir.

Diğer bir deyişle, bekletme süresi boyunca herhangi bir zaman için, bekletme döneminin en eski zamanından daha eski olan bir tam yedekleme ve bir sonraki tam yedeklemeye kadar bu tam yedeklemeden kesintisiz bir fark ve işlem günlüğü yedeklemeleri zinciri olmalıdır.

Artık gerekli olmayan yedeklemeler otomatik olarak silinir. Fark yedeklemeleri ve günlük yedeklemeleri, daha önce bir tam yedeklemenin geri yüklenebilir olmasını gerektirdiğinden, üç yedekleme türünün tümü haftalık kümeler halinde temizlenir.

Şifrelenen veritabanları da dahil olmak üzere tüm veritabanları için yedeklemeler, yedekleme depolama sıkıştırması ve maliyetlerini azaltmak için sıkıştırılır. Ortalama yedekleme sıkıştırma oranı 3-4 zamandır, ancak verilerin doğasına ve veri sıkıştırmasının veritabanında kullanılıp kullanılmasından bağımsız olarak önemli ölçüde daha yüksek olabilir.

SQL Veritabanı ve SQL yönetilen örnek, toplam kullanılan yedekleme depolama alanınızı birikimli bir değer olarak hesaplamalısınız. Her saat, bu değer Azure Faturalandırma işlem hattında raporlanır ve bu saatlik kullanımı, her ayın sonunda tüketiminizi hesaplamak için sağlamaktan sorumludur. Veritabanı silindikten sonra, yedeklemeler yaşaşımına uğrar ve silindikçe, tüketim azalır. Tüm yedeklemeler silindikten sonra ve artık mümkün değilse faturalandırma duraklar.

Tüketimi izleme

VCore veritabanları için her bir yedekleme türü (tam, değişiklik ve günlük) tarafından tüketilen depolama alanı, veritabanı izleme bölmesinde ayrı bir ölçüm olarak raporlanır. Aşağıdaki diyagramda tek bir veritabanı için yedekleme depolama tüketiminin nasıl izleneceği gösterilmektedir. Bu özellik şu anda yönetilen örnekler için kullanılamaz.

Yedekleme depolama tüketimine ince ayar yapma

Bir veritabanı için maksimum veri boyutuna kadar yedekleme depolama tüketimi ücretlendirilmez. Fazla yedekleme depolama alanı tüketimi, bireysel veritabanlarının iş yüküne ve en büyük boyutuna bağlıdır. Yedekleme depolama tüketiminizi azaltmak için aşağıdaki ayarlama tekniklerinden bazılarını göz önünde bulundurun:

• Yedekleme saklama süresini gereksinimleriniz için mümkün olan en düşük süreye düşürün.
• Dizin yeniden oluşturmanız gibi büyük yazma işlemlerini yapmaktan kaçının, ancak gerekenden daha sık.
• Büyük veri yükleme işlemleri için, kümelenmiş columnstore dizinlerini ve ilgili en iyi uygulamalarıkullanmayı ve/veya kümelenmemiş dizinlerin sayısını azaltmayı düşünün.
• Genel Amaçlı hizmet katmanında, sağlanan veri depolama alanı, yedekleme depolama fiyatından daha ucuz. Sürekli yedekleme depolama maliyetleriniz varsa, yedekleme depolama alanı üzerinde kaydedilecek veri depolama alanını artırmayı düşünebilirsiniz.
• Geçici sonuçları ve/veya geçici verileri depolamak için uygulama mantığınızdaki kalıcı tablolar yerine TempDB kullanın.
• Mümkün olduğunda yerel olarak yedekli yedekleme depolaması kullanın (örneğin geliştirme ve test ortamları)

Yedekleme dosyası saklama

Azure SQL Veritabanı ve Azure SQL yönetilen örneği, yedeklemelerin hem kısa vadeli hem de uzun süreli bekletmesini sağlar. Kısa süreli bekletme yedeklemeleri, veritabanı için bekletme süresiyle birlikte geri yükleme (ıNR), uzun süreli saklama ise çeşitli uyumluluk gereksinimlerine yönelik yedeklemeler sağlar.

Kısa süreli saklama

tüm yeni, geri yüklenen ve kopyalanmış veritabanları için, Azure SQL Veritabanı ve Azure SQL yönetilen örneği, son yedi gün içinde varsayılan olarak veri için yeterli yedeklemeler sağlar. Veritabanı veya yönetilen örnek için tanımlanan Bekletme dönemi içinde belirli bir noktaya geri yüklenebilir olmasını sağlamak için düzenli olarak tam, değişiklik ve günlük yedeklemeleri alınır. ayrıca, Azure SQL veritabanları için, fark yedeklemeleri 12 saat veya 24 saatlik sıklık olarak yapılandırılabilir.

Hiper ölçek ve temel katman veritabanları hariç olmak üzere, 1-35 gün aralığında her etkin veritabanı için yedekleme saklama süresini değiştirebilirsiniz . Yedekleme depolama tüketimibölümünde açıklandığı gibi, ınvr 'yi etkinleştirmek için depolanan yedeklemeler saklama süresinden daha eski olabilir. yalnızca Azure SQL yönetilen örneği için, 0-35 gün aralığında bir veritabanı silindikten sonra, yedek saklama oranını ayarlamak mümkündür.

Bir veritabanını silerseniz, sistem yedeklemeleri, belirli bir saklama süresi ile çevrimiçi bir veritabanı için olduğu gibi korur. Silinen bir veritabanı için yedekleme saklama süresini değiştiremezsiniz.

Son 1-35 gün içinde yedek bekletme amaçları için bazen kısa süreli yedekleme saklama adı verilir. Yedeklemeleri 35 günlük maksimum kısa süreli saklama süresinden daha uzun tutmanız gerekiyorsa, uzun süreli saklamasağlayabilirsiniz.

Uzun vadeli bekletme

hem SQL Veritabanı hem de SQL yönetilen örnek için Azure Blob depolamada en fazla 10 yıla kadar tam yedekleme uzun süreli saklama (LTR) yapılandırabilirsiniz. LTR ilkesi yapılandırıldıktan sonra, tam yedeklemeler 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. Depolama tüketim, LTR yedeklemelerdeki seçili sıklık ve bekletme dönemlerine bağlıdır. LTR depolama maliyetini tahmin etmek için LTR Fiyatlandırma Hesaplayıcı ' yı kullanabilirsiniz.

LTR hakkında daha fazla bilgi için bkz. uzun süreli yedek saklama.

Yedekleme depolama maliyetleri

Yedekleme depolaması için fiyat değişir ve satın alma modelinize (DTU veya vCore), seçili yedekleme depolama artıklığı seçeneğine ve ayrıca bölgenizde bağlıdır. yedekleme depolaması tüketilen GB/ay başına ücretlendirilir, fiyatlandırma için Azure SQL Veritabanı fiyatlandırma sayfasına ve Azure SQL yönetilen örnek fiyatlandırma sayfasına bakın.

Satın alma modelleri hakkında daha fazla bilgi için bkz. vCore ve DTU satın alma modelleri arasında seçim yapın.

DTU modeli

DTU modelinde, veritabanları ve elastik havuzlar için yedekleme depolaması için ek ücret alınmaz. Yedekleme depolama alanı fiyatı, veritabanının veya havuz fiyatının bir parçasıdır.

Sanal çekirdek modeli

SQL Veritabanı tek veritabanları için, veritabanı için maksimum veri depolama boyutunun yüzde 100 ' una eşit bir yedekleme depolama alanı, ek ücret ödemeden sunulmaktadır. Esnek havuzlar ve yönetilen örnekler için, havuz için maksimum veri depolama alanının yüzde 100 ' una eşit bir yedekleme depolama miktarı veya sırasıyla en büyük örnek depolama boyutu, ek ücret ödemeden sunulmaktadır.

Tek veritabanları için bu denklem, faturalandırılabilir toplam yedekleme depolama kullanımını hesaplamak için kullanılır:

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

Havuza alınmış veritabanları için, faturalandırılabilir toplam yedekleme depolama boyutu havuz düzeyinde toplanır ve şu şekilde hesaplanır:

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

Yönetilen örnekler için, faturalandırılabilir toplam yedekleme depolama boyutu örnek düzeyinde toplanır ve aşağıdaki şekilde 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

Toplam faturalanabilir yedekleme depolaması, varsa, kullanılan yedekleme depolama yedekliliğe göre GB/ay olarak ücretlendirilir. Bu yedekleme depolama alanı tüketimi, bireysel veritabanlarının, elastik havuzların ve yönetilen örneklerin iş yüküne ve boyutuna bağlı olarak değişir. Bu yedeklemelerin boyutu değiştirilen verilerin miktarıyla orantılı olduğundan, yoğun olarak değiştirilmiş veritabanlarının 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.

SQL Veritabanı ve SQL yönetilen örnek, toplam faturalandırılabilir yedekleme depolama alanınızı tüm yedekleme dosyalarında birikimli bir değer olarak hesaplar. Bu değer, her saat sonunda yedekleme depolama tüketiminizi almak için bu saatlik kullanımı toplayan Azure Faturalandırma işlem hattına bildirilir. Bir veritabanı silinirse, eski yedeklemeler yaşaşımına uğrar ve silindikçe yedekleme depolama alanı tüketimi yavaş yavaş azalır. Fark yedeklemeleri ve günlük yedeklemeleri, daha önce bir tam yedeklemenin geri yüklenebilir olmasını gerektirdiğinden, üç yedekleme türünün tümü haftalık kümeler halinde temizlenir. Tüm yedeklemeler silindikten sonra faturalandırma duraklar.

Basitleştirilmiş bir örnek olarak, veritabanı tamamen boşta olduğu için bir veritabanının 744 GB 'lık yedekleme depolama alanı olduğunu ve bu miktarın tüm bir ay boyunca sabit kalacağını varsayalım. Bu toplu depolama tüketimini saatlik kullanıma dönüştürmek için, 744,0 (ayda 31 gün * günde 24 saat) ayırın. SQL Veritabanı, veritabanının her saat, sabit bir hızda 1 GB 'lık yedek yedekleme tükettiğini Azure faturalandırma işlem hattına bildirir. Azure Faturalandırma, bu tüketimi toplar ve tüm ay için 744 GB kullanımını gösterir. Maliyet, bölgenizdeki tutara/GB/ay oranına göre yapılır.

Şimdi daha karmaşık bir örnek. Aynı boş veritabanını, bekletmenin, Ayın ortasında yedi günden 14 güne kadar arttığını varsayın. Bu artış, toplam yedekleme depolama alanının 1.488 GB 'a katmasına neden olur. SQL Veritabanı 1 ila 372 (ayın ilk yarısında) 1 GB 'lık kullanım için rapor verebilir. Kullanım süresi 373 ile 744 arasında (ayın ikinci yarısında), kullanımı 2 GB olarak raporlayabilir. Bu kullanım, son 1.116 GB/ay faturalandırılmakta toplanacak.

Gerçek yedekleme faturalandırma senaryoları daha karmaşıktır. Veritabanındaki değişiklik hızı iş yüküne ve zaman içinde değişken olmasına bağlı olduğundan, her bir değişiklik ve günlük yedeklemesinin boyutu da farklılık gösterir ve saatlik yedekleme depolama tüketiminin buna uygun şekilde dalgalanmasına neden olur. Ayrıca, her fark yedeklemesi, son tam yedeklemeden bu yana veritabanında yapılan tüm değişiklikleri içerir, bu nedenle tüm fark yedeklemelerinin toplam boyutu bir hafta boyunca kademeli olarak artar ve daha eski bir tam, değişiklik ve günlük yedekleri kümesi bir kez daha belirginleşerek keskin hale getirilir. Örneğin, tam bir yedekleme tamamlandıktan sonra, dizin yeniden oluşturma gibi ağır bir yazma etkinliği çalıştırıldıysa, dizin yeniden oluşturma işlemi tarafından yapılan değişiklikler yeniden oluşturma süresince alınan işlem günlüğü yedeklemelerine, sonraki değişiklik yedeklemesine ve sonraki tam yedekleme gerçekleşene kadar her değişiklik yedeklemesine dahil edilir. Daha büyük veritabanlarındaki İkinci senaryo için, değişiklik yedeklemesi çok büyük değilse, hizmette en iyi duruma getirme değişiklik yedeklemesi yerine tam yedekleme oluşturur. Bu, aşağıdaki tam yedekleme yapılıncaya kadar tüm değişiklik yedeklemelerinin boyutunu azaltır.

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

Yedekleme depolama yedekliliği

Yedekleme depolama artıklığı, yedekleme maliyetlerini aşağıdaki şekilde etkiler:

• Yerel olarak yedekli fiyat = x
• bölge-yedekli fiyat = 1,25 x
• coğrafi olarak yedekli fiyat = 2x

yedekleme depolama fiyatlandırması hakkında daha fazla ayrıntı için Azure SQL Veritabanı fiyatlandırma sayfası ve Azure SQL yönetilen örnek fiyatlandırma sayfasınıziyaret edin.

Maliyetleri izleme

Yedekleme depolama maliyetlerini anlamak için Azure portal maliyet yönetimi + faturalandırma ' e gidin, maliyet yönetimi' ni seçin ve ardından Maliyet Analizi' ni seçin. Kapsam olarak istenen aboneliği seçin ve ilgilendiğiniz zaman aralığı ve hizmet için filtre uygulayın.

Hizmet adı için bir filtre ekleyin ve ardından açılan listede SQL veritabanı ' nı seçin. Hizmetiniz için faturalandırma sayacını seçmek üzere ölçüm alt kategori filtresini kullanın. Tek bir veritabanı veya elastik veritabanı havuzu için, tek/elastik havuz yedek depolama' yı seçin. Yönetilen bir örnek için mı. yedekleme depolama alanı' nı seçin. Depolama ve işlem alt kategorileri sizi ilgilendirir, ancak yedekleme depolama maliyetleriyle ilişkili değildir.

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

Şifrelenmiş yedeklemeler

Veritabanınız TDE ile şifrelenirse, yedeklemeler, LTR yedeklemeler de dahil olmak üzere Rest 'de otomatik olarak şifrelenir. Azure SQL 'deki tüm yeni veritabanları, tde varsayılan olarak etkin ile yapılandırılır. tde hakkında daha fazla bilgi için, bkz. SQL Veritabanı & SQL yönetilen örnek Saydam Veri Şifrelemesi.

Yedekleme bütünlüğü

Azure SQL mühendislik ekibi, sürekli olarak otomatik veritabanı yedeklemelerinin geri yüklemesini otomatik olarak sınar. (bu test, SQL yönetilen örnekte şu anda kullanılamıyor. iş yükünüze göre zamanlanmış SQL yönetilen örnekteki veritabanlarınızda DBCC CHECKDB 'yi zamanlamanız gerekir.)

Bir noktadan sonra geri yükleme sonrasında veritabanları DBCC CHECKDB bütünlük denetimleri de alır.

Bütünlük denetimi sırasında bulunan tüm sorunlar, mühendislik ekibine bir uyarıya 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 sağlama TOPLAMı seçeneğiyle alınır.

Uyumluluk

Veritabanınızı DTU tabanlı bir hizmet katmanından sanal çekirdek tabanlı bir hizmet katmanına geçirdiğinizde, uygulamanızın veri kurtarma ilkesinin tehlikeye atılmasını sağlamak için, sür saklama korunur. Varsayılan saklama, uyumluluk gereksinimlerinizi karşılamıyorsa, elde tutma süresini değiştirebilirsiniz. Daha fazla bilgi için bkz. yedek saklama süresini değiştirme.

Kısa süreli saklama ilkesini değiştirme

Azure portal, PowerShell veya REST API kullanarak varsayılan olan yedek saklama süresini ve değişiklik yedekleme sıklığını değiştirebilirsiniz. Aşağıdaki örneklerde, AKR bekletmenin 28 güne ve değişiklik yedeklemelerinin 24 saatlik aralığa nasıl değiştirileceği gösterilmektedir.

Azure portal kullanarak kısa süreli saklama ilkesini değiştirme

Azure portal kullanarak, etkin veritabanlarının ara yedek saklama süresini veya değişiklik yedekleme sıklığını değiştirmek için, saklama süresini değiştirmek istediğiniz veritabanlarında sunucuya veya yönetilen örneğe gidin. Sol bölmedeki yedeklemeler ' i seçin, sonra bekletme ilkeleri sekmesini seçin. İçin yedek saklama için değişiklik yapmak istediğiniz veritabanlarını seçin. Ardından Eylem çubuğundan bekletmeyi Yapılandır ' ı seçin.

Azure CLı kullanarak kısa süreli saklama ilkesini değiştirme

Ortamınızı Azure CLı için hazırlayın.

• Azure Cloud Shell'Da Bash ortamını kullanın.

  

• Dilerseniz CLI başvuru komutlarını çalıştırmak için Azure CLI’yi yükleyebilirsiniz.

  • Yerel yükleme kullanıyorsanız az login komutunu kullanarak Azure CLI ile oturum açın. Kimlik doğrulama işlemini tamamlamak için terminalinizde görüntülenen adımları izleyin. Ek oturum açma seçenekleri için bkz. Azure CLI ile oturum açma.

  • İstendiğinde, ilk kullanımda Azure CLI uzantılarını yükleyin. Uzantılar hakkında daha fazla bilgi için bkz. Azure CLI ile uzantıları kullanma.

  • Yüklü sürümü ve bağımlı kitaplıkları bulmak için az version komutunu çalıştırın. En son sürüme yükseltmek için az upgrade komutunu çalıştırın.

# Set new PITR differential backup frequency on an active individual database
# Valid backup retention must be between 1 and 35 days
# Valid differential backup frequency must be ether 12 or 24
az sql db str-policy set \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --retention-days 28 \
    --diffbackup-hours 24

# Set new PITR backup retention period on an active individual database
# Valid backup retention must be between 1 and 35 days
az sql midb short-term-retention-policy set \
    --resource-group myresourcegroup \
    --managed-instance myinstance \
    --name mymanageddb \
    --retention-days 1 \

# Set new PITR backup retention period for ALL active databases
# Valid backup retention must be between 1 and 35 days
az sql midb short-term-retention-policy set \
    --resource-group myresourcegroup \
    --managed-instance myinstance \
    --retention-days 1 \

PowerShell kullanarak kısa süreli saklama ilkesini değiştirme

# SET new PITR backup retention period on an active individual database
# Valid backup retention must be between 1 and 35 days
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28

# SET new PITR differential backup frequency on an active individual database
# Valid differential backup frequency must be ether 12 or 24. 
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28 -DiffBackupIntervalInHours 24

# SET new PITR backup retention period on an active individual database
# Valid backup retention must be between 1 and 35 days
Set-AzSqlInstanceDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -InstanceName testserver -DatabaseName testDatabase -RetentionDays 1

# SET new PITR backup retention period for ALL active databases
# Valid backup retention must be between 1 and 35 days
Get-AzSqlInstanceDatabase -ResourceGroupName resourceGroup -InstanceName testserver | Set-AzSqlInstanceDatabaseBackupShortTermRetentionPolicy -RetentionDays 1

# SET new PITR backup retention on an individual deleted database
# Valid backup retention must be between 0 (no retention) and 35 days. Valid retention rate can only be lower than the period of the retention period when database was active, or remaining backup days of a deleted database.
Get-AzSqlDeletedInstanceDatabaseBackup -ResourceGroupName resourceGroup -InstanceName testserver -DatabaseName testDatabase | Set-AzSqlInstanceDatabaseBackupShortTermRetentionPolicy -RetentionDays 0

# SET new PITR backup retention for ALL deleted databases
# Valid backup retention must be between 0 (no retention) and 35 days. Valid retention rate can only be lower than the period of the retention period when database was active, or remaining backup days of a deleted database
Get-AzSqlDeletedInstanceDatabaseBackup -ResourceGroupName resourceGroup -InstanceName testserver | Set-AzSqlInstanceDatabaseBackupShortTermRetentionPolicy -RetentionDays 0

REST API kullanarak kısa süreli saklama ilkesini değiştirme

Aşağıdaki istek, bekletme süresini 28 gün olarak güncelleştirir ve ayrıca fark yedekleme sıklığını 24 saate ayarlar.

PUT https://management.azure.com/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/resourceGroup/providers/Microsoft.Sql/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default?api-version=2021-02-01-preview

{ 
    "properties":{
        "retentionDays":28
        "diffBackupIntervalInHours":24
  }
}

{ 
  "id": "/subscriptions/00000000-1111-2222-3333-444444444444/providers/Microsoft.Sql/resourceGroups/resourceGroup/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default",
  "name": "default",
  "type": "Microsoft.Sql/resourceGroups/servers/databases/backupShortTermRetentionPolicies",
  "properties": {
    "retentionDays": 28
    "diffBackupIntervalInHours":24
  }
}

PUT https://management.azure.com/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/resourceGroup/providers/Microsoft.Sql/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default?api-version=2017-10-01-preview

{
  "properties":{
    "retentionDays":28
  }
}

{
  "id": "/subscriptions/00000000-1111-2222-3333-444444444444/providers/Microsoft.Sql/resourceGroups/resourceGroup/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default",
  "name": "default",
  "type": "Microsoft.Sql/resourceGroups/servers/databases/backupShortTermRetentionPolicies",
  "properties": {
    "retentionDays": 28
  }
}

Yedek depolama yedekliliği yapılandırma

SQL veritabanları için yapılandırılabilir depolama yedekliliği, veritabanı oluşturma sırasında yapılandırılabilir veya mevcut bir veritabanı için güncelleştirilemeyebilir; var olan bir veritabanında yapılan değişiklikler yalnızca gelecekteki yedeklemeler için geçerlidir. SQL yönetilen örnek ve hiper ölçek yedekleme depolama yedekliği için, yalnızca oluşturma işlemi sırasında belirtilebilir. Kaynak sağlandıktan sonra yedek depolama artıklığı seçeneğini değiştiremezsiniz. Varsayılan değer, coğrafi olarak yedekli depolama. Yerel olarak yedekli, bölgesel olarak yedekli ve coğrafi olarak yedekli yedekleme depolaması arasındaki fiyatlandırma farkları için yönetilen örnek fiyatlandırma sayfasınıziyaret edin.

Azure portal kullanarak yedek depolama yedekliliği yapılandırma

Azure CLı kullanarak yedek depolama yedekliliği yapılandırma

az sql db create \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --tier GeneralPurpose \
    --backup-storage-redundancy Local

az sql db update \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --backup-storage-redundancy Local

PowerShell kullanarak yedek depolama yedekliliği yapılandırma

# Create a new database with geo-redundant backup storage.  
New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database03" -Edition "GeneralPurpose" -Vcore 2 -ComputeGeneration "Gen5" -BackupStorageRedundancy Geo

# Change the backup storage redundancy for Database01 to zone-redundant. 
Set-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -DatabaseName "Database01" -ServerName "Server01" -BackupStorageRedundancy Zone

New-AzSqlInstance -Name managedInstance2 -ResourceGroupName ResourceGroup01 -Location westcentralus -AdministratorCredential (Get-Credential) -SubnetId "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/resourcegroup01/providers/Microsoft.Network/virtualNetworks/vnet_name/subnets/subnet_name" -LicenseType LicenseIncluded -StorageSizeInGB 1024 -VCore 16 -Edition "GeneralPurpose" -ComputeGeneration Gen4 -BackupStorageRedundancy Geo

Yedekleme depolama yedekliliği zorlamak için Azure Ilkesini kullanma

tüm verilerinizi tek bir Azure bölgesinde tutmanızı gerektiren veri yerleşimi gereksinimleriniz varsa, Azure ilkesini kullanarak SQL Veritabanı veya yönetilen örneğiniz için bölgesel olarak yedekli veya yerel olarak yedekli yedeklemeler zorlamak isteyebilirsiniz. Azure Ilkesi, Azure kaynaklarına kurallar uygulayan ilkeler oluşturmak, atamak ve yönetmek için kullanabileceğiniz bir hizmettir. Azure Ilkesi, bu kaynakları kurumsal standartlarınızla ve hizmet düzeyi Sözleşmelerinizle uyumlu tutmanıza yardımcı olur. Daha fazla bilgi için bkz. Azure Ilkesine genel bakış.

Yerleşik yedekleme depolama artıklığı ilkeleri

Yeni veritabanları veya örnek oluşturmayı engellemek için abonelik veya kaynak grubu düzeyinde atanabilir ve coğrafi olarak yedekli yedekleme depolama ile yeni veritabanı veya örnek oluşturulmasını engellemek için aşağıdaki yeni yerleşik ilkeler eklenmiştir.

SQL Veritabanı grs yedek yedekliliği kullanmaktan kaçınmalıdır

SQL yönetilen örnekler, grs yedek yedekliliği kullanmaktan kaçınmalıdır

SQL Veritabanı ve yönetilen örnek için yerleşik ilke tanımlarının tam listesini buradabulabilirsiniz.

Bir kuruluş düzeyinde veri yerleşimi gereksinimlerini zorlamak için bu ilkeler bir aboneliğe atanabilir. Bu ilkeler bir abonelik düzeyinde atandıktan sonra, belirtilen abonelikteki kullanıcılar Azure portal veya Azure PowerShell aracılığıyla coğrafi olarak yedekli yedekleme depolama alanı ile bir veritabanı veya yönetilen örnek oluşturamaz.

Azure portal veya Azure PowerShell

Sonraki adımlar

• Veritabanı yedeklemeleri, verilerinizi yanlışlıkla bozulmaya veya silinmeye karşı korumaları nedeniyle iş sürekliliği ve olağanüstü durum kurtarma stratejisinin temel parçalarındandır. Diğer iş sürekliliği çözümleri hakkında SQL Veritabanı için bkz. İş sürekliliği'ne genel bakış.
• Azure portal kullanarak Azure Blob depolamada otomatik yedeklemelerin uzun süreli saklamayı yapılandırma, yönetme ve geri yükleme hakkında bilgi için bkz.Azure portal.
• PowerShell kullanarak Azure Blob depolamada otomatik yedeklemelerin uzun süreli saklamayı yapılandırma, yönetme ve geri yükleme hakkında bilgi için bkz. PowerShell kullanarak uzun süreli yedekleme saklamayı yönetme.
• veritabanını zaman içinde bir noktaya geri yükleme hakkında daha fazla bilgi için Azure portal.
• PowerShell kullanarak veritabanını zaman içinde bir noktaya geri yükleme hakkında daha fazla bilgi edinebilirsiniz.
• Azure yönetilen örneği üzerinde yedekleme depolama alanı tüketimi hakkında SQL için bkz. Yönetilen Örnekte yedekleme depolama tüketimi açıklaması.
• Azure yönetilen örneği için yedekleme depolama saklama ve maliyetlerde hassas ayarlama SQL için bkz. Yönetilen Örnekte yedekleme depolama maliyetlerini ayarlama.