Pencadangan penyimpanan jangka panjang untuk Azure SQL Database dan Azure SQL Managed Instance

Aplikasi ke:Azure SQL DatabaseAzure SQL Managed Instance

Artikel ini memberikan gambaran umum konseptual cadangan retensi jangka panjang (LTR) 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 mulai menggunakan fitur cadangan retensi jangka panjang, lihat:

Penting

Beberapa API lama yang digunakan untuk operasi pencadangan retensi jangka panjang (LTR) telah usang dan tidak lagi mendapatkan dukungan. Hindari menggunakan cmdlet PowerShell warisan seperti Copy-AzSqlDatabaseLongTermRetentionBackup. Gunakan metode pemulihan yang didukung yang dijelaskan dalam artikel ini sebagai gantinya.

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 Pencadangan otomatis di Azure SQL Managed Instance.

Dengan menggunakan fitur LTR, Anda dapat menyimpan SQL Database lengkap dan pencadangan SQL Managed Instance yang ditentukan dalam penyimpanan Blob Azure redundan 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. Proses penyalinan adalah pekerjaan latar belakang yang tidak memiliki dampak performa pada beban kerja database. Kebijakan LTR untuk setiap database juga dapat menentukan seberapa sering cadangan LTR dibuat.

Catatan

  • Dalam Azure SQL Database, Anda dapat mengonfigurasi cadangan retensi jangka panjang sebagai tidak dapat diubah.
  • Dalam Azure SQL Managed Instance, saat ini tidak mungkin untuk mengonfigurasi cadangan sebagai immutable. Pencadangan LTR tidak dapat dimodifikasi, tetapi Anda dapat menghapusnya melalui portal Azure, Azure CLI, PowerShell, atau REST API. Sebagai solusi dalam Azure SQL Managed Instance, Anda dapat mengambil cadangan database khusus copy dan menyimpannya di akun Azure Storage Anda sendiri sebagai file yang tidak dapat diubah.

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.

Perubahan pada kebijakan LTR hanya berlaku untuk cadangan di masa mendatang. Misalnya, jika Anda mengubah retensi cadangan mingguan (W), retensi cadangan bulanan (M), atau retensi cadangan tahunan (Y), pengaturan retensi baru hanya berlaku untuk cadangan baru. Retensi cadangan yang ada tidak dimodifikasi. Kebijakan LTR dapat dikonfigurasi untuk setiap database di Azure SQL Database dan Azure SQL Managed Instance. Jika Anda ingin menghapus cadangan LTR lama sebelum periode retensinya kedaluwarsa, Anda dapat menghapus cadangan secara manual.

Catatan

Dalam Azure SQL Database dan Azure SQL Managed Instance, saat Anda pertama kali mengaktifkan kebijakan LTR untuk database, cadangan lengkap terbaru yang diambil dari proses pemulihan ke titik waktu tertentu (PITR) disalin ke penyimpanan jangka panjang.

Contoh kebijakan LTR:

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

    Cadangan lengkap 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 cadangan data 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 (3.650 hari), WeekOfYear=20 (minggu setelah 13 Mei)

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

Pencadangan PITR ke LTR Kedaluwarsa W Masa Berlaku M Kedaluwarsa Y
2018-03-07 2019-03-02
2018-03-14 2018-06-06
2018-03-21 2018-06-13
28-03-2018 2018-06-20
2018-04-04 2019-03-30
2018-04-11 2018-07-04
2018-04-18 2018-07-11
2018-04-25 18-07-2018
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 2019-06-01
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
18-07-2018 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

Jika Anda mengubah kebijakan ini dan mengatur W=0 (tidak ada cadangan mingguan), cadangan mingguan dipertahankan sampai kedaluwarsa, dan kemudian layanan hanya mempertahankan cadangan bulanan dan tahunan. Tidak ada cadangan mingguan mendatang yang disimpan di bawah kebijakan LTR. Jumlah penyimpanan yang diperlukan untuk menyimpan cadangan ini berkurang.

Penting

Waktu pencadangan LTR individu dikendalikan oleh Microsoft. Anda tidak dapat membuat cadangan LTR secara manual atau mengontrol waktu pembuatan cadangan. Setelah Anda mengonfigurasi kebijakan LTR, mungkin perlu waktu hingga tujuh hari sebelum cadangan LTR pertama muncul di daftar cadangan yang tersedia.

Jika Anda menghapus server logis atau instans terkelola SQL, semua database di server atau instans terkelola tersebut juga akan dihapus. Anda tidak dapat memulihkan server logis yang dihapus atau instans terkelola SQL. Namun, jika Anda telah mengonfigurasi LTR untuk database, cadangan LTR tidak dihapus dan dapat digunakan untuk memulihkan database ke 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 replikasi geografis aktif atau grup failover sebagai solusi kelangsungan bisnis Anda, bersiaplah untuk failover akhir dan konfigurasikan kebijakan LTR yang sama pada database atau instans sekunder seperti yang Anda miliki di primer. Biaya penyimpanan LTR Anda tidak meningkat, karena cadangan tidak dihasilkan dari salinan sekunder. Cadangan hanya dibuat setelah wilayah sekunder menjadi primer untuk memastikan pembuatan cadangan LTR berlangsung tanpa gangguan ketika failover dipicu dan wilayah primer berpindah ke wilayah sekunder.

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

Perimeter keamanan jaringan dan pemulihan LTR (pratinjau)

Catatan

Perimeter keamanan jaringan (pratinjau) hanya berlaku untuk Azure SQL Database. Azure SQL Managed Instance bukanlah sumber daya yang sudah di-onboard, jadi bagian ini tidak berlaku untuknya. Untuk daftar saat ini, lihat Sumber daya tautan privat yang telah ditambahkan.

Pemulihan LTR adalah operasi yang dikelola platform yang mengembalikan basis data dari cadangan jangka panjang ke server logis target. Ketika salah satu server logis termasuk dalam perimeter, pemulihan tunduk pada aturan akses perimeter tersebut.

Layanan memeriksa akses keluar pada server sumber, saat server tersebut masih ada, dan akses masuk pada server target. Jika server logis sumber dihapus, hanya pemeriksaan masuk sisi target yang dapat dijalankan.

Konfigurasi yang didukung

Pemulihan LTR berfungsi baik dalam mode transisi maupun mode paksa. Dalam mode transisi, operasi pemulihan berhasil tanpa aturan akses. Konfigurasikan aturan sebelum Anda beralih ke mode penegakan.

Dalam mode penegakan, konfigurasi-konfigurasi berikut didukung:

Server sumber Server tujuan Aturan akses diperlukan
Di dalam perimeter Dalam perimeter yang sama None. Akses antar sumber daya di perimeter yang sama selalu diperbolehkan.
Di dalam perimeter Di perimeter yang berbeda Outbound pada sumber, inbound pada target.
Di dalam perimeter jaringan Tidak di perimeter Outbound ke source.
Tidak di perimeter Dalam batas Masuk ke target.
Dihapus Di dalam perimeter Masuk ke target.
Tidak di perimeter Tidak berada dalam perimeter None.

Pemulihan LTR tidak memerlukan identitas terkelola.

Konfigurasikan aturan akses untuk pemulihan LTR

  1. Hubungkan setiap server logis dengan perimeternya jika Anda belum melakukannya. Lewati langkah ini untuk server yang tetap berada di luar perimeter atau untuk server sumber yang dihapus.
  2. Jika server sumber berada di perimeter dan server target tidak berada dalam perimeter yang sama, tambahkan aturan keluar pada profil sumber dengan tipe Destination disetel ke FQDN dan nama domain server target yang sepenuhnya terkualifikasi.
  3. Jika server target berada di perimeter dan server sumber tidak berada di perimeter yang sama, tambahkan aturan masuk pada profil target. Permintaan pemulihan berasal dari infrastruktur manajemen Azure SQL, bukan dari server sumber. Dalam aturan ini, izinkan salah satu sumber berikut:
    • ID langganan server sumber (direkomendasikan).
    • Tag layanan (direkomendasikan).
    • Rentang alamat IP. Untuk cloud publik, Azure IP Ranges and Service Tags - Public Cloud mencantumkan setiap tag layanan beserta rentang alamat IP-nya. Nama tag layanan adalah SqlManagement. Microsoft tidak mempublikasikan rentang ini berdasarkan wilayah, jadi izinkan semuanya.
  4. Dengan server masih dalam mode transisi, jalankan pemulihan dan periksa log diagnostik perimeter keamanan jaringan untuk penolakan tak terduga.
  5. Beralih ke mode enforcement hanya setelah semua pemeriksaan diagnostik telah lolos.

Keterbatasan dan perbedaan perilaku

  • Anda tidak bisa menghapus server logis yang memiliki cadangan LTR saat asosiasi perimeternya dalam mode yang diberlakukan. Backup LTR yang tidak dapat diubah juga memblokir penghapusan, baik server berada di perimeter maupun tidak. Untuk informasi lebih lanjut, lihat Cadangan jangka panjang yang tidak dapat diubah dan menghapus server logis.
  • Jika Anda menghapus server sumber saat asosiasinya dalam mode transisi, layanan tidak dapat lagi membaca metadata perimeter server tersebut, sehingga hanya dapat memvalidasi sisi target dari pemulihan. Perhitungkan kesenjangan ini jika Anda mengandalkan validasi sisi sumber sebagai kontrol.
  • Dalam mode transisi, pemulihan berhasil meskipun aturan yang diperlukan tidak ada. Dalam mode yang diterapkan, pemulihan yang sama diblokir.

Konfigurasikan retensi cadangan jangka panjang

Penting

Beberapa API lama yang digunakan untuk operasi pencadangan retensi jangka panjang (LTR) telah usang dan tidak lagi mendapatkan dukungan. Hindari menggunakan cmdlet PowerShell warisan seperti Copy-AzSqlDatabaseLongTermRetentionBackup. Gunakan metode pemulihan yang didukung yang dijelaskan dalam artikel ini sebagai gantinya.

Anda dapat mengonfigurasi retensi cadangan jangka panjang menggunakan portal 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 atau instans terkelola yang ada di bawah langganan yang sama dengan database asli. Untuk daftar lengkap kemampuan pemulihan, batasan, dan fitur, lihat kemampuan dan fitur Restore di Azure SQL Managed Instance.

Ketika permintaan pemulihan dimulai dalam tujuh hari terakhir dari periode retensi LTR, cadangan LTR hanya dihapus setelah operasi pemulihan selesai, bahkan jika periode retensi telah kedaluwarsa.

Catatan

Memulihkan database antara tingkat layanan Hyperscale dan tingkat layanan lain dari Azure SQL Database saat ini tidak didukung.

Dalam Azure SQL Managed Instance, Anda dapat menggunakan pekerjaan SQL Agent untuk menjadwalkan pencadangan database khusus kopi dan memindahkannya ke akun penyimpanan Anda sendiri sebagai alternatif untuk:

  • Simpan cadangan selama lebih dari 10 tahun.
  • Simpan salinan harian database Anda selama lebih dari 35 hari.
  • Simpan cadangan database pada penyimpanan yang tidak dapat diubah.

Petunjuk / Saran

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.

Catatan

Cadangan jangka panjang bergantung pada keberhasilan cadangan penuh. Log transaksi yang penuh dapat mencegah cadangan penuh terjadwal, yang pada gilirannya dapat mencegah cadangan LTR (retensi jangka panjang). Pengambilan data perubahan (CDC) dan fitur lain yang mencegah pemotongan log transaksi dapat menunda pencadangan LTR, yang hanya akan berhasil setelah pencadangan penuh berhasil. Evaluasi fitur yang mencegah pemotongan log transaksi dan pertimbangkan untuk menonaktifkannya sementara sampai operasi backup pulih.

Langkah selanjutnya

Kelola Azure SQL Database retensi cadangan jangka panjang

Kelola Azure SQL Managed Instance retensi cadangan jangka panjang

Konten terkait

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.

  • Terakhir diperbarui pada