Cloud Backup:FAQ cadangan basis data

Masalah instans basis data

• Apa yang harus saya lakukan jika instans basis data gagal mendaftar ke Database Backup?

• Bagaimana cara mengatasi status "Inactivated" pada instans basis data?

• Bagaimana cara mengatasi status "DB Offline" pada instans basis data?

• Mengapa beberapa instans basis data muncul di tab ECS Database Instance setelah saya mendaftarkan instans basis data?

• Apa yang harus saya lakukan jika status basis data tidak dapat diambil setelah saya mendaftarkan instans basis data?

Masalah klien

• Bagaimana cara melihat status proses klien, menemukan path log, dan me-restart klien?

• Bagaimana cara mengatasi status "Offline" pada klien basis data?

• Bagaimana cara mengatasi error "Failed to run install script:exit status 4" saat menginstal klien pencadangan untuk basis data SQL Server lokal?

• Bagaimana cara mengatasi kegagalan instalasi klien pencadangan saat mencadangkan basis data SQL Server lokal?

• Bagaimana cara mengatasi kegagalan instalasi klien Database Backup pada Instance ECS?

Masalah pencadangan

• Bagaimana cara mendapatkan uji coba gratis fitur pencadangan basis data lokal?

• Apa saja persyaratan jaringan untuk mencadangkan basis data lokal?

• Berapa interval minimum untuk cadangan waktu nyata? Dapatkah saya mengonfigurasi cadangan waktu nyata dan cadangan inkremental secara bersamaan?

• Bagaimana cara mengubah username dan password untuk Database Backup?

• Apakah pencadangan basis data dienkripsi?

• Apa yang harus saya lakukan jika pencadangan basis data gagal?

• Apa yang harus saya lakukan jika pencadangan data Oracle gagal dan log berisi error "Failed to get install path from registry"?

• Apa yang harus saya lakukan jika pencadangan inkremental data Oracle memakan waktu sama lama atau lebih lama daripada pencadangan penuh?

• Bagaimana cara mengatasi error "RMAN reports a non-fatal error" selama pencadangan inkremental Oracle?

• Apa yang harus saya lakukan jika gagal melihat detail basis data saat mencadangkan basis data SQL Server 2019?

• Apa yang harus saya lakukan jika alamat IP basis data SQL Server lokal yang terdaftar yang ditampilkan di konsol Cloud Backup tidak sesuai dengan alamat IP aktualnya?

• Dapatkah saya mencadangkan basis data 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 tidak dapat dihapus setelah saya menerapkan layanan anti-ransomware untuk basis data SQL Server?

• Apa yang harus saya lakukan jika saya tidak dapat menginstal atau menggunakan Database Backup dengan benar setelah mentransfer Instance ECS dari satu Akun Alibaba Cloud ke akun lainnya?

• Versi basis data MySQL dan sistem operasi apa saja yang didukung untuk pencadangan?

• Bagaimana cara mencadangkan basis data yang baru dibuat di MySQL?

• Bagaimana cara membatalkan pencadangan basis data?

• Mengapa riwayat pencadangan berisi catatan pencadangan duplikat atau tidak terduga?

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

• Mengapa waktu peringatan berbeda dengan waktu sebenarnya ketika error terjadi?

• Mengapa saya menerima peringatan kegagalan, tetapi riwayat pencadangan menunjukkan catatan pencadangan berhasil dan gagal untuk waktu yang sama?

Masalah pemulihan

• Bagaimana cara kerja fitur "View Offline Instances Only"?

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

• Bagaimana cara mengatasi kegagalan pemulihan SQL Server ketika log agen menunjukkan error inisialisasi file?

• Bagaimana cara melakukan pemulihan lintas basis data antara basis data lokal dan basis data pada Instance ECS?

Masalah penyimpanan cadangan

• Apa itu penyimpanan cadangan basis data?

• Bagaimana data yang kedaluwarsa dibersihkan dari penyimpanan cadangan basis data?

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

Kegagalan pendaftaran instans

Pertama, periksa apakah klien pencadangan telah diinstal pada server Anda (server lokal atau Instance ECS). Jika sudah, uninstall dan hapus file konfigurasinya dengan mengikuti petunjuk di Uninstall the client. Kemudian, coba daftarkan kembali instans tersebut.

Status instans tidak aktif

Status instans offline

Beberapa instans setelah pendaftaran

Jika beberapa instans basis data diterapkan pada satu Instance ECS, konsol Cloud Backup akan memindai dan menampilkan semuanya selama pendaftaran.

Di tab ECS database instance, konsol menampilkan beberapa instans basis data pada Instance ECS yang sama sebagai catatan terpisah. Setiap catatan sesuai dengan nama instans dan nomor port yang berbeda.

Tidak dapat mengambil status basis data

• Gejala

  Setelah instans basis data didaftarkan, konsol Cloud Backup tidak dapat mengambil statusnya.

  Di konsol, kolom status basis data terus menampilkan ikon loading.

• Penyebab

  Sistem operasi saat ini tidak didukung oleh basis data.

• Solusi

  Beralih ke sistem operasi yang didukung lalu coba lagi.

Periksa status klien, path log, dan restart

• Linux

  1. Periksa status proses klien pencadangan.

     Jalankan perintah systemctl status dbackup3-agent atau service dbackup3-agent status untuk memeriksa status proses klien pencadangan basis data.

     Output active or dbackup3-agent is running... menunjukkan bahwa klien berjalan dengan benar.

     ● 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 pencadangan.

     Setelah Anda me-restart proses klien dengan menjalankan perintah systemctl restart dbackup3-agent atau service dbackup3-agent restart, status klien akan kembali normal jika Client Status basis data 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 lalu tekan Enter untuk membuka konsol Services.

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

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

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

Atasi status klien "Offline"

• Gejala

  Client Status basis data adalah Offline.

  Pada titik ini, Client Status adalah Offline, dan status basis data adalah Unknown.

• Penyebab

  Status Offline menunjukkan hilangnya heartbeat dari klien, biasanya disebabkan oleh proses klien yang dihentikan karena memori tidak mencukupi atau perangkat host dimatikan.

• Solusi

  Periksa dan restart klien seperti yang dijelaskan di How do I check the client process status, find the log path, and restart the client?. Setelah status klien berubah menjadi Running, tunggu hingga Client Status basis data di konsol berubah menjadi Installed. Ini menunjukkan bahwa klien telah kembali normal.

Atasi error instalasi "exit status 4"

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

1. Tekan Win+R untuk membuka perintah Run, masukkan gpedit.msc untuk menjalankan Local Group Policy Editor.

2. Di Local Group Policy Editor, navigasi 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.

Atasi kegagalan instalasi klien untuk SQL Server lokal

1. Login ke server dan periksa log pencadangan.

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

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

   Jika log pencadangan 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 installer ke daftar izin atau nonaktifkan sementara perangkat lunak keamanan, lalu coba instalasi lagi.

Atasi kegagalan instalasi klien di ECS

Untuk memastikan instalasi berhasil, periksa hal berikut:

1. Status Cloud Assistant: Verifikasi bahwa Cloud Assistant telah diinstal pada Instance ECS dan berjalan dengan baik.

   Jika instalasi gagal, Anda biasanya dapat menemukan catatan perintah gagal di Cloud Assistant console. Salin perintah tersebut dan jalankan secara manual di host ECS. Selama instalasi manual, jika terjadi error jaringan atau eksekusi skrip, pesan error spesifik akan muncul. Gunakan pesan tersebut untuk menyelesaikan masalah, misalnya dengan menyesuaikan pengaturan jaringan.

   Setelah Anda menyelesaikan masalah dan skrip berjalan berhasil, klien akan diinstal. Kemudian, picu kembali instalasi dari konsol untuk menyelesaikan proses.

2. Ruang drive C: Pastikan drive C memiliki ruang kosong yang cukup. Ruang yang tidak mencukupi akan mencegah instalasi klien.

Uji coba gratis untuk pencadangan basis data lokal

Proses uji coba gratis untuk pencadangan basis data lokal sama dengan pencadangan basis data ECS. Untuk detailnya, lihat 30-day free trial.

Persyaratan jaringan

Anda harus menghubungkan server basis data on-premises Anda ke virtual private cloud (VPC) Alibaba Cloud melalui leased line atau VPN. Anda juga harus mengonfigurasi routing dari jaringan on-premises Anda ke Blok CIDR berikut di cloud: 100.64.0.0/10 dan 100.96.0.0/11.

Interval pencadangan real-time dan pencadangan inkremental

Pencadangan real-time dapat mencapai RPO tingkat detik dan saat ini mendukung basis data MySQL dan Oracle. Setelah Anda mengaktifkan pencadangan real-time, Anda tidak dapat mengonfigurasi pencadangan log tradisional yang terpisah. Namun, Anda dapat menggabungkannya dengan pencadangan inkremental untuk meningkatkan perlindungan data Anda.

Ubah kredensial pencadangan basis data

Gunakan Reactivate untuk mengubah kredensial pencadangan, misalnya ketika password kedaluwarsa. Reaktivasi tidak memengaruhi rencana pencadangan yang ada tetapi memengaruhi pekerjaan pencadangan yang sedang berlangsung. Untuk meminimalkan dampak, lakukan hal berikut:

1. Di tab Backup Plans, jeda pencadangan log real-time apa pun.

2. Di kolom tindakan untuk basis data, pilih More > Reactivate.

Enkripsi pencadangan basis data

Ya, pencadangan basis data dienkripsi untuk melindungi data Anda dari risiko keamanan. Ini mencakup enkripsi dalam transit dan enkripsi saat disimpan.

• Enkripsi dalam transit: Secara default, data dienkripsi dalam transit menggunakan HTTPS, yang berbasis secure sockets layer/transport layer security (SSL/TLS). SSL/TLS memastikan kerahasiaan dan integritas data antara aplikasi yang berkomunikasi.

• Enkripsi saat disimpan: Cloud Backup mengenkripsi data pencadangan Anda di penyimpanan cadangan menggunakan algoritma AES-256 dan kunci yang dikelola penyedia.

Menangani kegagalan pencadangan basis data

Kesalahan pencadangan Oracle: Gagal mendapatkan jalur instalasi dari registri

• Gejala

  Pencadangan data Oracle gagal, dan log berisi pesan error berikut:

  Failed to get install path from registry.
  Failed import $APPDATA\scutech\dbackup3\common\conf/config.ini: No such file or directory
  (Failed to open '$APPDATA\ scutech\dbackup3\common\conf/config ini' as default global config.

• Penyebab

  Oracle 12c dan versi yang lebih baru mendukung menjalankan layanan Oracle sebagai pengguna virtual. Namun, klien Cloud Backup berjalan sebagai pengguna sistem. Hal ini dapat menyebabkan konflik izin yang mencegah Oracle mengakses direktori yang dibuat oleh perangkat lunak pencadangan.

• Solusi

  Berikan izin Full Control secara manual ke grup Users. Ikuti langkah-langkah berikut:

  1. Buka Registry Editor. Navigasi ke HKEY_LOCAL_MACHINE\SOFTWARE\scutech\dbackup3, klik kanan kunci agent, lalu pilih Permissions.

  2. Di kotak dialog Permissions for agent, pilih grup Users, centang kotak Allow untuk Full Control, lalu klik OK.

Pencadangan inkremental sama lambatnya dengan pencadangan penuh

• Gejala

  Pencadangan inkremental atau log memakan waktu hampir sama lama, atau lebih lama, daripada pencadangan penuh.

• Solusi

  Aktifkan Block Change Tracking (BCT) di basis data Oracle Anda. BCT mempercepat pencadangan inkremental RMAN dengan melacak perubahan blok data untuk mengurangi waktu pencadangan. Fitur ini dinonaktifkan secara default dan harus diaktifkan secara manual.

  Kelebihan dan kekurangan BCT

  Kelebihan

  Kekurangan

  Mempercepat pencadangan inkremental RMAN File BCT mencatat perubahan pada blok data. Selama pencadangan inkremental RMAN, RMAN menemukan blok yang berubah dengan membaca file BCT alih-alih memindai seluruh basis data. Untuk basis data besar, hal ini dapat mengurangi waktu pencadangan inkremental lebih dari 90%. Misalnya, pemindaian penuh basis data 1 TB mungkin memakan waktu satu jam, sedangkan pencadangan inkremental menggunakan BCT hanya memakan waktu beberapa menit. Mengurangi beban I/O Mengurangi pembacaan fisik. Selama pencadangan, file BCT dibaca secara langsung, yang menghindari pemindaian tabel penuh dan mengurangi dampak pada lingkungan produksi. Konsumsi sumber daya rendah Memerlukan overhead memori yang hampir tidak ada. File BCT biasanya hanya beberapa ratus megabyte. Misalnya, file BCT untuk basis data 1 TB berukuran sekitar 100 MB hingga 200 MB. Kompatibilitas Mendukung semua versi Oracle mulai dari 10g R2. Oracle 12c dan yang lebih baru mendukung konfigurasi redundan dengan beberapa salinan file BCT untuk meningkatkan toleransi kesalahan.

  Memerlukan ruang penyimpanan tambahan Ukuran file: Meskipun file hanya beberapa ratus megabyte, Anda harus memastikan path penyimpanan memiliki ruang yang cukup. Konfigurasi redundan: Jika Anda mengonfigurasi beberapa salinan, misalnya dengan REDUNDANCY 2, ruang penyimpanan yang diperlukan menjadi dua kali lipat. Dampak kinerja minor Overhead operasi tulis: Saat blok data dimodifikasi, file BCT juga harus diperbarui. Hal ini dapat sedikit memengaruhi kinerja pada sistem dengan beban tulis tinggi. Contoh skenario: Dalam sistem pemrosesan transaksi online (OLTP) dengan puluhan ribu transaksi per detik, dampak kinerja BCT biasanya dapat diabaikan. Namun, Anda harus memantau kinerja dalam skenario konkurensi tinggi ekstrem. Risiko korupsi file Titik kegagalan tunggal: Jika file BCT rusak dan tidak ada redundansi yang dikonfigurasi, pencadangan inkremental mungkin gagal. Kompleksitas perbaikan: Anda mungkin perlu mengaktifkan kembali BCT dan membangun ulang file, yang mungkin memerlukan downtime singkat.

  Skenario yang direkomendasikan untuk mengaktifkan BCT:

  • Sistem yang melakukan pencadangan inkremental RMAN harian atau per jam.

  • Basis data skala terabyte yang memerlukan pencadangan inkremental lebih cepat.

  • Lingkungan produksi yang memerlukan ketersediaan tinggi dan pemulihan cepat, serta mengandalkan pencadangan inkremental.

  Berhati-hatilah saat mengaktifkan BCT dalam skenario berikut:

  • Basis data yang sangat kecil, seperti yang kurang dari 1 GB, di mana manfaat BCT minimal.

  • Sistem OLTP dengan beban tulis sangat tinggi, seperti puluhan ribu transaksi per detik, di mana Anda harus mempertimbangkan dampak kinerja potensial.

  • Lingkungan dengan ruang penyimpanan terbatas, di mana Anda perlu mengevaluasi kebutuhan penyimpanan file BCT.

Error non-fatal RMAN selama pencadangan inkremental Oracle

• Gejala

  Pencadangan penuh basis data Oracle berhasil, tetapi pencadangan inkremental terus-menerus gagal. Anda menerima pesan error seperti berikut:

  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

  Masalah ini disebabkan oleh log arsip yang hilang. Skrip pencadangan atau tugas pencadangan lain mungkin telah memindahkan log, sehingga Cloud Backup tidak dapat menemukan file yang diperlukan untuk pencadangan inkremental.

• Solusi

  Jangan gunakan Cloud Backup secara bersamaan dengan perangkat lunak pencadangan atau skrip pencadangan lain. Menjalankan beberapa alat pencadangan secara bersamaan dapat menyebabkan konflik, yang mengakibatkan kegagalan pencadangan atau mencegah pemulihan yang berhasil.

Gagal menampilkan detail basis data SQL Server 2019

• Gejala

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

• Penyebab

  Error ini terjadi jika perangkat lunak pencadangan atau skrip lain melakukan pencadangan bersamaan pada SQL Server 2019 saat Anda membuat atau mengedit rencana pencadangan.

  Konsol kemudian menampilkan dialog error dengan pesan: "Failed to list unibackup instance detail".

• Solusi

  1. Hapus file C:\ProgramData\scutech\dbackup3\agent\mssql\(local)\data.db.

  2. Di konsol Services (services.msc), temukan dan restart layanan dbackup3-agent.

Alamat IP SQL Server lokal salah

• Gejala

  Setelah Anda mendaftarkan basis data SQL Server lokal ke Cloud Backup, alamat IP di konsol Cloud Backup tidak sesuai dengan alamat IP lokal host. Masalah ini terjadi bahkan ketika klien lokal berjalan normal dan alamat IP-nya tidak diubah.

  Di tab Local Database Instance, alamat IP di kolom Client IP address berada dalam rentang 169.x.x.x, yang berbeda dari alamat IP lokal.

• Penyebab

  Di lingkungan multi-NIC, Cloud Backup mengambil alamat IP dari antarmuka jaringan yang tidak digunakan di host.

• Solusi

  Untuk menyelesaikan masalah ini, nonaktifkan antarmuka jaringan yang tidak digunakan, lalu instal ulang klien.

Pencadangan SQL Server TDE

Tidak, ini tidak didukung.

Pemecahan masalah klien offline yang tidak dapat di-uninstall

• Gejala

  Setelah Anda menerapkan layanan anti-ransomware untuk instans SQL Server, klien tampak offline, upaya menghapus kebijakan anti-ransomware gagal, dan Anda tidak dapat meng-uninstall klien.

  Di halaman manajemen anti-ransomware di konsol, status klien untuk instans SQL Server adalah Offline, dan Anda tidak dapat menghapus kebijakan anti-ransomware.

  Di Windows Task Manager, layanan dbackup3-agent dihentikan, dan log agen berisi entri seperti "Stopping all jobs".

  Attempting to connect database ...
  ...
  Stopping all jobs

• Penyebab

  Perangkat lunak antivirus telah memblokir klien. Periksa perangkat lunak antivirus Anda untuk catatan pemblokiran terkait sekitar waktu tersebut.

• Solusi

  Tambahkan klien ke daftar izin di perangkat lunak antivirus Anda, dan restart layanan klien (atau instal ulang klien).

Masalah pencadangan basis data setelah transfer Instance ECS

Setelah Instance ECS ditransfer dari Akun Alibaba Cloud aslinya ke akun baru, metadata ECS-nya tidak disinkronkan secara otomatis ke layanan Cloud Backup. Anda harus menyinkronkan metadata ECS di backend layanan Cloud Backup sebelum Anda dapat menginstal dan menggunakan fitur pencadangan basis data. Untuk langkah-langkah detailnya, hubungi Dukungan Cloud Backup atau bergabunglah dengan grup Dukungan Online Cloud Backup di DingTalk.

• Cloud Backup Technical Support Group

  Dapatkan jawaban cepat untuk pertanyaan Anda tentang harga, fitur, dan penggunaan. Klik untuk bergabung dengan Dukungan Online Cloud Backup (disarankan Chrome). Cari dan bergabunglah dengan grup publik menggunakan ID DingTalk 88650005148.

• Cloud Backup Expert Support

  Ahli teknis memberikan analisis langsung untuk menyelesaikan masalah produk dengan cepat. Klik untuk menghubungi dukungan Cloud Backup (disarankan Chrome). Tambahkan kontak di DingTalk menggunakan ID: d37_g935gslgo.

Batasan versi dan OS MySQL

Ada batasan pada versi basis data yang didukung, sistem operasi, dan fitur pencadangan. Misalnya, basis data MySQL yang diterapkan di Windows tidak didukung. Untuk informasi lebih lanjut, lihat Compatibility list and limits.

Mencadangkan basis data baru

Karena pencadangan MySQL dilakukan di tingkat instans, basis data baru secara otomatis disertakan dalam siklus pencadangan berikutnya tanpa perlu konfigurasi manual.

Membatalkan pencadangan basis data

Catatan pencadangan duplikat atau tidak terduga

Hal ini terjadi ketika Anda mengkloning server (server lokal atau Instance ECS) yang memiliki klien pencadangan basis data terinstal, atau saat Anda membuat Instance ECS atau server lokal baru dari image yang mencakup klien yang sama. Server yang dikloning mempertahankan beberapa informasi klien dari server asli, yang menyebabkan catatan pencadangan duplikat. Untuk menyelesaikan masalah ini, login ke server yang dikloning dan uninstall klien. Untuk meng-uninstall klien pencadangan basis data, ikuti petunjuk yang relevan di bawah ini.

Error rencana pencadangan

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

1. Uninstall klien dan hapus file konfigurasinya dari server yang dikloning. Untuk informasi lebih lanjut, lihat Uninstall the client.

2. Verifikasi bahwa status klien di server saat ini adalah "Installed".

3. Hapus rencana pencadangan asli di konsol dan buat rencana pencadangan baru.

Ketidaksesuaian waktu peringatan

Dengan penekanan malam hari, peringatan pesan teks yang dipicu antara pukul 20.00 hingga 08.00 tidak dikirim hingga setelah pukul 08.00. Sebaliknya, peringatan email dikirim segera.

Catatan pencadangan berhasil dan gagal duplikat

Hal ini terjadi ketika Anda mengkloning server (server lokal atau Instance ECS) yang memiliki klien pencadangan basis data terinstal, atau saat Anda membuat Instance ECS atau server lokal baru dari image yang mencakup klien yang sama. Server yang dikloning mempertahankan beberapa informasi klien dari server asli, yang menyebabkan catatan pencadangan duplikat. Untuk menyelesaikan masalah ini, login ke server yang dikloning dan uninstall klien. Untuk meng-uninstall klien pencadangan basis data, ikuti petunjuk yang relevan di bawah ini.

Fitur View Offline Instances Only

Fitur View Offline Instances Only berlaku untuk skenario di mana klien tidak dapat lagi terhubung ke instans aslinya, sehingga perlu memulihkan data dari pencadangan. Hal ini dapat terjadi jika sistem operasi di klien diinstal ulang atau proses dan konfigurasi klien dihapus, misalnya oleh program berbahaya. Dalam kasus seperti itu, jika Anda menginstal klien baru, sistem akan memberikan ID instans yang berbeda untuk membedakannya dari instans offline dan mencegah kebingungan. Anda kemudian dapat memulihkan data dari instans offline ke instans baru. Untuk petunjuk detailnya, lihat Restore MySQL, Restore Oracle, dan Restore SQL Server.

Menyelesaikan kegagalan pemulihan SQL Server

1. Login ke server dan lihat log pencadangan.

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

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

   Jika log pencadangan berisi kata kunci RestoreContainer::ValidateTargetForCreation, hal ini menunjukkan operasi pemulihan gagal karena Anda mengubah path basis data tetapi tidak mengubah nama basis data, yang menyebabkan konflik nama. Untuk berhasil memulihkan basis data, ubah nama basis data dan path-nya.

Kegagalan pemulihan SQL Server: Error inisialisasi file

• Gejala

  Saat pemulihan SQL Server gagal, log agen menunjukkan bahwa file gagal diinisialisasi dengan benar. Log menunjukkan hal 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.

  Selain itu, SQL Server ErrorLog melaporkan pesan the file "xxx_log" failed to initialize correctly.

• Penyebab

  Error ini dapat terjadi saat memulihkan pencadangan basis data SQL Server 2008 R2 yang sebelumnya dienkripsi. Bahkan setelah enkripsi dinonaktifkan, informasi sisa dapat tetap ada di set pencadangan, menyebabkan error inisialisasi file saat Anda memulihkannya. Proses analisisnya adalah sebagai berikut.

  Catatan

  Jika basis data sumber adalah SQL Server 2008 R2 dan memiliki transparent data encryption (TDE) yang diaktifkan, operasi pemulihan gagal bahkan jika instans target adalah versi yang lebih baru, seperti SQL Server 2014. Pemulihan gagal dengan error "Certificate not found". Untuk menyelesaikan pemulihan, Anda harus memulihkan sertifikat dan kunci privat secara manual.

  1. Konfirmasi versi basis data dari SQL Server ErrorLog.

     Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64)

  2. Masalah ini sering terkait dengan transparent data encryption (TDE). Konfirmasi apakah TDE pernah diaktifkan di basis data sumber, bahkan jika saat ini dinonaktifkan.

     Jalankan pernyataan SQL berikut di basis data. Jika kolom key_algorithm dan key_length untuk basis data Anda dalam hasil kueri tidak NULL, basis data 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;

     Contoh hasil kueri adalah sebagai berikut.

     Dalam hasil kueri, jika nilai bidang key_algorithm dan key_length untuk basis data tidak NULL, hal ini menunjukkan bahwa enkripsi TDE telah diaktifkan untuk basis data tersebut.

