Uzun süreli saklama yedeklemeleri - Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği

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

Bu makalede, Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği için uzun süreli saklama (LTR) yedeklemelerine kavramsal bir genel bakış sağlanır. Uzun süreli saklama, Azure SQL Veritabanı (Hiper Ölçek hizmet katmanı dahil) ve Azure SQL Yönetilen Örneği için yedeklemelerde 10 yıla kadar yapılandırılabilir.

Uzun süreli saklama yedekleme özelliğini kullanmaya başlamak için bkz:

Önemli

Uzun süreli saklama (LTR) yedekleme işlemleri için kullanılan bazı eski API'ler kullanım dışıdır ve artık desteklenmez. gibi Copy-AzSqlDatabaseLongTermRetentionBackupeski PowerShell cmdlet'lerini kullanmaktan kaçının. Bunun yerine bu makalede açıklanan desteklenen geri yükleme yöntemlerini kullanın.

Uzun süreli saklama nasıl çalışır?

Birçok uygulamanın, otomatik yedeklemelerin kısa süreli saklama süresi tarafından sağlanan 1-35 günden uzun süre boyunca veritabanı yedeklerini saklamanızı gerektiren mevzuat, uyumluluk veya diğer iş nedenleri vardır. Uzun süreli yedekleme saklama (LTR), Azure SQL hizmeti tarafından otomatik olarak oluşturulan tam veritabanı yedeklemelerine dayanır. Daha fazla bilgi için bkz. Azure SQL Veritabanı'da otomatik yedeklemeler veya Azure SQL Yönetilen Örneği'de özel yedeklemeler.

LTR özelliğini kullanarak, 10 yıla kadar yapılandırılabilir saklama ilkesiyle belirtilen tam SQL Veritabanı ve SQL Yönetilen Örneği yedeklemelerini yedekli Azure Blob depolama alanında depolayabilirsiniz. LTR yedekleri daha sonra yeni bir veritabanı olarak geri yüklenebilir. Bir LTR ilkesi yapılandırılırsa, otomatik yedeklemeler uzun süreli depolama için farklı bloblara kopyalanır ve bu blobları kullanarak veritabanınızı belirli bir zamana geri yükleyebilirsiniz. Kopyalama işlemi, veritabanı iş yükü üzerinde performans etkisi olmayan bir arka plan işidir. Her veritabanı için LTR ilkesi, LTR yedeklemelerinin ne sıklıkta oluşturulduğunu da belirtebilir.

Not

  • Azure SQL Veritabanı uzun süreli saklama yedeklerini sabit olarak yapılandırabilirsiniz.
  • Azure SQL Yönetilen Örneği'da yedeklemeleri şu anda mutable olarak yapılandırmak mümkün değildir. LTR yedeklemeleri değiştirilemez, ancak bunları Azure portal, Azure CLI, PowerShell veya REST API aracılığıyla silebilirsiniz. Azure SQL Yönetilen Örneği'te bir geçici çözüm olarak, copy-only veritabanı yedeklerini alabilir ve bunları değiştirilemez bir dosya olarak kendi Azure Depolama hesabınızda tutabilirsiniz.

LTR'yi etkinleştirmek için, dört parametrenin birleşimini kullanarak bir ilke tanımlayabilirsiniz: haftalık yedekleme saklama (W), aylık yedekleme saklama (M), yıllık yedekleme saklama (Y) ve yılın haftası (WeekOfYear). W belirtirseniz, her hafta bir yedekleme uzun vadeli depolama alanına kopyalanır. M belirtirseniz, her ayın ilk yedeklemesi uzun vadeli depolama alanına kopyalanır. Y belirtirseniz, WeekOfYear tarafından belirtilen hafta boyunca bir yedekleme uzun vadeli depolama alanına kopyalanır. İlke yapılandırıldığında belirtilen WeekOfYear geçmişteyse, ilk LTR yedeklemesi sonraki yıl oluşturulur. Her yedekleme, LTR yedeklemesi oluşturulduğunda yapılandırılan ilke parametrelerine göre uzun süreli depolamada tutulur.

LTR ilkesindeki değişiklikler yalnızca gelecekteki yedeklemeler için geçerlidir. Örneğin, haftalık yedekleme saklama (W), aylık yedekleme saklama (M) veya yıllık yedekleme saklamayı (Y) değiştirirseniz, yeni saklama ayarı yalnızca yeni yedeklemeler için geçerlidir. Mevcut yedeklemelerin saklama süresi değiştirilmez. LTR ilkesi Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği her veritabanı için yapılandırılabilir. Eski LTR yedeklemelerini saklama süreleri dolmadan silmeyi planlıyorsanız, yedeklemeleri el ile silebilirsiniz.

