Mencadangkan SQL Server selalu dalam grup ketersediaan

Azure Backup menawarkan dukungan end-to-end untuk mencadangkan SQL Server selalu dalam grup ketersediaan (AG) jika semua simpul berada dalam satu lokasi dan langganan dengan brankas Layanan Pemulihan. Namun, jika simpul AG tersebar di seluruh lokasi/langganan/lokal, dan Azure, ada beberapa hal yang perlu dipertimbangkan.

Untuk melihat skenario pencadangan dan pemulihan yang saat ini kami dukung, lihat matriks dukungan. Untuk pertanyaan umum, lihat pertanyaan yang sering diajukan.

Perilaku preferensi cadangan berdasarkan versi SQL Server

Dukungan pencadangan penuh dan diferensial pada replika sekunder tergantung pada versi SQL Server. Preferensi pencadangan AG dan versi SQL Server menentukan simpul yang dipilih untuk setiap jenis cadangan.

SQL Server 2022 dan yang lebih lama

Preferensi pencadangan yang digunakan oleh Azure Backup SQL AG mendukung pencadangan penuh dan diferensial hanya dari replika utama. Jadi, pekerjaan pencadangan ini selalu dijalankan di simpul utama terlepas dari preferensi pencadangan yang digunakan. Untuk pencadangan penuh hanya salin dan log transaksi, preferensi pencadangan AG akan dipertimbangkan saat memutuskan node tempat pencadangan akan dijalankan.

SQL Server 2025 dan yang lebih baru

Pada SQL Server 2025 dan yang lebih baru, replika sekunder juga mendukung pencadangan penuh dan diferensial. Preferensi cadangan sekarang mengatur kedua jenis cadangan secara seragam. Saat Anda menetapkan Hanya Sekunder atau Utamakan Sekunder, pencadangan penuh dan diferensial tidak lagi memerlukan simpul utama.

Saat Anda mendaftarkan simpul dengan layanan Azure Backup, Anda menginstal ekstensi cadangan beban kerja pada simpul tersebut. Saat Anda mengonfigurasi database AG untuk pencadangan, jadwal pencadangan diterapkan ke semua simpul AG yang terdaftar. Jadwal diaktifkan pada semua node AG, dan ekstensi cadangan beban kerja pada simpul ini disinkronkan antara mereka sendiri untuk memutuskan simpul mana yang dapat melakukan pencadangan. Pilihan simpul tergantung pada jenis cadangan dan preferensi cadangan yang dijelaskan dalam Perilaku preferensi Cadangan berdasarkan versi SQL Server.

Node yang dipilih akan melanjutkan tugas pencadangan, sedangkan tugas yang dipicu di node lain membatalkan, yaitu melewatkan tugas.

Mendaftarkan node AG ke penyimpanan Layanan Pemulihan

Vault Layanan Pemulihan mendukung pencadangan database hanya dari VM yang berada di wilayah dan langganan yang sama dengan vault.

SQL Server 2022 dan yang lebih lama:

• Daftarkan node utama ke vault (jika tidak dilakukan, pencadangan penuh tidak akan dapat dilakukan).
• Daftarkan setidaknya satu node sekunder ke vault (jika tidak, pencadangan penuh log atau hanya salin tidak dapat dilakukan) jika preferensi hanya sekunder.

Mengonfigurasi cadangan untuk database AG gagal dengan kode kesalahan FabricSvcBackupPreferenceCheckFailedUserError jika kondisi di atas tidak terpenuhi.

SQL Server 2025 dan yang lebih baru:

• Pendaftaran simpul utama tidak lagi wajib untuk konfigurasi cadangan AG. Karena pencadangan penuh dan diferensial sekarang dapat berjalan pada replika sekunder, Anda dapat mengonfigurasi cadangan hanya dengan simpul sekunder yang terdaftar (ketika preferensi cadangan hanya sekunder atau Pilih Sekunder).
• Untuk preferensi pencadangan Primary, simpul utama harus tetap terdaftar.
• Daftarkan setidaknya satu simpul yang memenuhi preferensi cadangan yang dipilih.