• Solusi

  • Tingkatkan basis data sumber ke versi yang lebih baru dan buat pencadangan baru. Gunakan set pencadangan baru untuk melakukan operasi pemulihan. Set pencadangan sebelumnya tidak valid.

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

    Setelah pemulihan selesai, hapus sertifikat TDE dan kunci enkripsi basis data dari instans target. Lalu, cadangkan instans target. Operasi pencadangan dan pemulihan berikutnya pada instans target akan berfungsi dengan benar.

    Catatan

    Bahkan jika pencadangan data dibuat setelah TDE dinonaktifkan, proses pemulihan tetap memerlukan kunci privat dan sertifikat. Mereka diperlukan untuk menangani metadata terenkripsi sisa di pencadangan. Namun, basis data yang dipulihkan sendiri tidak dienkripsi dan dapat berjalan normal tanpa sertifikat setelah itu.

    # Di instans sumber, jalankan perintah berikut.
    USE master;
    
    # 1. Kueri nama sertifikat untuk basis data 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 hasilnya 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 sebelumnya ke instans target.
    
    # 2. Di instans target, jalankan perintah berikut.
    USE master;
    
    # Pulihkan kunci master. Jika Anda menerima 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 saat mencadangkan kunci privat.
        );
    
    # 3. Lakukan pemulihan di konsol Cloud Backup seperti biasa.
    
    # 4. Setelah pemulihan, hapus kunci enkripsi basis data.
    USE TDE_TestDB_Restore -- Nama basis data target.
    DROP DATABASE ENCRYPTION KEY;
    
    # 5. Hapus sertifikat.
    USE master;
    DROP CERTIFICATE TDECert;

Pemulihan lintas basis data: Lokal dan ECS

Pemulihan langsung antara dua lingkungan ini tidak didukung. Anda harus terlebih dahulu mendaftarkan basis data di Instance ECS sebagai instans basis data lokal. Setelah pendaftaran, Anda dapat memulihkan data antara instans basis data lokal yang berbeda.

Apa itu penyimpanan cadangan basis data?

Anda harus membuat penyimpanan cadangan basis data sebelum dapat membuat rencana pencadangan basis data.

Penyimpanan cadangan basis data adalah repositori yang menyimpan pencadangan basis data Anda. Biaya sewa penyimpanan dan kapasitas penyimpanan menentukan biaya pencadangan basis data. Untuk informasi lebih lanjut, lihat Billing methods and billable items.

Pembersihan cadangan yang kedaluwarsa

Pencadangan inkremental, pencadangan inkremental kumulatif, dan pencadangan log semuanya bergantung pada rantai pencadangan lengkap. Rantai ini mencakup pencadangan penuh awal dan semua pencadangan inkremental, inkremental kumulatif, dan log berikutnya. Dalam rantai pencadangan, semua pencadangan yang bergantung dipertahankan dan mengonsumsi ruang penyimpanan hingga pencadangan terakhir dalam rantai kedaluwarsa. Anda harus mengonfigurasi siklus pencadangan dan waktu kedaluwarsa dengan hati-hati untuk mengelola biaya penyimpanan.

Misalnya, jika Anda melakukan pencadangan penuh pada 1 September dan pencadangan inkremental setiap hari dari 2 hingga 7 September dengan periode retensi tujuh hari, tujuh pencadangan yang dibuat dari 1 hingga 7 September akan dihapus secara otomatis hanya setelah seluruh rantai kedaluwarsa pada 14 September.

Ukuran data, penggunaan, dan penagihan

Source Data Size mewakili jumlah total data yang telah Anda cadangkan. Misalnya, jika Anda mencadangkan file 1 TB dua kali, Cloud Backup menyimpan dua salinan independen, dan Source Data Size dihitung sebagai 2 TB. Cloud Backup menggunakan deduplikasi dan kompresi untuk mengurangi penyimpanan yang dikonsumsi pencadangan Anda, yang membantu Anda menghemat biaya. Penagihan didasarkan pada Storage Vault Data Size aktual. Anda dapat melihat Source Data Size dan Storage Vault Data Size untuk penyimpanan cadangan basis data di halaman Vault Management.