Pulihkan data cadangan SQL Server - ApsaraDB RDS

Jika Anda memiliki data cadangan untuk instans RDS SQL Server, Anda dapat memulihkan data tersebut ke instans yang ada atau instans baru. Ini berguna untuk skenario seperti pemulihan setelah kesalahan operasi dan analisis data historis.

Catatan

Topik ini berlaku untuk memulihkan semua data ke instans di Wilayah yang sama. Untuk memulihkan data lintas wilayah atau memulihkan file cadangan RDS ke database yang dikelola sendiri, lihat tutorial Ikhtisar Solusi Pemulihan untuk memilih solusi pemulihan yang sesuai.

Batasan

Jika instans telah mengaktifkan fitur pengarsipan data ke OSS, hanya database yang ada dalam set cadangan (database non-terarsip) yang didukung untuk pemulihan. Jika database telah diarsipkan, instans yang dipulihkan tidak akan mencakup database yang terarsip.
Data cadangan dari instans Serverless hanya dapat dipulihkan ke instans Serverless baru dan tidak dapat dipulihkan ke instans yang sudah ada.
Instans RDS SQL Server 2008 R2 (disk lokal performa premium) tidak didukung. Data dari instans ini harus dipulihkan melalui instans sementara.
Setelah TDE diaktifkan, data cadangan yang dihasilkan oleh instans dapat digunakan untuk memulihkan ke instans baru, tetapi memulihkan data cadangan ke instans yang sudah ada tidak didukung.

Pemulihan ke Instans yang Ada

Anda dapat memulihkan cadangan historis dari Instans A ke instans yang ada tertentu (termasuk Instans A) berdasarkan titik waktu atau set cadangan. Ruang lingkup pemulihan mendukung pemilihan beberapa atau semua database.

Aturan Pemulihan

Persyaratan Instans	Deskripsi
Versi Database	Versi database dari instans yang ada harus lebih besar dari atau sama dengan versi database dari instans asli.
Seri Instans	Pemulihan dari seri yang lebih tinggi ke seri yang lebih rendah tidak didukung. Urutan seri dari tinggi ke rendah adalah: Edisi Kluster > Ketersediaan Tinggi > Dasar.
Tipe Instans	Hanya tipe yang sama ke tipe yang sama, Tujuan Umum ke Spesifikasi Khusus, dan Spesifikasi Khusus ke Tujuan Umum yang didukung.

Prosedur

Buka halaman Instans. Di bilah navigasi atas, pilih wilayah tempat instans RDS berada. Kemudian, temukan instans RDS dan klik ID instans tersebut.
Di panel navigasi di sebelah kiri, klik Backup and Restoration, lalu klik Database Restoration.
Di kotak dialog yang muncul, pilih Restore To Existing Instance dan klik OK.

Atur parameter berikut dan klik OK.

Parameter	Deskripsi
Restoration Method	By Backup Set: Anda dapat memulihkan data dalam set cadangan yang dipilih. By Time: Anda dapat menetapkan titik waktu apa pun dalam periode retensi cadangan log. Sistem akan memulihkan data ke titik waktu yang ditentukan berdasarkan cadangan penuh terbaru dan cadangan inkremental (pemulihan cadangan inkremental tertentu tidak didukung). Anda dapat melihat atau memodifikasi periode retensi cadangan log sesuai kebutuhan.
Restoration Time	Parameter ini terlihat ketika Restoration Method disetel ke By Time. Pilih titik waktu untuk data yang ingin Anda salin.
Backup Set	Parameter ini terlihat ketika Restoration Method disetel ke By Backup Set. Pilih set cadangan yang ingin Anda pulihkan.
More Backup Sets	Jika Anda tidak dapat menemukan set cadangan target di Backup Set, Anda dapat memilih opsi ini untuk melanjutkan pencarian.
Target Instance Name	Pilih instans ke mana Anda ingin memulihkan data. Anda dapat memulihkan data ke instans dengan versi yang lebih tinggi. Sistem secara default menampilkan semua instans di wilayah saat ini di bawah Akun Alibaba Cloud saat ini, termasuk instans saat ini. Catatan Cadangan snapshot hanya dapat dipulihkan ke instans yang memiliki cadangan snapshot diaktifkan. Cadangan dari instans bersama tidak dapat dipulihkan ke instans Tujuan Umum atau Spesifikasi Khusus, dan cadangan dari instans Tujuan Umum atau Spesifikasi Khusus tidak dapat dipulihkan ke instans bersama. Jika terlalu banyak instans target yang ditampilkan, Anda dapat menggunakan kotak pencarian untuk menyaringnya.
Databases To Restore	Pilih database yang ingin Anda pulihkan. Anda dapat memulihkan beberapa atau semua database. Sistem secara default menampilkan semua database dalam instans. Tetapkan nama database setelah pemulihan. Sistem menggunakan nama database asli secara default. Perhatikan hal berikut: Nama database setelah pemulihan tidak boleh sama dengan nama database yang sudah ada di instans target. Jika tidak, tugas pemulihan akan menghasilkan kesalahan. Silakan ubah ke nama database unik. Ketika nama database setelah pemulihan berbeda dari nama database yang sudah ada di instans target, sistem akan membuat database baru tanpa menimpa atau memengaruhi data yang ada di instans target. Nama database setelah pemulihan hanya dapat berisi huruf besar dan kecil, angka, garis bawah (_), dan tanda hubung (-).

Lihat kemajuan tugas pemulihan.
Sistem akan menghasilkan tugas pemulihan. Anda dapat mengklik tombol di sudut kanan atas dan menyaring halaman Task List berdasarkan Task Type sebagai Clone Instance untuk melihat kemajuan pemulihan.

Pemulihan ke Instans Baru

Anda dapat memulihkan cadangan historis dari Instans A ke instans baru berdasarkan titik waktu atau set cadangan. Ruang lingkup pemulihan mendukung pemilihan beberapa atau semua database. Untuk waktu yang diperlukan untuk memulihkan ke instans baru, lihat FAQ dalam topik ini.

Informasi Penagihan

Karena data dipulihkan ke instans baru, biaya untuk instans baru akan dikenakan. Anda dapat melihat detail biaya saat membuat instans.

Catatan

Jika Anda tidak lagi memerlukan instans asli setelah pemulihan, Anda dapat melepaskan atau berhenti berlangganan dari instans asli segera.
Penagihan dimulai setelah instans dibuat.

Prosedur

Buka halaman Instans. Di bilah navigasi atas, pilih wilayah tempat instans RDS berada. Kemudian, temukan instans RDS dan klik ID instans tersebut.
Di panel navigasi di sebelah kiri, klik Backup and Restoration, lalu klik Database Restoration.
Di kotak dialog Select Restoration Method, pilih Restore To New Instance dan klik OK.

Di halaman Database Restoration, atur parameter berikut.

Kategori	Deskripsi
Metode Penagihan	Subscription: Ini adalah metode penagihan prabayar yang memerlukan pembayaran saat Anda membuat instans. Cocok untuk kebutuhan jangka panjang dan lebih hemat biaya daripada metode penagihan bayar sesuai pemakaian. Semakin lama periode langganan, semakin tinggi diskonnya. Pay-as-you-go: Ini adalah metode penagihan pascabayar yang mengenakan biaya per jam. Cocok untuk kebutuhan jangka pendek. Anda dapat melepaskan instans segera setelah digunakan untuk mengurangi biaya.
Restoration Method	By Backup Set: Anda dapat memulihkan data dalam set cadangan yang dipilih. By Time: Anda dapat menetapkan titik waktu apa pun dalam periode retensi cadangan log. Sistem akan memulihkan data ke titik waktu yang ditentukan berdasarkan cadangan penuh terbaru dan cadangan inkremental (pemulihan cadangan inkremental tertentu tidak didukung). Anda dapat melihat atau memodifikasi periode retensi cadangan log sesuai kebutuhan.
Database	Anda dapat memulihkan semua atau beberapa database. Jika Anda memilih Partial, Anda perlu memasukkan nama database secara manual, dipisahkan dengan koma (,). Catatan Jika instans telah mengaktifkan cadangan snapshot, hanya All database yang dapat dipulihkan, dan pemulihan Partial database tidak didukung.
Edition	Wilayah dan versi database yang berbeda mendukung edisi yang berbeda. Silakan merujuk ke antarmuka aktual.
Storage Type	Pilih SSD Perusahaan (ESSD) atau disk performa premium. Untuk informasi lebih lanjut, lihat Pengenalan Tipe Penyimpanan.
Primary Node Zone	Pilih zona tempat node utama instans berada. Catatan Edisi Dasar hanya mencakup satu node, sehingga hanya ada satu zona.
Deployment Method	Multi-zone Deployment (direkomendasikan): Node utama dan node sekunder berada di zona berbeda dalam wilayah yang sama, memberikan pemulihan bencana lintas zona. Single-zone Deployment: Node utama dan node sekunder berada di zona yang sama. Catatan Tidak ada perbedaan substansial antara zona berbeda dalam wilayah yang sama. Kinerja ECS mengakses RDS di zona yang sama lebih baik daripada mengakses RDS di zona lain dari wilayah yang sama, tetapi perbedaannya kecil. Ketika Anda memilih Basic Edition, hanya Single-zone Deployment yang didukung. Jika pojok kanan atas zona target menampilkan Sold Out, silakan ganti ke zona lain. Parameter ini tidak didukung untuk Edisi Dasar.
Secondary Node Zone	Jika Deployment Method disetel ke Multi-zone Deployment, Anda perlu memilih zona tempat node sekunder instans berada. Catatan Edisi Dasar hanya mencakup satu node, sehingga tidak ada zona node sekunder.
Instance Type	Wilayah dan versi database yang berbeda mendukung tipe instans yang berbeda. Silakan merujuk ke antarmuka aktual.
Storage Capacity	Kapasitas penyimpanan instans baru harus lebih besar dari atau sama dengan instans asli. Anda dapat melihat kapasitas penyimpanan instans asli di halaman Basic Information halaman detail instans RDS. Kapasitas penyimpanan mencakup ruang data, ruang file sistem, ruang file log, dan ruang file transaksi.

Klik Next: Instance Configuration dan atur parameter berikut.

Kategori	Deskripsi
Network Type	Saat ini, hanya virtual private cloud (VPC) yang didukung. Anda dapat membuat VPC dan vSwitch sesuai kebutuhan. Catatan Pastikan bahwa instans RDS dan instans ECS yang ingin Anda hubungkan berada dalam VPC yang sama. Jika tidak, instans RDS dan instans ECS tidak dapat berkomunikasi melalui jaringan internal.
Resource Group	Kelompok sumber daya tempat instans tersebut termasuk. Anda dapat membuat kelompok sumber daya sesuai kebutuhan.

Klik Next: Confirm Order.
Konfirmasi Parameter Configuration, pilih Quantity dan Duration (hanya untuk instans langganan), klik Confirm Order, dan selesaikan pembayaran.
Anda dapat pergi ke daftar instans dan menemukan instans baru yang dibuat berdasarkan waktu pembuatan. Pembuatan instans memakan waktu sekitar 1 hingga 10 menit. Silakan segarkan halaman untuk memeriksa.
Anda dapat terhubung ke instans SQL Server baru dan memeriksa database serta tabel yang telah dipulihkan.

Operasi Terkait

Anda juga dapat memulihkan data menggunakan API (RecoveryDBInstance).

FAQ

Berapa lama waktu yang diperlukan untuk memulihkan data ke instans baru?

Perkiraan Waktu

Secara umum, rentang waktu perkiraan untuk memulihkan data ke instans baru adalah sebagai berikut. Perhatikan bahwa kecepatan cadangan dan pemulihan di bawah ini didasarkan pada ukuran data yang tidak dikompresi.

Catatan

Karena versi Web dari instans tidak mendukung kompresi cadangan, efisiensi cadangan akan terpengaruh, dan kecepatan cadangan serta pemulihan mungkin berkurang menjadi di bawah 100 GB/jam.

Operasi	Diperlukan	Perkiraan Waktu	Catatan
Membuat dan mengonfigurasi instans baru	Diperlukan	10-15 menit	Waktu yang diperlukan tergantung pada edisi dan tipe instans yang dipilih saat memulihkan ke instans baru.
Melakukan cadangan penuh instans	Tidak Diperlukan	200 GB/jam	Karena kecepatan pemulihan log transaksi jauh lebih rendah daripada kecepatan pemulihan data dari cadangan penuh, untuk memastikan efisiensi pemulihan data terbaik, jika instans belum melakukan cadangan penuh dalam 36 jam, instans akan melakukan cadangan penuh selama proses peningkatan untuk menemukan keseimbangan antara mempercepat pemulihan dan menambahkan cadangan penuh tambahan. Disarankan untuk melakukan cadangan penuh secara manual pada waktu yang tepat sebelum pemulihan, atau memulai tugas pemulihan dalam waktu 36 jam setelah cadangan penuh otomatis sistem selesai, untuk mengurangi total waktu yang diperlukan untuk proses pemulihan. Kecepatan cadangan mungkin berbeda tergantung pada wilayah dan periode waktu. Untuk performa cadangan dan pemulihan yang lebih akurat, lihat volume data dan waktu cadangan dari cadangan penuh terbaru.
Memulihkan cadangan penuh ke instans target	Diperlukan	200 GB/jam	Tidak ada
Melakukan cadangan log transaksi inkremental pada instans sumber	Diperlukan	200 GB/jam	Mungkin ada overhead tambahan 2 menit sebelum dan sesudah cadangan log inkremental (seperti persiapan cadangan, penyelesaian, alokasi sumber daya, dll.).
Menerapkan cadangan log transaksi inkremental ke instans target	Diperlukan	200 GB/jam	Mungkin ada overhead tambahan 2 menit sebelum dan sesudah menerapkan cadangan log inkremental (seperti verifikasi konsistensi cadangan, dll.).
Mengaktifkan database	Diperlukan	Biasanya dalam 2 menit	Konsumsi sumber daya: Menerapkan log transaksi inkremental adalah operasi yang intensif sumber daya. Tipe instans kecil (seperti 2 core, 4 GB) mungkin mengalami penurunan kecepatan pemulihan karena banyaknya log transaksi. Opsi percepatan pemulihan database: RDS SQL Server 2019 dan versi yang lebih tinggi menyediakan opsi Accelerated Database Recovery, yang dapat mengurangi waktu yang diperlukan untuk langkah pemulihan database online. Silakan merujuk ke dokumentasi Microsoft resmi untuk mengevaluasi secara menyeluruh apakah akan mengaktifkan opsi ini.

Contoh Estimasi

Instans uji: Tipe instans adalah 4 core 8 GB, ukuran data adalah 600 GB.

Membuat dan mengonfigurasi instans baru: Perkiraan waktu adalah 12 menit.
Cadangan penuh (tidak diperlukan): Perkiraan waktu adalah 3 jam. (600 GB / 200 GB per jam)
Memulihkan cadangan penuh ke instans target: Perkiraan waktu adalah 3 jam. (600 GB / 200 GB per jam)
Melakukan cadangan log transaksi inkremental pada instans sumber: Perkiraan waktu adalah 5 menit. (10 GB / 200 GB per jam) + 2 menit overhead tambahan = 5 menit
Menerapkan cadangan log transaksi inkremental ke instans target: Perkiraan waktu adalah 5 menit. (10 GB / 200 GB per jam) + 2 menit overhead tambahan = 5 menit
Mengaktifkan database: Perkiraan waktu adalah dalam 2 menit.

Secara keseluruhan, dalam contoh ini, jika instans belum melakukan cadangan penuh dalam 36 jam, total perkiraan waktu adalah sekitar 6 jam dan 24 menit. Jika tidak, dibutuhkan sekitar 3 jam dan 24 menit.

Rekomendasi Pemulihan

Perencanaan jendela pemeliharaan: Disarankan untuk melakukan operasi pemulihan selama periode beban sistem rendah untuk meminimalkan dampak pada bisnis.
Masalah transaksi jangka panjang: Selama proses pemulihan, hindari menjalankan operasi transaksi jangka panjang, seperti membuat atau membangun ulang indeks, pengarsipan data, dll., untuk menghindari memperpanjang waktu langkah pemulihan database online.