Mari kita jadikan penyebaran AG berikut ini sebagai acuan.

Berdasarkan contoh penyebaran AG yang diberikan, berikut adalah berbagai pertimbangan:

• Karena simpul utama berada di Wilayah 1 dan Langganan 1, brankas Layanan Pemulihan (Brankas 1) harus berada di Wilayah 1 dan Langganan 1 untuk melindungi AG ini.
• VM3 tidak dapat didaftarkan ke Vault 1 karena berada dalam langganan yang berbeda.
• VM4 tidak dapat didaftarkan ke Vault 1 karena berada di wilayah yang berbeda.
• Jika preferensi cadangan hanya sekunder, daftarkan VM1 (Primer) dan VM2 (Sekunder) ke Vault 1. Pada SQL Server 2022 dan yang lebih lama, pencadangan penuh memerlukan node utama sehingga daftarkan kedua node; pada SQL Server 2025 dan yang lebih baru, VM2 saja sudah cukup. Untuk preferensi pencadangan lainnya, daftarkan VM1 (Primer) ke Vault 1; VM2 bersifat opsional.
• Meskipun Anda dapat mendaftarkan VM3 ke vault 2 di langganan 2 dan database AG tersebut kemudian akan muncul untuk perlindungan di vault 2, konfigurasi cadangan akan gagal pada SQL Server 2022 dan versi sebelumnya karena tidak adanya node utama di vault 2. Pada SQL Server 2025 dan yang lebih baru, Anda dapat mengonfigurasi cadangan di vault 2 jika preferensi cadangan hanya sekunder atau Lebih Suka Sekunder.
• Demikian pula, meskipun Anda dapat mendaftarkan VM4 ke vault 4 di wilayah 2, mengonfigurasi cadangan akan gagal pada SQL Server 2022 dan yang lebih lama karena node utama tidak terdaftar di vault 4. Pada SQL Server 2025 dan yang lebih baru, Anda dapat mengonfigurasi cadangan di vault 4 jika preferensi cadangan hanya sekunder atau Lebih Suka Sekunder.

Menangani proses failover

Setelah AG melakukan failover ke salah satu simpul sekunder:

• SQL Server 2022 dan versi sebelumnya: Pencadangan penuh dan diferensial dilanjutkan dari simpul utama baru jika terdaftar di vault.
• SQL Server 2025 dan versi yang lebih baru: Pencadangan penuh dan diferensial dilanjutkan dari simpul yang memenuhi preferensi pencadangan. Untuk Sekunder Saja atau Lebih Suka Sekunder, cadangan ini dapat berjalan pada replika sekunder.
• Pencadangan log dan penuh hanya-salin akan dilanjutkan dari node primer/sekunder sesuai preferensi pencadangan.

Berdasarkan contoh penyebaran AG di atas, berikut adalah berbagai kemungkinan failover:

• Pengalihan otomatis ke VM2
  • Pencadangan penuh dan diferensial akan dilakukan dari VM2.
  • Pencadangan penuh log dan hanya salin akan dilakukan dari VM1 atau VM2 sesuai preferensi pencadangan.
• Pengalihan ke VM3 (langganan yang berbeda)
  • Karena pencadangan tidak dikonfigurasi di Brankas 2, pencadangan tidak akan dilakukan.
  • Pada SQL Server 2022 dan yang lebih lama, jika preferensi cadangan tidak hanya sekunder, Anda sekarang dapat mengonfigurasi cadangan di Vault 2 karena simpul utama terdaftar di vault ini. Pada SQL Server 2025 dan yang lebih baru, Anda juga dapat mengonfigurasi cadangan ketika simpul terdaftar di Vault 2 memenuhi preferensi cadangan yang dipilih. Kondisi ini dapat menyebabkan konflik atau kegagalan pencadangan. Untuk informasi selengkapnya, lihat Mengonfigurasi cadangan untuk AG multi-wilayah.