Not

Hem Azure SQL Veritabanı hem de Azure SQL Yönetilen Örneği'da, bir LTR ilkesini bir veritabanı için ilk kez etkinleştirdiğinizde, nokta zamanı kurtarmadan (PITR) en son tam yedekleme uzun vadeli depolamaya kopyalanır.

LTR politikası örnekleri:

  • W=0, M=0, Y=5, WeekOfYear=3

    Her yılın üçüncü tam yedeklemesi beş yıl boyunca saklanır.

  • W=0, M=3, Y=0

    Her ayın ilk tam yedeklemesi üç ay boyunca tutulur.

  • W=12, M=0, Y=0

    Her haftalık tam yedekleme 12 hafta boyunca saklanır.

  • W=6, M=12, Y=10, WeekOfYear=20

    Her haftalık tam yedekleme altı hafta boyunca tutulur. Her ay yapılan ilk tam yedekleme hariç, bu yedekleme 12 ay boyunca saklanır. Yılın 20. haftasında alınan ve 10 yıl boyunca tutulan tam yedekleme hariç.

Aşağıdaki tabloda, aşağıdaki ilke için uzun vadeli yedeklemelerin temposu ve süre sonu gösterilmektedir:

W=12 weeks (84 gün), M=12 months (365 gün), Y=10 years (3.650 gün), WeekOfYear=20 (13 Mayıs'ı geçen hafta)

Aşağıdaki tarihler ISO 8601 (YYYY-MM-DD içindedir).

LTR'ye PITR yedeklemesi Süre Sonu W Süre Sonu M Son Kullanma Tarihi Y
2018-03-07 2019-03-02
2018-03-14 2018-06-06
2018-03-21 2018-06-13
2018-03-28 2018-06-20
04-04-2018 2019-03-30
2018-04-11 2018-07-04
2018-04-18 2018-07-11
2018-04-25 2018-07-18
2018-05-02 2019-04-27
2018-05-09 2018-08-01
2018-05-16 13.05.2028
2018-05-23 2018-08-15
2018-05-30 2018-08-22
2018-06-06 01.06.2019
2018-06-13 2018-09-05
2018-06-20 2018-09-12
2018-06-27 2018-09-19
2018-07-04 2019-06-29
2018-07-11 2018-10-03
2018-07-18 2018-10-10
2018-07-25 2018-10-17
2018-08-01 2019-07-27
2018-08-08 2018-10-31
2018-08-15 2018-11-07
2018-08-22 2018-11-14
2018-08-29 2018-11-21

Bu ilkeyi değiştirir ve ayarlarsanız W=0 (haftalık yedekleme yoktur), haftalık yedeklemeler süresi dolana kadar korunur ve ardından hizmet yalnızca aylık ve yıllık yedeklemeleri korur. LTR ilkesi altında gelecekteki haftalık yedeklemeler depolanmaz. Bu yedeklemeleri tutmak için gereken depolama miktarı buna göre azalır.

Önemli

Tek tek LTR yedeklemelerinin zamanlaması Microsoft tarafından denetlenmektedir. LTR yedeğini manuel olarak oluşturamaz veya yedek oluşturma zamanlamasını denetleyemezsiniz. Bir LTR ilkesini yapılandırdıktan sonra, ilk LTR yedeklemesinin kullanılabilir yedeklemeler listesinde yer alması yedi güne kadar sürebilir.

Mantıksal sunucuyu veya SQL yönetilen örneğini silerseniz, bu sunucudaki veya yönetilen örnekteki tüm veritabanları da silinir. Silinen mantıksal sunucuyu veya SQL yönetilen örneğini geri yükleyemezsiniz. Ancak, bir veritabanı için LTR yapılandırdıysanız, LTR yedeklemeleri silinmez ve veritabanlarını aynı abonelikteki farklı bir sunucuya veya yönetilen örneğe, ltr yedeklemesinin alındığı belirli bir noktaya geri yüklemek için kullanılabilir.

Benzer şekilde, bir veritabanını silerseniz, LTR yedeklemeleri silinmez ve yapılandırılan saklama süresi boyunca korunur. Bu yedeklemeler aynı sunucuya veya aynı abonelikteki farklı bir sunucuya geri yüklenebilir.

Coğrafi çoğaltma ve uzun süreli yedek saklama

İş sürekliliği çözümünüz olarak etkin coğrafi çoğaltma veya yük devretme grupları kullanıyorsanız, sonrasında meydana gelebilecek yük devretme işlemlerine hazırlanın ve birincil veritabanında olduğu gibi ikincil veritabanı veya örnekte de aynı LTR politikasını yapılandırın. Yedekler ikincil kaynaklardan oluşturulmadığından LTR depolama maliyetiniz artmıyor. Yedeklemeler yalnızca ikincil, birincil duruma geldikten sonra oluşturulur, böylece yük devretme tetiklendiğinde ve birincil ikincil bölgeye geçtiğinde LTR yedeklemelerinin kesintisiz oluşturulması sağlanır.

Asıl birincil veritabanı, kesintiden kurtulduğunda yeni bir ikincil veritabanı olur. Bu nedenle, yedekleme oluşturma işlemi yeni ikincil sunucuda devam etmez ve mevcut LTR ilkesi yeniden birincil olana kadar geçerli olmaz.

Ağ güvenlik çevresi ve LTR geri yükleme (önizleme)

Not

Ağ güvenliği çevresi (önizleme) yalnızca Azure SQL Veritabanı için geçerlidir. Azure SQL Yönetilen Örneği ortama alınmış bir kaynak değildir, bu yüzden bu bölüm ona uygulanmaz. Mevcut liste için bkz. Onboarded özel bağlantı kaynakları.

LTR geri yükleme, uzun vadeli yedekten hedef mantıksal sunucuya veritabanını geri getiren platform tarafından yönetilen bir işlemdir. Mantıksal sunuculardan biri bir çevreye ait olduğunda, geri yükleme çevrenin erişim kurallarına tabidir.

Hizmet, kaynak sunucudaki çıkış erişimini, o sunucu hâlâ mevcutsa, ve hedef sunucudaki gelen erişimi kontrol eder. Kaynak mantıksal sunucu silindiyse, yalnızca hedef taraf gelen kontrol çalışabilir.

Desteklenen yapılandırmalar

LTR restore hem geçiş modunda hem de zorunlu modda çalışır. Geçiş modunda, geri yüklemeler erişim kuralları olmadan başarılı olur. Zorunlu moda geçmeden önce kuralları yapılandırın.

Zorunlu modda ise şu yapılandırmalar desteklenir:

Kaynak sunucu Hedef sunucu Erişim kuralları gereklidir
Bir çevre içinde Aynı sınır içinde None. Aynı güvenlik çevresindeki kaynaklar arasında erişime her zaman izin verilir.
Bir çevre sınırı içinde Farklı bir sınırda Kaynakta giden, hedefte gelen.
Bir çevre içinde Sınırda değil Kaynaktan giden.
Bir çevre içinde değil Bir çevre içinde Hedefe doğru ilerliyor.
Silindi Bir çevre sınırında Hedefe giriş yapıyor.
Bir güvenlik çevresi içinde değil Çevre içinde değil None.

LTR geri yükleme için yönetilen bir kimlik gerekmez.

LTR geri yüklemesi için erişim kurallarını yapılandırma

  1. Henüz yapmadıysanız, her mantıksal sunucuyu çevresiyle ilişkilendirin. Sınır dışında kalan sunucu veya silinmiş kaynak sunucu için bu adımı atlayın.
  2. Eğer kaynak sunucu bir perimetredeyse ve hedef sunucu aynı perimetrede değilse, kaynak profiline Destination type değeri FQDN olarak ayarlanmış ve hedef sunucunun tam nitelikli alan adını içeren bir outbound kuralı ekleyin.
  3. Hedef sunucu bir güvenlik çevresindeyse ve kaynak sunucu aynı güvenlik çevresinde değilse, hedef profiline gelen bir kural ekleyin. Geri yükleme talebi kaynak sunucudan değil, Azure SQL yönetim altyapısından gelir. Kuralda, şu kaynaklardan birine izin verin:
    • Kaynak sunucunun abonelik kimliği (önerilen).
    • Servis etiketi (önerilir).
    • IP adresi aralıkları. Genel bulut için, Azure IP Aralıkları ve Hizmet Etiketleri - Genel Bulut her hizmet etiketini ve IP adres aralıklarını listeler. Hizmet etiketi adı SqlManagement. Microsoft bu aralıkları bölgeye göre yayınlamıyor, bu yüzden hepsine izin ver.
  4. Sunucular hâlâ geçiş modundayken bir geri yükleme yapın ve ağ güvenliği çevresi tanı kayıtlarını beklenmedik reddler için kontrol edin.
  5. Tüm tanı kontrolleri geçtikten sonra zorlanan moda geçin.

Sınırlamalar ve davranış farklılıkları

  • Sınır ilişkilendirmesi zorunlu moddayken LTR yedekleri olan mantıksal bir sunucuyu silemezsiniz. Değişmez LTR yedeklemeleri, sunucu çevre ağında olsun ya da olmasın silmeyi de engeller. Daha fazla bilgi için bkz. Değişmez uzun süreli yedeklemeler ve mantıksal sunucuların silinmesi.
  • Bir kaynak sunucuyu ilişkisi geçiş modundayken silerseniz, hizmet artık o sunucunun perimeter meta verilerini okuyamaz, bu yüzden sadece geri yüklemenin hedef tarafını doğrulayabilir. Kaynak tarafı doğrulamaya güveniyorsanız bu boşluğu hesaba katın.
  • Geçiş modunda, gerekli kurallar eksik olsa bile geri yükleme başarılı olur. Zorunlu modda ise aynı geri yükleme engellenir.

Uzun süreli yedek saklama yapılandırma

Önemli

Uzun süreli saklama (LTR) yedekleme işlemleri için kullanılan bazı eski API'ler kullanım dışıdır ve artık desteklenmez. gibi Copy-AzSqlDatabaseLongTermRetentionBackupeski PowerShell cmdlet'lerini kullanmaktan kaçının. Bunun yerine bu makalede açıklanan desteklenen geri yükleme yöntemlerini kullanın.

Azure SQL Veritabanı ve Azure SQL Yönetilen Örneği için Azure portalını ve PowerShell'i kullanarak uzun süreli yedekleme saklamayı yapılandırabilirsiniz. Bir veritabanını LTR depolama alanından geri yüklemek için zaman damgasına göre belirli bir yedekleme seçebilirsiniz. Veritabanı, özgün veritabanıyla aynı abonelik altında mevcut herhangi bir sunucuya veya yönetilen örneğe geri yüklenebilir. Geri yükleme yetenekleri, sınırlamalar ve özelliklerin tam listesi için bkz. Azure SQL Yönetilen Örneği'ta Restorasyon Kapasiteleri ve Özellikleri.

LTR saklama süresinin son yedi gününde bir geri yükleme isteği başlatıldığında, LTR yedeklemesi yalnızca saklama süresi dolmuş olsa bile geri yükleme işlemi tamamlandıktan sonra silinir.

Not

Hiper Ölçek hizmet katmanı ile Azure SQL Veritabanı diğer hizmet katmanları arasında veritabanlarının geri yüklenmesi şu anda desteklenmemektedir.

Azure SQL Yönetilen Örneği'da SQL Aracısı işlerini kullanarak copy-only veritabanı yedeklemeleri zamanlayabilir ve bunları aşağıdakilere alternatif olarak kendi depolama hesabınıza taşıyabilirsiniz:

  • Yedeklemeleri 10 yıldan daha uzun süre tutun.
  • Veritabanlarınızın günlük kopyalarını 35 günden daha uzun süre tutun.
  • Veritabanı yedeklemelerini sabit depolama alanında depolayın.

Tavsiye

Uyumluluk veya görev açısından kritik diğer gereksinimleri karşılamak için LTR yedeklemeleri kullanıyorsanız, LTR yedeklemelerinin geri yüklenebileceğini ve geri yüklemenin beklenen veritabanı durumunda sonuçlandığını doğrulamak için düzenli kurtarma tatbikatları gerçekleştirmeyi göz önünde bulundurun.

Not

LTR yedekleri, başarılı tam yedeklere bağlıdır. Tam işlem günlüğü, planlanmış tam yedeklemeyi engelleyebilir, bu da LTR yedeklemesini engelleyebilir. Değişim veri yakalama (CDC) ve işlem günlüğünün kesilmesini engelleyen diğer özellikler, LTR yedeklemesini geciktirebilir ve bu yedekleme ancak tam yedekleme başarılı olduktan sonra başarılı olur. İşlem günlüğünün kesilmesini önleyen özellikleri değerlendirin ve yedekleme işlemleri geri gelene kadar geçici olarak devre dışı bırakmayı düşünün.

Sonraki adım

Azure SQL Veritabanı uzun vadeli yedekleme saklama yönetme

Azure SQL Yönetilen Örneği uzun süreli yedekleme saklamayı yönet

İlgili içerik

Veritabanı yedeklemeleri verileri yanlışlıkla bozulmaya veya silinmeye karşı koruduğundan, iş sürekliliği ve olağanüstü durum kurtarma stratejilerinin önemli bir parçasıdır.

  • Son güncelleştirme: