Retensi jangka panjang - Azure SQL Database dan Azure SQL Managed Instance

Berlaku untuk:Azure SQL DatabaseAzure SQL Managed Instance

Artikel ini memberikan gambaran umum konseptual tentang retensi cadangan jangka panjang untuk Azure SQL Database dan Azure SQL Managed Instance. Retensi jangka panjang dapat dikonfigurasi hingga 10 tahun pada cadangan untuk Azure SQL Database (termasuk di tingkat layanan Hyperscale), dan Azure SQL Managed Instance.

Untuk memulai, lihat mengonfigurasi retensi cadangan jangka panjang untuk Azure SQL Database dan Azure SQL Managed Instance.

Cara kerja retensi jangka panjang

Banyak aplikasi memiliki alasan peraturan, kepatuhan, atau bisnis lain yang mengharuskan Anda mempertahankan cadangan database di luar 1-35 hari yang disediakan oleh periode retensi jangka pendek cadangan otomatis. Retensi cadangan jangka panjang (LTR) bergantung pada cadangan database lengkap yang secara otomatis dibuat oleh layanan Azure SQL. Untuk informasi selengkapnya, lihat pencadangan otomatis di Azure SQL Database atau Azure SQL Managed Instance.

Dengan menggunakan fitur LTR, Anda dapat menyimpan cadangan SQL Database lengkap dan SQL Managed Instance yang ditentukan dalam penyimpanan Azure Blob yang berlebihan dengan kebijakan penyimpanan yang dapat dikonfigurasi hingga 10 tahun. Pencadangan LTR kemudian dapat dipulihkan sebagai database baru. Jika kebijakan LTR dikonfigurasi, cadangan otomatis disalin ke blob yang berbeda untuk penyimpanan jangka panjang yang kemudian dapat Anda gunakan untuk memulihkan database Anda ke titik waktu tertentu. Salinan adalah pekerjaan latar belakang yang tidak memiliki dampak performa pada beban kerja database. Kebijakan LTR untuk setiap database dalam SQL Database juga dapat menentukan seberapa sering cadangan LTR dibuat.

Catatan

  • Saat ini tidak dimungkinkan untuk mengonfigurasi cadangan Azure SQL Database dan Azure SQL Managed Instance sebagai tidak dapat diubah.
  • Di Azure SQL Managed Instance, gunakan pekerjaan SQL Agent untuk menjadwalkan pencadangan database khusus salinan sebagai alternatif untuk LTR melebihi 35 hari.

Untuk mengaktifkan LTR, Anda dapat menentukan kebijakan menggunakan kombinasi empat parameter: retensi cadangan mingguan (W), retensi cadangan bulanan (M), retensi cadangan tahunan (Y), dan minggu dalam setahun (WeekOfYear). Jika Anda menentukan W, satu cadangan setiap minggu disalin ke penyimpanan jangka panjang. Jika Anda menentukan M, cadangan pertama setiap bulan disalin ke penyimpanan jangka panjang. Jika Anda menentukan Y, satu cadangan selama minggu yang ditentukan oleh WeekOfYear disalin ke penyimpanan jangka panjang. Jika WeekOfYear yang ditentukan berada di masa lalu saat kebijakan dikonfigurasi, cadangan LTR pertama dibuat pada tahun berikutnya. Setiap cadangan disimpan dalam penyimpanan jangka panjang sesuai dengan parameter kebijakan yang dikonfigurasi saat cadangan LTR dibuat.

Setiap perubahan pada kebijakan LTR hanya berlaku untuk pencadangan pada masa mendatang. Misalnya, jika retensi cadangan mingguan (W), retensi cadangan bulanan (M), atau retensi cadangan tahunan (Y) dimodifikasi, pengaturan retensi baru hanya akan berlaku untuk cadangan baru. Retensi cadangan yang ada tidak akan diubah. Jika niat Anda adalah menghapus cadangan LTR lama sebelum periode retensinya berakhir, Anda harus menghapus cadangan secara manual.

Contoh kebijakan LTR:

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

    Pencadangan penuh ketiga setiap tahun disimpan selama lima tahun.

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

    Pencadangan penuh pertama setiap bulan disimpan selama tiga bulan.

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

    Setiap pencadangan penuh mingguan disimpan selama 12 minggu.

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

    Setiap pencadangan penuh mingguan disimpan selama enam minggu. Kecuali pencadangan penuh pertama setiap bulan, yang disimpan selama 12 bulan. Kecuali cadangan penuh yang diambil pada minggu ke-20 dalam setahun, yang disimpan selama 10 tahun.

Tabel berikut ini menggambarkan tempo dan kedaluwarsa pencadangan jangka panjang untuk kebijakan berikut:

W=12 weeks (84 hari), M=12 months (365 hari), Y=10 years (3650 hari), WeekOfYear=20 (minggu setelah 13 Mei)

Tanggal berikut ada di ISO 8601 (YYYY-MM-DD).

Pencadangan PITR ke LTR Kedaluwarsa W Kedaluwarsa M Kedaluwarsa Y
2018-03-07 2019-07-03
2018-03-14 2018-06-06
2018-03-21 2018-06-13
28-03-2018 2018-06-20
2018-04-04 25-04-2019
2018-04-11 2018-07-04
2018-04-18 2018-07-11
2018-04-25 18-07-2018
2018-05-02 2019-05-23
2018-05-09 2018-08-01
2018-05-16 2028-05-13
2018-05-23 2018-08-15
2018-05-30 2018-08-22
2018-06-06 2019-06-20
2018-06-13 2018-09-05
2018-06-20 2018-09-12
2018-06-27 2018-09-19
2018-07-04 2019-07-25
2018-07-11 2018-10-03
18-07-2018 2018-10-10
2018-07-25 2018-10-17
2018-08-01 2019-08-22
2018-08-08 2018-10-31
2018-08-15 2018-11-07
2018-08-22 2018-11-14
2018-08-29 2018-11-21

Jika Anda mengubah kebijakan dan set W=0 di atas (tidak ada cadangan mingguan), layanan hanya mempertahankan cadangan bulanan dan tahunan. Tidak ada cadangan mingguan yang disimpan di bagian kebijakan LTR. Jumlah penyimpanan yang diperlukan untuk menyimpan cadangan ini berkurang.

Penting

Waktu pencadangan LTR individual dikendalikan oleh Azure SQL Database. Anda tidak bisa membuat cadangan LTR secara manual atau mengontrol waktu pembuatan cadangan. Setelah mengonfigurasi kebijakan LTR, mungkin diperlukan waktu hingga 7 hari sebelum pencadangan LTR pertama akan muncul di daftar cadangan yang tersedia.

Jika Anda menghapus server logis atau instans terkelola, semua database di server atau instans terkelola tersebut juga dihapus dan tidak dapat dipulihkan. Anda tidak dapat memulihkan server atau instans terkelola yang dihapus. Namun, jika Anda telah mengonfigurasi LTR untuk database atau instans terkelola, cadangan LTR tidak dihapus, dan mereka dapat digunakan untuk memulihkan database di server atau instans terkelola yang berbeda dalam langganan yang sama, ke titik waktu ketika cadangan LTR diambil.

Demikian pula, jika Anda menghapus database, cadangan LTR tidak dihapus dan dipertahankan untuk periode retensi yang dikonfigurasi. Cadangan ini dapat dipulihkan ke server yang sama atau server lain dalam langganan yang sama.

Replikasi geografis dan retensi cadangan jangka panjang

Jika Anda menggunakan grup replikasi geo aktif atau kegagalan sebagai solusi kelangsungan bisnis Anda, Anda harus mempersiapkan kegagalan yang mungkin terjadi dan mengonfigurasi kebijakan LTR yang sama pada database atau instans sekunder. Biaya penyimpanan LTR Anda tidak meningkat, karena cadangan tidak dihasilkan dari sekunder. File cadangan hanya dibuat ketika yang sekunder menjadi yang utama. Ini memastikan pembuatan cadangan LTR yang tidak terganggu ketika failover dipicu dan primer berpindah ke wilayah sekunder.

Catatan

Ketika database utama asli pulih dari pemadaman yang menyebabkan failover, database tersebut menjadi sekunder baru. Oleh karena itu, pembuatan cadangan tidak akan dilanjutkan, dan kebijakan LTR yang ada tidak berlaku sampai menjadi yang utama lagi.

Konfigurasikan retensi cadangan jangka panjang

Anda dapat mengonfigurasi retensi cadangan jangka panjang menggunakan portal Microsoft Azure dan PowerShell untuk Azure SQL Database dan Azure SQL Managed Instance. Untuk memulihkan database dari penyimpanan LTR, Anda dapat memilih cadangan tertentu berdasarkan tanda waktunya. Database dapat dipulihkan ke server mana pun yang ada atau instans terkelola di bawah langganan yang sama dengan database asli.

Untuk mempelajari cara mengonfigurasi retensi jangka panjang atau memulihkan database dari cadangan untuk SQL Database menggunakan portal Microsoft Azure atau PowerShell, lihat Kelola retensi cadangan jangka panjang Azure SQL Database.

Untuk mempelajari cara mengonfigurasikan retensi jangka panjang atau memulihkan database dari cadangan untuk SQL Managed Instance menggunakan portal Microsoft Azure atau PowerShell, lihat Mengelola retensi data cadangan jangka panjang Azure SQL Managed Instance.

Ketika permintaan pemulihan dimulai dalam 7 hari terakhir dari periode retensi LTR, Azure akan secara otomatis memperpanjang tanggal kedaluwarsa semua cadangan +7 hari, untuk mencegah pencadangan LTR kedaluwarsa selama pemulihan.

Catatan

Jika Anda menggunakan cadangan LTR untuk memenuhi kepatuhan atau persyaratan misi penting lainnya, pertimbangkan untuk melakukan latihan pemulihan berkala untuk memverifikasi bahwa cadangan LTR dapat dipulihkan, dan bahwa pemulihan menghasilkan status database yang diharapkan.

Karena pencadangan database adalah bagian penting dari setiap kelangsungan bisnis dan strategi pemulihan bencana karena melindungi data Anda dari kerusakan dan penghapusan data yang tidak disengaja.

Untuk tutorial tentang mengonfigurasi dan mengelola cadangan LTR, kunjungi: