Cloud Backup：FAQ untuk Cadangan Basis Data

Masalah instans database

• Apa yang harus saya lakukan jika pendaftaran instans untuk Database Backup gagal?

• Apa yang harus saya lakukan jika status instans database adalah "Inactivated"?

• Apa yang harus saya lakukan jika status instans database adalah "DB Offline"?

• Mengapa beberapa instans database muncul di tab ECS Database Instance setelah saya mendaftarkan sebuah instans?

• Apa yang harus saya lakukan jika status database tidak dapat diambil setelah pendaftaran instans?

Masalah klien

• Bagaimana cara memeriksa status proses klien, menemukan path log, dan merestart klien?

• Apa yang harus saya lakukan jika status klien database adalah "Offline"?

• Apa yang harus saya lakukan jika terjadi error "Failed to run install script:exit status 4" saat menginstal klien backup untuk SQL Server lokal?

• Apa yang harus saya lakukan jika klien backup gagal diinstal untuk SQL Server lokal?

• Apa yang harus saya lakukan jika klien Database Backup gagal diinstal pada instans ECS?

Masalah pencadangan

• Bagaimana cara mendapatkan uji coba gratis untuk pencadangan database lokal?

• Apa saja persyaratan jaringan untuk pencadangan database lokal?

• Berapa interval minimum untuk cadangan waktu nyata? Apakah dapat dikonfigurasi dengan cadangan inkremental?

• Bagaimana cara mengubah username dan password untuk cadangan database?

• Apa yang harus saya lakukan jika pencadangan database gagal?

• Apa yang harus saya lakukan jika waktu yang dibutuhkan untuk cadangan inkremental data Oracle sama dengan atau lebih besar dari waktu untuk cadangan penuh?

• RMAN melaporkan error non-fatal selama cadangan inkremental Oracle

• Apa yang harus saya lakukan jika penjelajahan detail database gagal saat mencadangkan SQL Server 2019?

• Apa yang harus dilakukan jika alamat IP untuk database SQL Server lokal salah di konsol Cloud Backup

• Dapatkah saya mencadangkan database SQL Server ke Alibaba Cloud setelah mengaktifkan Transparent Data Encryption (TDE)?

• Apa yang harus saya lakukan jika klien offline, tidak dapat di-uninstall, dan kebijakan anti-ransomware gagal dihapus setelah saya menerapkan layanan anti-ransomware untuk database SQL Server?

• Apa yang harus saya lakukan jika tidak dapat menginstal atau menggunakan fitur Database Backup setelah mentransfer instans ECS dari Akun Alibaba Cloud asal ke akun baru?

• Apakah ada batasan pada versi database MySQL dan sistem operasi yang didukung untuk pencadangan?

• Bagaimana cara mencadangkan database yang baru dibuat di MySQL?

• Bagaimana cara membatalkan pencadangan database?

• Mengapa ada catatan duplikat atau waktu yang tidak sesuai dalam riwayat pencadangan?

• Mengapa pencadangan gagal dan status rencana pencadangan menunjukkan "Error"?

• Mengapa waktu peringatan berbeda dari waktu error sebenarnya?

• Mengapa saya menerima email atau pesan teks peringatan kegagalan, tetapi riwayat pencadangan menunjukkan catatan pencadangan berhasil dan gagal secara bersamaan?

Masalah pemulihan

• Apa itu fitur "View Offline Instances Only"?

• Apa yang harus saya lakukan jika pemulihan database SQL Server gagal?

• Apa yang harus saya lakukan jika pemulihan SQL Server gagal dan log agen menunjukkan error inisialisasi file?

• Bagaimana cara melakukan pemulihan lintas database antara database lokal dan database ECS?

Masalah penyimpanan cadangan

• Apa itu penyimpanan cadangan database?

• Bagaimana penyimpanan cadangan database melakukan purge data kedaluwarsa?

• Bagaimana cara melihat ukuran data cadangan dan penggunaan penyimpanan cadangan? Apa dasar penagihannya?

Apa yang harus saya lakukan jika pendaftaran instans untuk Database Backup gagal?

Pertama, pastikan klien Database Backup telah diinstal pada server (server lokal atau instans ECS). Jika sudah, lihat Uninstall the client untuk meng-uninstall klien dan membersihkan file konfigurasinya. Kemudian, coba daftarkan kembali instans tersebut.

Apa yang harus saya lakukan jika status instans database adalah "Inactivated"?

Apa yang harus saya lakukan jika status instans database adalah "Database Offline"?

Mengapa beberapa instans database muncul di tab ECS Database Instance setelah saya mendaftarkan sebuah instans?

Jika beberapa instans database diterapkan pada satu instans ECS, konsol Cloud Backup memindai dan menampilkan semuanya selama pendaftaran.

Apa yang harus saya lakukan jika status database tidak dapat diperoleh setelah pendaftaran instans?

• Gejala

  Setelah Anda mendaftarkan instans database, konsol Cloud Backup tidak dapat mengambil status database.

• Penyebab

  Sistem operasi tidak didukung oleh database.

• Solusi

  Beralihlah ke sistem operasi yang didukung dan coba lagi.

Cara memeriksa status proses klien, menemukan path log, dan merestart klien

• Linux

  1. Periksa status proses klien backup.

     Jalankan perintah systemctl status dbackup3-agent atau service dbackup3-agent status untuk memeriksa status proses klien Database Backup.

     Status active atau dbackup3-agent is running... menunjukkan bahwa klien berjalan dengan baik.

     ● dbackup3-agent.service - dbackup3 agent daemon
        Loaded: loaded (/usr/lib/systemd/system/dbackup3-agent.service; enabled; vendor preset: disabled)
        Active: active (running) since Mon 2023-12-11 13:47:34 CST; 1min 13s ago
      Main PID: 22192 (dbackup3-agent)
        CGroup: /system.slice/dbackup3-agent.service
                └─22192 /opt/scutech/dbackup3/bin/dbackup3-agent -f /etc/opt/scutech/dbackup3/agent/svc.conf.d
     
     Dec 11 13:47:34 iZbp1******gktZ systemd[1]: Started dbackup3 agent daemon.

  2. Restart klien backup.

     Jalankan perintah systemctl restart dbackup3-agent atau service dbackup3-agent restart untuk merestart proses klien. Status klien kembali normal ketika Client Status untuk database di konsol adalah Installed.

     

  Path log klien adalah: /var/log/dbackup3/agent.log

• Windows

  1. Tekan Win + R untuk membuka kotak dialog Run.

  2. Masukkan services.msc dan tekan Enter untuk membuka antarmuka Services.

  3. Dalam daftar layanan, temukan layanan dbackup3-agent.

  4. Periksa apakah status layanan adalah "Running". Jika tidak, klik kanan layanan dbackup3-agent dan pilih "Restart" untuk menjalankannya.

  Path log klien adalah: C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log

Apa yang harus saya lakukan jika status klien database adalah "Offline"?

• Gejala

  Client Status database adalah Offline.

  

• Penyebab

  Status "Offline" menunjukkan bahwa Cloud Backup belum menerima sinyal heartbeat dari proses klien. Hal ini dapat terjadi karena beberapa alasan, seperti klien berhenti otomatis akibat error kehabisan memori, atau perangkat tempat klien berada dimatikan.

• Solusi

  Ikuti petunjuk di Cara melihat status proses klien, path log, dan merestart klien untuk memeriksa dan merestart klien. Setelah status klien berubah menjadi Running, tunggu hingga Client Status database di konsol ditampilkan sebagai Installed. Ini menunjukkan bahwa klien telah kembali normal.

Apa yang harus saya lakukan jika terjadi error "Failed to run install script:exit status 4" saat menginstal klien backup untuk SQL Server lokal?

Error ini terjadi karena pengaturan kebijakan keamanan lokal "Admin Approval Mode for the Built-in Administrator account" tidak diaktifkan. Kebijakan ini harus diatur ke Enabled.

1. Tekan Win+R untuk membuka kotak dialog Run, masukkan gpedit.msc, lalu jalankan Local Group Policy Editor.

2. Di panel Local Group Policy Editor, navigasikan ke Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. Di panel kanan, temukan User Account Control: Admin Approval Mode for the Built-in Administrator account dan ubah statusnya menjadi Enabled.

Apa yang harus saya lakukan jika klien backup gagal diinstal untuk SQL Server lokal?

1. Login ke server dan lihat log backup.

   Path log klien Windows: C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log

2. Di log, periksa entri sekitar waktu tugas gagal.

   Jika log backup berisi pesan error Failed to install dbackup3-agent service, errno=1783, The stub received bad data, sistem mungkin telah menolak instalasi. Periksa apakah ada perangkat lunak antivirus atau keamanan yang memblokir instalasi dan tinjau catatan pemblokiran tersebut. Tambahkan program instalasi ke daftar putih atau nonaktifkan sementara perangkat lunak keamanan sebelum mencoba menginstalnya lagi.

Apa yang harus saya lakukan jika klien Database Backup gagal diinstal pada instans ECS?

Periksa dua hal berikut untuk memastikan klien dapat diinstal dengan sukses:

1. Status Cloud Assistant: Pastikan Cloud Assistant diinstal dengan benar dan sedang berjalan.

   Jika instalasi gagal, temukan catatan perintah yang gagal di Konsol Cloud Assistant. Salin perintah tersebut dan jalankan secara manual di host ECS. Selama instalasi manual, jika terjadi masalah konektivitas jaringan atau error eksekusi skrip sistem, pesan error spesifik akan muncul di layar. Gunakan pesan-pesan tersebut untuk menyelesaikan masalah, misalnya dengan menyesuaikan pengaturan jaringan.

   Setelah semua masalah diselesaikan dan skrip berjalan sukses, klien akan terinstal. Kemudian, picu instalasi lagi di konsol untuk menyelesaikan proses.

2. Ruang disk C: Pastikan ada cukup ruang kosong di drive C. Ruang yang tidak mencukupi dapat mencegah instalasi klien.

Bagaimana cara mendapatkan uji coba gratis untuk pencadangan database lokal?

Uji coba gratis untuk pencadangan database lokal sama dengan uji coba gratis untuk pencadangan database ECS. Untuk informasi lebih lanjut tentang uji coba gratis, lihat Uji Coba Gratis 30 Hari.

Apa saja persyaratan jaringan untuk pencadangan database lokal?

Server database lokal harus terhubung ke virtual private cloud (VPC) Alibaba Cloud melalui jalur sewa atau VPN. Routing harus dikonfigurasi dari on-premises ke cloud pada 100.64.0.0/10 atau 100.64.0.0/11, 100.96.0.0/11.

Berapa interval minimum untuk cadangan waktu nyata? Dapatkah dikonfigurasi dengan cadangan inkremental?

Cadangan waktu nyata secara teoretis dapat mencapai tujuan titik pemulihan (RPO) dalam hitungan detik dan saat ini mendukung database MySQL dan Oracle. Setelah Anda mengaktifkan cadangan waktu nyata, Anda tidak dapat mengonfigurasi cadangan log tradisional yang terpisah. Namun, Anda masih dapat menggunakannya bersama dengan cadangan inkremental untuk lebih meningkatkan kebijakan perlindungan data Anda.

Bagaimana cara mengubah username dan password untuk cadangan database?

Selama proses pencadangan, gunakan Reactivate untuk mengubah username dan password pencadangan Anda, misalnya jika password kedaluwarsa. Reaktivasi tidak memengaruhi rencana pencadangan yang ada. Namun, ini memengaruhi pekerjaan pencadangan yang sedang berlangsung. Kami merekomendasikan langkah-langkah berikut:

1. Di tab Backup Plans, jeda semua pencadangan log waktu nyata.

2. Di kolom Actions untuk database, pilih More > Reactivate.

Apa yang harus saya lakukan jika pencadangan database gagal?

Apa yang harus saya lakukan jika waktu yang dibutuhkan untuk cadangan inkremental data Oracle sama dengan atau lebih besar dari waktu untuk cadangan penuh?

• Gejala

  Waktu yang dibutuhkan untuk cadangan inkremental dan cadangan log mendekati atau bahkan melebihi waktu untuk cadangan penuh.

• Solusi

  Aktifkan Block Change Tracking (BCT) di database Oracle. BCT adalah fitur yang digunakan untuk mempercepat cadangan inkremental RMAN dengan melacak perubahan pada blok data. Hal ini mengurangi waktu pencadangan. Pengaturan ini dinonaktifkan secara default. Anda harus mengaktifkannya secara manual untuk memanfaatkan kemampuannya dalam mempercepat cadangan inkremental RMAN.

  Kelebihan dan kekurangan BCT

  Kelebihan

  Kekurangan

  Mempercepat cadangan inkremental RMAN File BCT mencatat modifikasi blok data. Selama cadangan inkremental RMAN, RMAN tidak perlu memindai seluruh database. RMAN hanya perlu menemukan blok yang berubah melalui file BCT. Untuk database besar, hal ini dapat mengurangi waktu pencadangan inkremental hingga lebih dari 90%. Misalnya, pemindaian tabel penuh database 1 TB mungkin memakan waktu 1 jam, sedangkan BCT dapat menyelesaikan pencadangan inkremental dalam beberapa menit. Mengurangi beban I/O Mengurangi pembacaan fisik. Selama proses pencadangan, file BCT dibaca langsung, menghindari pemindaian tabel penuh dan mengurangi dampak pencadangan pada lingkungan produksi. Konsumsi sumber daya rendah Hampir tidak ada overhead memori tambahan. File BCT biasanya hanya memerlukan beberapa ratus MB (misalnya, file BCT untuk database 1 TB berukuran sekitar 100 MB hingga 200 MB). Kompatibilitas Mendukung semua versi Oracle (mulai dari 10g R2). Di Oracle 12c dan versi selanjutnya, mendukung konfigurasi redundan (beberapa replika file BCT untuk meningkatkan toleransi kesalahan).

  Penggunaan ruang disk tambahan Ukuran file: Meskipun hanya beberapa ratus MB, pastikan path penyimpanan memiliki ruang yang cukup. Konfigurasi redundan: Jika Anda mengonfigurasi beberapa replika (seperti REDUNDANCY 2), penggunaan disk akan berlipat ganda. Dampak kinerja minor Overhead operasi tulis: Setiap kali blok data dimodifikasi, file BCT perlu diperbarui, yang mungkin berdampak sedikit pada kinerja sistem dengan beban tulis tinggi. Skenario pengujian: Dalam sistem pemrosesan transaksi online (OLTP) dengan puluhan ribu transaksi per detik, dampak kinerja BCT biasanya dapat diabaikan. Namun, pemantauan diperlukan dalam skenario konkurensi ekstrem. Risiko kerusakan file Titik kegagalan tunggal: Jika file BCT rusak dan tidak ada redundansi yang dikonfigurasi, pencadangan inkremental mungkin gagal. Kompleksitas perbaikan: Anda perlu mengaktifkan kembali BCT dan membangun ulang file, yang mungkin memerlukan downtime singkat.

  Skenario yang kami rekomendasikan untuk mengaktifkan BCT:

  • Cadangan inkremental sering: sistem yang melakukan pencadangan inkremental RMAN harian atau per jam.

  • Database besar: optimasi waktu pencadangan inkremental untuk database skala terabyte.

  • Persyaratan ketersediaan tinggi: lingkungan produksi yang memerlukan pemulihan cepat dan mengandalkan pencadangan inkremental.

  Skenario yang harus berhati-hati saat mengaktifkan BCT:

  • Database sangat kecil: untuk database berukuran kurang dari 1 GB, manfaat BCT mungkin tidak signifikan.

  • Beban tulis ekstrem tinggi: untuk sistem OLTP dengan puluhan ribu transaksi per detik, dampak kinerja perlu dipertimbangkan.

  • Ruang penyimpanan terbatas: jika ruang disk terbatas, kebutuhan penyimpanan file BCT perlu dievaluasi.

RMAN melaporkan error non-fatal selama cadangan inkremental Oracle

• Gejala

  Cadangan penuh Oracle berhasil, tetapi cadangan inkremental terus-menerus gagal. Pesan error berikut dilaporkan:

  oracle.phxxdb.18472|RMAN reports a non-fatal error:
  ORA-19505: failed to identify file "/arch/1_5137021_976544044.dbf"
  ORA-27037: unable to obtain file status
  Linux-x86_64 Error: 2: No such file or directory
  Additional information: 3

• Penyebab

  Log arsip yang diperlukan tidak dapat ditemukan. Masalah ini dapat terjadi jika skrip atau pekerjaan pencadangan lain memindahkan log arsip tersebut. Jika skrip atau perangkat lunak pencadangan lain berjalan bersamaan dengan Cloud Backup, proses eksternal ini dapat mengubah lokasi log arsip. Hal ini menyebabkan pencadangan inkremental Cloud Backup gagal karena tidak dapat menemukan file yang diperlukan.

• Solusi

  Jangan gunakan Cloud Backup bersamaan dengan perangkat lunak atau skrip pencadangan lain. Hal ini dapat menyebabkan pencadangan gagal atau tidak dapat dipulihkan.

Apa yang harus saya lakukan jika penjelajahan detail database gagal saat mencadangkan SQL Server 2019?

• Gejala

  Saat Anda membuat atau mengedit rencana pencadangan untuk SQL Server 2019 dan memilih instans database, konsol menampilkan pesan error: "Failed to list unibackup instance detail".

• Penyebab

  Saat mencadangkan SQL Server 2019, jika perangkat lunak atau skrip pencadangan lain sedang melakukan operasi pencadangan secara bersamaan, penjelajahan detail database mungkin gagal saat Anda membuat atau mengedit rencana pencadangan dan memilih instans database.

• Solusi

  1. Di database SQL Server, kueri jumlah database dan set cadangan.

     select count(database_id) from master.sys.databases
     select count(backup_set_id) from msdb.dbo.backupset

  2. Hapus catatan pencadangan di msdb.dbo.backupset.

     Penting

     Menghapus catatan pencadangan memengaruhi Anda. Jika Anda memiliki pencadangan sendiri, catatan pencadangan akan dihapus, dan Anda tidak dapat memulihkan catatan tersebut melalui proses normal. Namun, hal ini tidak memengaruhi pencadangan data Anda karena pencadangan berikutnya secara otomatis dikonversi menjadi pencadangan penuh. Perhatikan bahwa saat mencadangkan SQL Server 2019, Anda tidak dapat menggunakannya bersamaan dengan perangkat lunak atau skrip pencadangan lain.

     use msdb;
     exec sp_delete_backuphistory @oldest_date = '04/10/2024' ---Retain records from 4/10 onwards, delete all before 4/9. You need to confirm the retention period.

Apa yang harus dilakukan jika alamat IP untuk database SQL Server lokal salah di konsol Cloud Backup

• Gejala

  Setelah Anda mendaftarkan database SQL Server lokal ke Cloud Backup, alamat IP yang ditampilkan di konsol Cloud Backup tidak sesuai dengan alamat IP mesin lokal. Masalah ini dapat terjadi bahkan jika status klien lokal adalah Normal dan alamat IP mesin lokal tidak diubah.

• Penyebab

  Masalah ini terjadi di lingkungan dengan beberapa network interface card karena Cloud Backup mengambil alamat IP dari network interface card yang tidak digunakan.

• Solusi

  Nonaktifkan network interface card yang tidak digunakan lalu instal ulang klien.

Dapatkah saya mencadangkan database SQL Server ke Alibaba Cloud setelah mengaktifkan Transparent Data Encryption (TDE)?

Tidak.

Apa yang harus saya lakukan jika klien offline, tidak dapat di-uninstall, dan kebijakan anti-ransomware gagal dihapus setelah menerapkan layanan anti-ransomware untuk database SQL Server?

• Gejala

  Setelah Anda menerapkan layanan anti-ransomware untuk database SQL Server, klien offline, kebijakan anti-ransomware tidak dapat dihapus, dan klien tidak dapat di-uninstall.

  Pada titik ini, layanan dbackup3-agent di Windows Task Manager berhenti, dan log agen berisi entri seperti "Stopping all jobs".

  

• Penyebab

  Klien diblokir oleh perangkat lunak antivirus. Periksa perangkat lunak antivirus untuk catatan pemblokiran terkait pada waktu yang sesuai.

• Solusi

  Tambahkan klien ke daftar tepercaya di perangkat lunak antivirus, lalu restart layanan klien atau instal ulang klien.

Apa yang harus saya lakukan jika tidak dapat menginstal atau menggunakan fitur Database Backup setelah mentransfer instans ECS dari Akun Alibaba Cloud asal ke akun baru?

Saat Anda mentransfer instans ECS dari Akun Alibaba Cloud asal ke akun baru, metadata ECS tidak disinkronkan secara otomatis ke layanan Cloud Backup. Anda harus menyelesaikan sinkronisasi terlebih dahulu di backend layanan Cloud Backup sebelum menginstal dan menggunakan fitur tersebut. Untuk langkah-langkah spesifik, hubungi "Dukungan Cloud Backup" atau bergabunglah dengan grup DingTalk "Dukungan Online Cloud Backup" untuk bantuan.

• Cloud Backup Technical Support Group

  Dapatkan jawaban cepat untuk pertanyaan tentang biaya, fitur, dan penggunaan. Cari grup publik DingTalk dan bergabung. Nomor grup DingTalk adalah 88650005148.

• Cloud Backup Expert Support

  Pakar teknis memberikan analisis di tempat untuk menyelesaikan masalah produk dengan cepat. Klik untuk menghubungi dukungan Cloud Backup. Kami merekomendasikan Anda menggunakan Chrome. Tambahkan kontak DingTalk. ID DingTalk adalah d37_g935gslgo.

Apakah ada batasan pada versi database MySQL dan sistem operasi yang didukung untuk pencadangan?

Ya, ada. Batasan berlaku untuk versi database yang didukung, sistem operasi, dan fitur pencadangan. Misalnya, database MySQL yang diterapkan di Windows tidak didukung. Untuk informasi lebih lanjut, lihat Daftar kompatibilitas dan batasan.

Bagaimana cara mencadangkan database yang baru dibuat di MySQL?

Pencadangan MySQL dilakukan di tingkat instans database. Anda tidak perlu mengonfigurasi pencadangan secara manual untuk database baru. Pencadangan berikutnya secara otomatis mencakup database baru tersebut.

Bagaimana cara membatalkan pencadangan database?

Mengapa ada catatan duplikat atau waktu yang tidak sesuai dalam riwayat pencadangan?

Masalah ini biasanya terjadi ketika server (server lokal atau instans ECS) tempat klien Database Backup diinstal dikloning, atau ketika instans ECS baru atau server lokal dibuat dari citra yang berisi klien backup yang sama. Karena server yang dikloning menyimpan beberapa informasi klien dari server asli, catatan pencadangan duplikat mungkin dihasilkan. Untuk mengatasi masalah ini, login ke server yang dikloning dan uninstall klien. Untuk informasi lebih lanjut tentang cara meng-uninstall klien backup, lihat langkah-langkah berikut:

Mengapa pencadangan gagal dan status rencana pencadangan menunjukkan "Error"?

Jika status rencana pencadangan adalah "Error" dan pencadangan gagal, pertama-tama periksa apakah server (server lokal atau instans ECS) tempat klien diinstal telah dikloning, sistem operasinya diinstal ulang, atau disk sistemnya direset. Operasi-operasi ini dapat membatalkan asosiasi antara rencana pencadangan dan klien. Untuk mengatasi masalah ini, ikuti langkah-langkah berikut:

1. Pastikan Anda telah meng-uninstall klien dan file konfigurasinya dari server yang dikloning. Untuk informasi lebih lanjut, lihat Uninstall the client.

2. Pastikan status klien di server saat ini adalah "Installed".

   

3. Setelah menyelesaikan langkah-langkah di atas, hapus rencana pencadangan asli dari konsol dan buat yang baru.

Mengapa waktu peringatan berbeda dari waktu error sebenarnya?

Peringatan pesan teks memiliki fitur penekanan malam hari yang menunda peringatan yang dipicu antara pukul 20.00 hingga 08.00 keesokan harinya hingga setelah pukul 08.00. Peringatan email tidak terpengaruh oleh fitur ini dan dikirim segera.

Mengapa saya menerima email atau pesan teks peringatan kegagalan, tetapi riwayat pencadangan menunjukkan catatan pencadangan berhasil dan gagal secara bersamaan?

Masalah ini biasanya terjadi ketika server (server lokal atau instans ECS) tempat klien Database Backup diinstal dikloning, atau ketika instans ECS baru atau server lokal dibuat dari citra yang berisi klien backup yang sama. Karena server yang dikloning menyimpan beberapa informasi klien dari server asli, catatan pencadangan duplikat mungkin dihasilkan. Untuk mengatasi masalah ini, login ke server yang dikloning dan uninstall klien. Untuk informasi lebih lanjut tentang cara meng-uninstall klien backup, lihat langkah-langkah berikut:

Deskripsi fitur "View Offline Instances Only"

Fitur View Offline Instances Only berguna dalam skenario di mana klien tidak dapat lagi terhubung ke server instans aslinya atau memulihkan data cadangan. Hal ini dapat terjadi jika sistem operasi mesin klien diinstal ulang, atau proses dan konfigurasi klien dihapus oleh perangkat lunak berbahaya. Jika Anda menginstal klien baru dalam situasi ini, sistem akan menetapkan ID instans baru untuk membedakan klien baru dari yang offline dan mencegah kebingungan. Kemudian pulihkan data dari instans offline ke instans klien baru. Untuk informasi lebih lanjut tentang langkah-langkah pemulihan, lihat Restore MySQL, Restore Oracle, dan Restore SQL Server.

Apa yang harus saya lakukan jika pemulihan database SQL Server gagal?

1. Login ke server dan lihat log backup.

   Path log klien Windows: C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log

2. Di log, periksa entri sekitar waktu tugas gagal.

   Jika log backup berisi kata kunci RestoreContainer::ValidateTargetForCreation, hal ini menunjukkan bahwa saat Anda memulihkan database dengan nama yang sama, Anda hanya mengubah path tetapi tidak mengubah nama database. Hal ini menyebabkan konflik nama dan operasi pemulihan gagal. Untuk berhasil memulihkan database, Anda harus mengubah nama database dan path-nya.

Apa yang harus saya lakukan jika pemulihan SQL Server gagal dan log agen menunjukkan error inisialisasi file?

• Gejala

  Saat pemulihan SQL Server gagal, log agen menunjukkan bahwa file gagal diinisialisasi. Log berisi detail berikut:

  2025-11-10 11:25:53.967@iZrxhug********@2208@LM_INFO@dbackup3-agent|[SQLSERVER] output: 100 percent processed.
  2025-11-10 11:25:53.968@iZrxhug********@2208@LM_INFO@dbackup3-agent|[SQLSERVER] output: Processed 51595000 pages for database 'xxx', file 'xxx' on file 1.
  2025-11-10 11:25:53.985@iZrxhug********@2208@LM_INFO@dbackup3-agent|[SQLSERVER] output: Processed 3865 pages for database 'xxx', file 'xxx_log' on file 1.
  2025-11-10 11:25:53.987@iZrxhug********@2208@LM_INFO@dbackup3-agent|[SQLSERVER] output: File "xxx_log" failed to initialize correctly. See the error log for details.
  2025-11-10 11:25:53.989@iZrxhug********@2208@LM_INFO@dbackup3-agent|[SQLSERVER] output: RESTORE DATABASE is terminating abnormally.

  Sebagai tambahan, log error SQL Server melaporkan pesan the file "xxx_log" failed to initialize correctly.

  

• Penyebab

  Jika database sumber di SQL Server 2008 R2 sebelumnya dienkripsi, menonaktifkan enkripsi dapat meninggalkan informasi sisa. Saat Anda mencadangkan database ini dan memulihkan set cadangan ke instans lain, terjadi error inisialisasi. Proses analisis adalah sebagai berikut:

  Catatan

  Jika database sumber adalah SQL Server 2008 R2 dan memiliki Enkripsi Data Transparan (TDE) yang diaktifkan, operasi pemulihan gagal bahkan jika instans target adalah versi yang lebih baru, seperti SQL Server 2014. Pesan error "Certificate not found" dikembalikan. Untuk menyelesaikan pemulihan, Anda harus memulihkan sertifikat dan kunci privat secara manual.

  1. Konfirmasi versi database dari log error SQL Server.

     

  2. Masalah ini kemungkinan terkait dengan TDE. Konfirmasi apakah TDE diaktifkan pada database sumber. Juga, periksa apakah operasi seperti menonaktifkan enkripsi baru-baru ini dilakukan.

     Jalankan pernyataan SQL berikut pada database sumber. Jika bidang key_algorithm dan key_length dalam hasil kueri bukan NULL, database kemungkinan dienkripsi sebelumnya.

     USE master;
     SELECT 
         d.name,
         d.is_encrypted,
         drs.database_id,
         drs.encryption_state,
         drs.percent_complete,
         drs.key_algorithm,
         drs.key_length
     FROM sys.databases AS d
     LEFT JOIN sys.dm_database_encryption_keys AS drs
         ON d.database_id = drs.database_id;

     Gambar berikut menunjukkan contoh hasil kueri.

     

• Solusi

  • Tingkatkan database sumber ke versi yang lebih baru dan buat cadangan baru. Gunakan set cadangan baru untuk melakukan pemulihan. Set cadangan sebelumnya tidak valid.

  • Pulihkan kunci privat dan sertifikat dari instans sumber ke instans target, lalu lakukan operasi pemulihan.

    Setelah pemulihan selesai, hapus sertifikat enkripsi TDE dan kunci enkripsi database dari instans target. Kemudian, cadangkan instans target. Operasi pencadangan dan pemulihan selanjutnya pada instans target akan berfungsi dengan benar.

    Catatan

    Bahkan jika pencadangan data dibuat setelah TDE dinonaktifkan, proses pemulihan tetap memerlukan kunci privat dan sertifikat. Ini diperlukan untuk memproses metadata terenkripsi sisa dalam cadangan. Namun, database yang dipulihkan tidak dienkripsi. Anda kemudian dapat menggunakan database secara normal tanpa sertifikat.

    # Lakukan operasi berikut pada instans sumber
    USE master;
    
    # 1. Kueri nama sertifikat untuk database terenkripsi TDE
    SELECT d.name AS DatabaseName,
           k.encryption_state,
           c.name AS CertificateName
    FROM sys.dm_database_encryption_keys AS k
    JOIN sys.certificates AS c
        ON k.encryptor_thumbprint = c.thumbprint
    JOIN sys.databases AS d
        ON k.database_id = d.database_id
    
    # Asumsikan CertificateName dalam hasil adalah TDECert. Cadangkan sertifikat TDE dan kunci privat ke path kustom.
    BACKUP CERTIFICATE TDECert
       TO FILE = 'C:\Backup\TDECert.cer'  -- Tentukan path file kustom
       WITH PRIVATE KEY (
            FILE = 'C:\Backup\TDECert_PrivateKey.pvk',    -- Tentukan path file kustom
            ENCRYPTION BY PASSWORD = 'Strong_Password_123!'    -- Ingat password ini
       );
    
    -- Salin sertifikat dan kunci privat dari path di atas ke instans target
    
    # 2. Lakukan operasi berikut pada instans target
    USE master;
    
    # Pulihkan kunci utama. Jika muncul pesan 'The master key already exists in the database. Drop the master key before you perform this statement.', lewati langkah ini.
    CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Another_Strong_Password_456!';
    
    # Pulihkan sertifikat TDE
    CREATE CERTIFICATE TDECert -- Tentukan nama sertifikat kustom. Anda akan menggunakannya nanti untuk penghapusan.
        FROM FILE = 'C:\TDE_Test\TDECert.cer' -- Path tempat file yang disalin berada
        WITH PRIVATE KEY (
            FILE = 'C:\TDE_Test\TDECert_PrivateKey.pvk',
            DECRYPTION BY PASSWORD = 'Strong_Password_123!'  -- Password yang digunakan untuk mencadangkan kunci privat
        );
    
    
    # 3. Lakukan langkah pemulihan di konsol Cloud Backup seperti biasa
    
    
    # 4. Setelah pemulihan, hapus kunci enkripsi database
    USE TDE_TestDB_Restore -- Nama database target
    DROP DATABASE ENCRYPTION KEY;
    
    # 5. Hapus sertifikat
    USE master;
    DROP CERTIFICATE TDECert;

Bagaimana cara melakukan pemulihan lintas database antara database lokal dan database ECS?

Pemulihan timbal balik langsung tidak didukung. Daftarkan database di instans ECS sebagai instans database lokal. Setelah pendaftaran, pulihkan data antara instans database lokal yang berbeda.

Apa itu penyimpanan cadangan database?

Anda harus membuat penyimpanan cadangan database sebelum membuat rencana pencadangan database.

Penyimpanan cadangan database adalah vault penyimpanan yang menyimpan data cadangan database Anda. Biaya pencadangan database ditentukan oleh biaya sewa vault dan kapasitas vault. Untuk informasi lebih lanjut, lihat Metode penagihan dan item yang dapat ditagih.

Bagaimana penyimpanan cadangan database melakukan purge data kedaluwarsa?

Cadangan inkremental, cadangan inkremental kumulatif, dan cadangan log bergantung pada rantai pencadangan lengkap sebelumnya. Rantai pencadangan mencakup cadangan penuh sebelumnya dan semua cadangan inkremental, inkremental kumulatif, atau log. Dalam rantai pencadangan yang mencakup cadangan penuh dan cadangan inkremental, inkremental kumulatif, serta log, semua pencadangan yang menjadi dasar rantai pencadangan lengkap disimpan di penyimpanan cadangan dan menempati ruang pencadangan hingga pencadangan terakhir dalam rantai tersebut kedaluwarsa. Anda harus mengonfigurasi siklus pencadangan dan waktu kedaluwarsa secara wajar.

Misalnya, Anda melakukan cadangan penuh pada 1 September dan cadangan inkremental setiap hari dari 2 hingga 7 September. Periode retensi adalah 7 hari. Tujuh pencadangan dari 1 hingga 7 September secara otomatis dihapus setelah semua data kedaluwarsa pada 14 September.

Bagaimana cara melihat ukuran data cadangan dan penggunaan penyimpanan cadangan? Apa dasar penagihannya?

Source Data Size adalah jumlah total data yang telah dicadangkan. Misalnya, jika Anda mencadangkan file 1 TB dua kali, ukuran data sumber adalah 2 TB. Cloud Backup menggunakan deduplikasi dan kompresi untuk mengurangi penggunaan penyimpanan cadangan dan menurunkan biaya Anda. Penagihan didasarkan pada Ukuran Data Penyimpanan Vault yang sebenarnya. Lihat Source Data Size dan Storage Vault Data Size penyimpanan cadangan database di halaman Vault Management.