• Alih fungsi ke VM4 (wilayah lain)
  • Karena pencadangan tidak dikonfigurasi di Brankas 4, maka tidak ada pencadangan yang akan dilakukan.
  • Pada SQL Server 2022 dan yang lebih lama, jika preferensi cadangan tidak hanya sekunder, Anda sekarang dapat mengonfigurasi cadangan di Vault 4 karena simpul utama terdaftar di vault ini. Pada SQL Server 2025 dan yang lebih baru, Anda juga dapat mengonfigurasi cadangan ketika simpul terdaftar di Vault 4 memenuhi preferensi cadangan yang dipilih. Kondisi ini dapat menyebabkan konflik atau kegagalan pencadangan. Untuk informasi selengkapnya, lihat Mengonfigurasi cadangan untuk AG multi-wilayah.

Mengonfigurasi cadangan untuk AG multi-wilayah

Brankas layanan pemulihan tidak mendukung pencadangan lintas langganan atau lintas wilayah. Bagian ini merangkum cara mengaktifkan backup untuk AG yang mencakup beberapa langganan atau wilayah Azure serta pertimbangan-pertimbangan yang terkait.

• Evaluasi apakah Anda benar-benar perlu memungkinkan pencadangan dari semua node. Jika suatu wilayah atau langganan mencakup sebagian besar node AG dan failover ke node lain sangat jarang terjadi, menyiapkan pencadangan di kawasan pertama tersebut mungkin sudah cukup. Jika failover ke wilayah/langganan lain sering terjadi dan untuk durasi yang lama, maka Anda mungkin juga ingin menyiapkan cadangan secara proaktif di wilayah lain.

• Setiap brankas yang mengaktifkan pencadangan akan memiliki rangkaian rantai titik pemulihannya sendiri. Pemulihan data dari titik pemulihan ini hanya dapat dilakukan untuk VM yang terdaftar di brankas yang sama.

• SQL Server 2022 dan yang lebih lama: Pencadangan penuh dan diferensial hanya berfungsi di vault yang memiliki simpul utama. Cadangan ini di vault lain terus gagal. Di SQL Server 2025 dan versi yang lebih baru, perilaku ini berubah untuk preferensi Sekunder Saja dan Utamakan Sekunder - lihat SQL Server 2025: Perubahan pencadangan AG multiwilayah.

• Pencadangan log akan terus bekerja di vault sebelumnya hingga cadangan log berjalan di vault baru (yaitu, di vault tempat simpul utama baru ada) dan memutus rantai log untuk vault lama.

  Catatan

  Ada batas tegas 15 hari, setelah itu pencadangan log akan mulai gagal.

• Pencadangan penuh hanya salin dapat digunakan di semua brankas.

• Perlindungan pada setiap brankas dianggap sebagai sumber data yang unik dan ditagihkan secara terpisah.

Untuk mencegah konflik pencadangan log antara dua brankas, sebaiknya atur preferensi pencadangan ke Primer. Kemudian, brankas yang memiliki simpul induk juga akan melakukan pencadangan log.

SQL Server 2025: Perubahan cadangan AG multi-wilayah

Dengan SQL Server 2025, pencadangan penuh dan diferensial tidak lagi memerlukan simpul utama. Perubahan ini berarti:

• Pendaftaran simpul utama tidak diperlukan — Jika preferensi cadangan Anda Hanya Sekunder atau Pilih Sekunder, Anda dapat mengonfigurasi dan menjalankan cadangan dari simpul sekunder terdaftar, bahkan jika simpul utama berada di wilayah atau langganan yang berbeda.

• Mengurangi dampak failover — Setelah failover ke node di wilayah yang berbeda, pencadangan dapat dilanjutkan di vault asli selama node terdaftar yang memenuhi preferensi cadangan tersedia.

Namun, batasan koordinasi lintas vault mendasar tetap ada — cadangan tidak dapat dikoordinasikan antara beberapa vault. Jika Anda mendaftarkan simpul AG pada vault yang berbeda di berbagai wilayah, jadwal pencadangan yang berjalan secara bersamaan dapat saling bertabrakan dan menyebabkan terputusnya rantai log atau pencadangan duplikat.

Rekomendasi untuk menghindari konflik antarbrankas:

• AG 2-node: Atur preferensi cadangan ke Hanya Sekunder atau Primer.
• 3+ node AG: Atur preferensi cadangan ke Primary.

Konfigurasi ini memastikan bahwa hanya satu node milik vault yang dapat digunakan untuk pencadangan pada satu waktu.

Berdasarkan penyebaran AG contoh di atas, berikut ini adalah langkah-langkah untuk mengaktifkan cadangan dari setiap node. Asumsi adalah bahwa preferensi pencadangan terpenuhi pada setiap langkah.

Langkah 1: Aktifkan pencadangan di Wilayah 1, Langganan 1 (Vault 1)

Karena simpul utama berada di wilayah dan langganan, langkah-langkah standar untuk mengaktifkan pencadangan dapat digunakan.

Langkah 2: Aktifkan cadangan di Wilayah 1, Langganan 2 (Brankas 2)

1. Pindahkan AG ke VM3 agar simpul utama tersedia di Vault 2.
2. Konfigurasikan pencadangan untuk database AG di Brankas 2.
3. Pada titik ini:
   1. Pencadangan diferensial/penuh akan gagal di Vault 1 karena tidak ada node terdaftar yang dapat melakukan pencadangan ini.
   2. Pencadangan log akan berhasil di Vault 1 hingga cadangan log dijalankan di Vault 2 yang memutus rantai log untuk Vault 1.
4. Kembalikan AG ke VM1.

Langkah 3: Aktifkan pencadangan di Region 2, Langganan 1 (Brankas 4)

Sama seperti Langkah 2.

Mencadangkan AG yang mencakup Azure dan lingkungan lokal

Azure Backup for SQL Server tidak dapat dijalankan secara lokal. Jika simpul utama berada di Azure dan preferensi pencadangan dipenuhi oleh simpul di Azure, Anda dapat mengikuti panduan di atas terkait AG multi-wilayah untuk mengaktifkan pencadangan bagi replika di Azure. Jika failover ke simpul lokal terjadi, pencadangan penuh dan diferensial di Azure akan mulai gagal. Pencadangan log dapat berlanjut hingga pemutusan rantai log terjadi/15 hari berlalu.

Pembatasan untuk pekerjaan pencadangan dalam database AG

Saat ini, pembatasan pencadangan berlaku pada tingkat mesin individu. Batas default adalah 20 – jika lebih dari 20 pencadangan dipicu secara bersamaan, 20 pencadangan pertama akan berjalan sedangkan yang lainnya akan mengantre. Ketika pekerjaan yang berjalan sudah selesai, pekerjaan yang mengantre akan mulai dikerjakan.

Anda dapat mengubah nilai ini ke nilai yang lebih kecil jika pencadangan simultan menyebabkan tekanan pada memori/IO/CPU di simpul. Karena pembatasan berada pada tingkat simpul, memiliki simpul AG yang tidak seimbang dapat menyebabkan masalah sinkronisasi cadangan. Untuk memahaminya, pertimbangkan AG dengan 2 node sebagai contoh.

Misalnya, simpul pertama memiliki 50 database mandiri yang dilindungi dan kedua simpul memiliki 5 database AG yang dilindungi. Secara efektif, Simpul 1 memiliki 55 pekerjaan pencadangan database terjadwal sedangkan Simpul 2 hanya memiliki 5. Selain itu, semua pencadangan ini dikonfigurasi agar berjalan pada saat yang sama, setiap jam. Pada suatu titik, semua 55 pencadangan tersebut akan terpicu pada Simpul 1 dan 35 di antaranya akan mengantre. Beberapa di antaranya adalah cadangan basis data AG. Tetapi pada Simpul 2, pencadangan database AG akan terus berlanjut tanpa antrean.

Karena pekerjaan basis data AG diantrekan pada satu simpul dan dijalankan pada simpul lain, sinkronisasi pencadangan tidak berfungsi dengan baik. Node 2 mungkin mengasumsikan bahwa Node 1 tidak berfungsi dan oleh karena itu pekerjaan dari Node 1 tidak muncul untuk sinkronisasi. Masalah ini dapat menyebabkan pemutusan rantai log atau cadangan tambahan karena kedua simpul dapat mengambil cadangan secara independen.

Masalah yang mirip dapat terjadi jika jumlah database AG yang dilindungi melampaui pembatasan. Dalam kasus tersebut, pencadangan untuk, misalnya, DB1 dapat mengantre di Node 1 sementara berjalan di Node 2.

Sebaiknya gunakan preferensi pencadangan berikut untuk mencegah masalah sinkronisasi ini:

• Untuk AG 2 simpul, atur Preferensi Pencadangan ke Primer atau Sekunder Saja, agar hanya satu simpul yang dapat melakukan pencadangan, yang lain akan selalu berhenti.
• Untuk AG dengan lebih dari 2 simpul, atur Preferensi Pencadangan ke Primer, agar hanya simpul utama yang dapat melakukan pencadangan, yang lain akan berhenti.

Tagihan untuk pencadangan AG

Sama seperti instans SQL server mandiri, satu instans AG yang dicadangkan dianggap sebagai satu instans yang dilindungi. Ukuran total frontend dari semua database yang dilindungi pada suatu instans dibebankan. Pertimbangkan penyebaran berikut:

Instans yang dilindungi dihitung sebagai berikut:

Memindahkan database yang dilindungi ke dalam atau ke luar AG

Azure Backup mempertimbangkan instans SQL atau nama AG\Nama database sebagai nama unik database. Ketika DB mandiri dilindungi, nama uniknya adalah StandAloneInstanceName\DBName. Saat berpindah di bawah AG, nama unik berubah menjadi AGName\DBName. Cadangan untuk database mandiri akan mulai gagal dengan kode kesalahan: UserErrorBackupFailedStandaloneDatabaseMovedInToAG.

Database harus dikonfigurasi untuk perlindungan dari bawah AG. Langkah ini akan dianggap sebagai sumber data baru dengan rantai titik pemulihan terpisah. Perlindungan yang lebih lama dari database mandiri dapat dihentikan dengan menyimpan data untuk mencegah pencadangan berikutnya terpicu atau gagal. Demikian pula, ketika database AG yang dilindungi bergerak keluar dari AG dan menjadi database mandiri, cadangannya mulai gagal dengan kode kesalahan: UserErrorBackupFailedDatabaseMovedOutOfAG.

Database harus dikonfigurasi untuk perlindungan dari bawah instans mandiri. Langkah ini akan dianggap sebagai sumber data baru dengan rantai titik pemulihan terpisah. Perlindungan yang lebih lama dari database AG dapat dihentikan dengan mempertahankan data untuk mencegah pencadangan berikutnya terpicu atau gagal.

Penambahan atau penghapusan node ke/dari AG

Ketika simpul baru ditambahkan ke AG yang dikonfigurasi untuk pencadangan, ekstensi pencadangan beban kerja yang berjalan pada simpul AG yang sudah terdaftar mendeteksi perubahan topologi AG dan menginformasikan layanan Azure Backup selama pekerjaan penemuan database yang terjadwal berikutnya. Ketika simpul baru ini terdaftar untuk pencadangan ke brankas Layanan Pemulihan yang sama dengan simpul lain yang ada, layanan Azure Backup memicu alur kerja yang mengonfigurasi simpul baru ini dengan metadata yang diperlukan untuk melakukan pencadangan AG.

Setelah langkah ini, simpul baru menyinkronkan informasi jadwal pencadangan AG dari layanan Azure Backup dan mulai berpartisipasi dalam proses pencadangan yang disinkronkan. Jika simpul baru tidak dapat menyinkronkan jadwal pencadangan dan berpartisipasi dalam pencadangan, memicu pendaftaran ulang pada node memaksa konfigurasi ulang node untuk cadangan AG juga. Demikian pula, selama penghapusan simpul, ekstensi beban kerja mendeteksi perubahan topologi AG dan menginformasikan layanan Azure Backup. Layanan memulai alur kerja un-configuration pada node yang dihapus untuk menghapus jadwal pencadangan bagi database AG dan menghapus metadata yang terkait dengan AG.

Membatalkan pendaftaran simpul AG dari Azure Backup

Jika nodus merupakan bagian dari Grup Ketersediaan (AG) yang memiliki satu atau beberapa basis data yang dikonfigurasi untuk pencadangan, maka Azure Backup tidak mengizinkan pembatalan pendaftaran nodus tersebut. Ini untuk mencegah kegagalan cadangan di masa depan jika preferensi pencadangan tidak dapat dipenuhi tanpa simpul ini. Untuk membatalkan registrasi simpul, langkah pertama Anda perlu menghapusnya dari AG. Ketika alur kerja un-configuration pada node selesai dan node tersebut sudah dibersihkan, Anda dapat membatalkan pendaftarannya.

Memulihkan database dari Azure Backup ke Grup Ketersediaan AG SQL tidak mendukung pemulihan database secara langsung ke AG. Database perlu dipulihkan ke instans SQL mandiri dan kemudian digabungkan dengan AG.

Skenario pembuatan ulang grup ketersediaan untuk server database SQL

Pembuatan ulang grup Ketersediaan (AG), AG duplikat, dan item cadangan terdaftar sebagai item yang dapat dilindungi atau item yang dilindungi dalam skenario berikut:

• Membuat ulang AG yang sudah dilindungi muncul sebagai AG duplikat pada halaman Konfigurasi Cadangan dan di daftar Item terproteksi . Jika Anda ingin menyimpan data cadangan yang sudah ada di AG yang lebih lama, hentikan pencadangan dengan menggunakan opsi Hentikan perlindungan dan pertahankan data sebelum membuat ulang dan menjadwalkan cadangan pada item AG baru.

  Secara desain, Azure Backup mencantumkan item duplikat pada daftar Item terproteksi, dan halaman Konfigurasi Cadangan atau daftar item yang dapat dilindungi dan menampilkan item ini hingga Anda ingin menyimpan data cadangan.

• Jika Anda tidak ingin data cadangan dari AG yang lebih lama, hentikan operasi pencadangan dengan menggunakan opsi Hentikan perlindungan dan hapus data untuk item lama sebelum membuat ulang dan menjadwalkan cadangan pada AG baru.

  Perhatian

  Menghentikan perlindungan dan menghapus data adalah operasi yang merusak.

• Anda dapat membuat ulang AG setelah melakukan salah satu proses Hentikan perlindungan di atas untuk menghindari kegagalan pencadangan.

Pertimbangan cadangan AG SQL Server 2025

Perubahan preferensi cadangan setelah konfigurasi

Jika Anda mengubah preferensi pencadangan AG tetapi tidak mendaftarkan simpul yang diperlukan ke vault, pencadangan gagal. Misalnya, jika Anda mengubah preferensi dari Primer ke Sekunder Saja tetapi tidak ada simpul sekunder yang terdaftar, pencadangan log dan Penuh/Diff gagal. Selalu pastikan bahwa simpul yang memenuhi preferensi cadangan baru didaftarkan ke vault sebelum melakukan perubahan.

Koordinasi pencadangan AG multiregion

Saat Anda melindungi simpul AG di beberapa brankas yang tersebar di berbagai wilayah, brankas tidak dapat mengoordinasikan pencadangan di antaranya, terlepas dari versi SQL Server. Untuk panduan tentang pengaturan preferensi pencadangan yang mencegah terputusnya rantai log dan pencadangan duplikat dalam skenario ini, lihat SQL Server 2025: perubahan pencadangan AG multiwilayah.

Dukungan pencadangan rekam jepret

Cadangan snapshot tidak didukung pada replika sekunder dari AG. Saat Anda mengaktifkan pencadangan snapshot pada kebijakan pencadangan, pendaftaran node utama tetap wajib terlepas dari versi SQL Server.

Langkah berikutnya

Pelajari cara:

• Memulihkan database SQL Server yang dicadangkan
• Mengelola database SQL Server yang dicadangkan

Konten terkait

• Cadangkan database server SQL di Azure VM menggunakan Azure Backup melalui REST API.
• Pulihkan database SQL Server di Azure VM dengan REST API.
• Mengelola database server SQL di Azure VM dengan portal Microsoft Azure, Azure CLI, REST API.