All Products
Search
Document Center

Data Management:Kesalahan umum dan troubleshooting untuk Pemulihan Bencana Data (DBS)

Last Updated:Jun 22, 2026

Topik ini menjelaskan berbagai kesalahan, seperti pesan pengecualian dan kode kesalahan, yang mungkin Anda temui saat mengonfigurasi jadwal backup, menjalankan pemeriksaan awal (precheck), atau mengeksekusi pekerjaan pemulihan, serta cara mengatasinya.

Catatan

Jika Anda mengalami kesalahan yang tidak dijelaskan dalam topik ini atau solusi yang diberikan tidak menyelesaikan masalah tersebut, hubungi dukungan teknis melalui grup DingTalk (ID: 35585947).

Kesalahan

Kesalahan konfigurasi jadwal backup

Kegagalan uji koneksi database sumber

Kesalahan precheck backup dan pemulihan

Kesalahan tugas unduh lanjutan

Kesalahan eksekusi tugas

Kesalahan jadwal backup

Koneksi ke database sumber gagal

Skenario: Uji koneksi gagal saat Anda mengonfigurasi jadwal backup.

Penyebab yang mungkin terjadi:

  • Akun database atau password salah.

  • Akses ke database dibatasi berdasarkan alamat IP sumber.

  • Pembatasan firewall pada server atau jaringan database sumber.

  • Masalah konektivitas jaringan.

Solusi:

  1. Klik Check di konsol untuk melihat detail kegagalan koneksi. Dialog Check menampilkan hasil diagnosis untuk MySQL JDBC Connect dan Telnet. Gunakan hasil diagnosis dan pesan kesalahan untuk menentukan penyebab kegagalan.

  2. Periksa apakah pemeriksaan diagnosis berikut berhasil.

    • Pertama, periksa apakah akun database atau password salah atau database membatasi akses dari IP sumber.

      1. Verifikasi akun dan password database.

        Dari klien yang dapat terhubung ke database sumber, gunakan akun dan password database yang ditentukan dalam jadwal backup untuk memverifikasi kredensial. Jika kredensial salah, perbarui di konfigurasi jadwal backup dan uji koneksi lagi.

      2. Jika akun dan password benar, database mungkin membatasi akses berdasarkan alamat IP sumber.

        • Jika database sumber adalah MySQL, gunakan klien MySQL untuk terhubung dan jalankan pernyataan SQL berikut. Kemudian, periksa output untuk memastikan daftar alamat IP yang diizinkan mengizinkan akses remote.

          SELECT host,user,authentication_string,password_expired,account_locked FROM mysql.user WHERE user='[$Username]';
          Catatan

          Ganti [$Username] dengan akun database yang ditentukan dalam jadwal backup Anda.

        • Jika database sumber adalah SQL Server:

          • Jika gateway backup diinstal pada server database sumber, atur Address menjadi localhost.

          • Periksa apakah firewall dikonfigurasi pada host SQL Server, atau apakah titik akhir (endpoint) atau pemicu (trigger) di database sumber membatasi akses berdasarkan alamat IP.

        • Jika database sumber adalah Oracle, periksa file konfigurasi sqlnet.ora untuk memastikan apakah parameter TCP.VALIDNODE_CHECKING diatur ke YES. Jika nilainya YES, database sumber membatasi akses berdasarkan alamat IP sumber.

    • Kemudian, periksa apakah server dan jaringan yang menghosting database memiliki pembatasan firewall atau terdapat masalah komunikasi jaringan.

      1. Periksa apakah firewall diaktifkan pada server database sumber dan apakah kebijakan firewall dikonfigurasi.

        • Jika database sumber diinstal pada server Windows, buka Control Panel, navigasi ke Windows Defender Firewall, dan periksa apakah ada kebijakan firewall yang dikonfigurasi.

        • Jika database sumber diinstal pada server Linux, jalankan perintah iptables -L untuk memeriksa apakah kebijakan firewall dikonfigurasi.

        • Jika database diinstal pada instance ECS Alibaba Cloud, rujuk dokumentasi Tambahkan aturan grup keamanan untuk memeriksa apakah grup keamanan mengizinkan akses dari Blok CIDR yang diperlukan. Anda dapat menemukan informasi Blok CIDR di konsol.

      2. Periksa apakah firewall jaringan membatasi akses dari Blok CIDR yang diperlukan. Instruksi berikut menggunakan Cloud Firewall sebagai contoh.

        1. Login ke Konsol Cloud Firewall. Di panel navigasi kiri, klik Access Control.

        2. Periksa apakah ada kebijakan Cloud Firewall yang memblokir akses dari Blok CIDR yang diperlukan. Anda dapat menemukan informasi Blok CIDR di konsol.

        Catatan

        Jika Anda telah menyingkirkan pembatasan firewall tetapi pemeriksaan Telnet tetap gagal, penyebabnya kemungkinan besar adalah masalah konektivitas jaringan. Untuk bantuan, hubungi dukungan melalui grup DingTalk.

Kesalahan precheck backup dan pemulihan

Koneksi ke database sumber gagal

Kesalahan ini terjadi selama precheck untuk jadwal backup atau tugas pemulihan.

Penyebab yang mungkin terjadi:

  • Akun database atau password salah.

  • Database membatasi akses dari alamat IP sumber.

  • Firewall dikonfigurasi pada server atau jaringan database.

  • Terdapat masalah komunikasi jaringan.

Solusi: Lihat resolusi untuk kegagalan uji koneksi database sumber, yang dijelaskan di bawah kesalahan umum untuk konfigurasi jadwal backup.

Pemeriksaan izin database gagal

Skenario: Kesalahan ini terjadi selama precheck untuk jadwal backup atau tugas pemulihan.

Penyebab yang mungkin terjadi:

  • Akun database untuk jadwal backup tidak memiliki izin yang diperlukan untuk mengakses data database.

  • Akun database untuk tugas pemulihan tidak memiliki izin untuk menulis data atau memodifikasi skema database.

Solusi: Periksa izin akun database. Jika izin tidak mencukupi, berikan izin yang diperlukan ke akun tersebut atau gunakan akun lain yang memiliki izin tersebut.

Catatan
  • Untuk jadwal backup: Untuk mengubah akun database, lihat Ubah sumber backup.

  • Untuk tugas pemulihan: Konfigurasikan tugas pemulihan baru, lalu hapus tugas asli yang gagal dalam precheck.

Pemeriksaan OSS gagal

Skenario: Precheck untuk jadwal backup atau tugas pemulihan gagal.

Penyebab yang mungkin terjadi:

  • Penyimpanan backup adalah bucket OSS milik pengguna, tetapi Pemulihan Bencana Data belum diberikan otorisasi layanan untuk mengaksesnya.

  • Telah terjadi masalah layanan internal.

Solusi:

  • Di halaman Configure Task untuk jadwal pencadangan target, periksa bidang Backup Storage OSS Bucket pada bagian Basic Information untuk memastikan apakah bucket OSS milik pengguna digunakan. Jika ya, buka konsol OSS untuk memverifikasi bahwa bucket yang ditampilkan di konsol Pemulihan Bencana Data tersedia dan otorisasi layanan telah diberikan.

  • Jika terjadi masalah layanan internal, hubungi dukungan teknis di grup DingTalk.

Precheck binlog database sumber gagal

Skenario: Precheck binlog database sumber gagal.

Solusi: Precheck ini memverifikasi bahwa fitur binary logging diaktifkan pada database sumber. Precheck yang gagal menunjukkan bahwa fitur tersebut dinonaktifkan. Untuk mengatasi masalah ini, ikuti langkah-langkah berikut.

  1. Login ke server yang menghosting database sumber MySQL yang dikelola sendiri.

  2. Modifikasi pengaturan berikut dalam file konfigurasi MySQL my.cnf.

    log_bin=mysql_bin
    binlog_format=row
    server_id=2 # Harus berupa bilangan bulat lebih besar dari 1. Ini adalah nilai contoh.
    binlog_row_image=full # Parameter ini diperlukan jika database sumber menjalankan MySQL 5.6 atau lebih baru.
    Catatan

    Jalur default file konfigurasi my.cnf adalah /etc/my.cnf. Jalur aktual dapat berbeda tergantung pada instalasi Anda.

  3. Restart layanan MySQL dengan menjalankan perintah berikut.

    [$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
    [$Mysql_Dir]/bin/safe_mysqld &
    Catatan

    Ganti [$Mysql_Dir] dengan direktori instalasi MySQL.

  4. Login ke database sumber MySQL yang dikelola sendiri dan jalankan pernyataan SQL berikut untuk memastikan bahwa fitur binary logging diaktifkan.

    SHOW variables LIKE '%log_bin%';

    Output berikut menunjukkan bahwa fitur tersebut diaktifkan:

    MariaDB [pro1]> show variables like '%log_bin%';
    +----------------------------------+-------+
    | Variable_name                    | Value |
    +----------------------------------+-------+
    | log_bin                          | ON    |
    | log_bin_trust_function_creators  | OFF   |
    | sql_log_bin                      | ON    |
    +----------------------------------+-------+
    3 rows in set (0.00 sec)
  5. Jalankan precheck DBS lagi.

Pemeriksaan format binlog sumber gagal

Skenario: Precheck untuk format log biner database sumber gagal.

Solusi: Pemeriksaan ini memverifikasi bahwa format log biner database sumber diatur ke ROW. Jika precheck gagal, format tersebut tidak diatur ke ROW. Untuk mengatasi masalah ini, ikuti langkah-langkah berikut.

  1. Login ke server tempat database sumber MySQL yang dikelola sendiri berjalan.

  2. Modifikasi file konfigurasi MySQL my.cnf untuk mengatur parameter binlog_format ke ROW.

    log_bin=mysql_bin
    binlog_format=ROW  # Atur format log biner ke ROW.
    server_id=2 # Ini harus berupa bilangan bulat lebih besar dari 1. Ini adalah nilai contoh.
    binlog_row_image=full # Parameter ini diperlukan jika database sumber menjalankan MySQL 5.6 atau lebih baru.
    Catatan

    Jalur default file konfigurasi my.cnf adalah /etc/my.cnf. Jalur aktual dapat berbeda berdasarkan instalasi Anda.

  3. Restart MySQL dengan menjalankan perintah berikut.

    [$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
    [$Mysql_Dir]/bin/safe_mysqld &
    Catatan

    Ganti [$Mysql_Dir] dengan direktori instalasi MySQL.

  4. Login ke database sumber MySQL yang dikelola sendiri dan jalankan pernyataan SQL berikut untuk memverifikasi bahwa format log biner diatur ke ROW.

    SHOW variables LIKE "%binlog_format%";

    Output berikut menunjukkan bahwa format log biner diatur ke ROW:

    MariaDB [(none)]> show variables like "%binlog_format%";
    +-----------------+-------+
    | Variable_name   | Value |
    +-----------------+-------+
    | binlog_format   | ROW   |
    +-----------------+-------+
    1 row in set (0.01 sec)
  5. Jalankan precheck DBS lagi.

Pemeriksaan binlog_row_image gagal

Skenario: Precheck untuk parameter binlog_row_image database sumber gagal.

Solusi: Pemeriksaan ini berlaku untuk MySQL 5.6 atau lebih baru. Pemeriksaan ini memverifikasi apakah parameter binlog_row_image diatur ke full. Kegagalan menunjukkan bahwa log biner tidak mencatat gambar baris lengkap. Untuk mengatasi masalah ini, ikuti langkah-langkah berikut.

  1. Login ke server yang menghosting database sumber MySQL yang dikelola sendiri.

  2. Modifikasi file konfigurasi MySQL my.cnf untuk mengatur parameter binlog_row_image ke full.

    log_bin=mysql_bin
    binlog_format=row  # Atur format binlog ke row.
    server_id=2 # Harus berupa bilangan bulat lebih besar dari 1. Ini adalah nilai contoh.
    binlog_row_image=full # Parameter ini diperlukan jika database sumber adalah MySQL 5.6 atau lebih baru.
    Catatan

    Jalur default file konfigurasi my.cnf adalah /etc/my.cnf. Jalur aktual dapat berbeda.

  3. Jalankan perintah berikut untuk restart MySQL.

    [$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
    [$Mysql_Dir]/bin/safe_mysqld &
    Catatan

    Ganti [$Mysql_Dir] dengan direktori instalasi MySQL Anda.

  4. Login kembali ke database sumber MySQL yang dikelola sendiri dan jalankan pernyataan SQL berikut untuk memastikan bahwa parameter binlog_row_image diatur ke full.

    show variables like "%binlog_row_image%";
  5. Jalankan precheck lagi.

Pemeriksaan server_id database sumber gagal

Skenario: Pemeriksaan server_id gagal untuk database sumber.

Solusi: Saat Anda memulai tugas migrasi data inkremental MySQL, pemeriksaan server_id dilakukan pada database sumber selama fase precheck. Bagian berikut menjelaskan cara mengatasi kegagalan pemeriksaan server_id untuk database sumber MySQL yang dikelola sendiri.

  1. Login ke server database MySQL yang dikelola sendiri dan jalankan pernyataan SQL berikut untuk memeriksa nilai parameter server_id.

    SHOW variables LIKE '%server_id%';
  2. Parameter server_id harus diatur ke bilangan bulat lebih besar dari 1. Jalankan pernyataan SQL berikut untuk memodifikasi nilai server_id.

    SET global server_id=[$ID];
    Catatan
    • Ganti [$ID] dengan bilangan bulat lebih besar dari 1. Pastikan ID tersebut unik dan tidak digunakan oleh server database lain.

    • Jika database yang dikelola sendiri Anda berada dalam mode primer/sekunder, pastikan perubahan ini tidak memengaruhi replikasi primer-sekunder.

    • Setelah menjalankan pernyataan ini, Anda juga harus memodifikasi nilai server_id dalam file konfigurasi. Jika tidak, restart akan mengembalikan perubahan ini.

  3. Jalankan ulang precheck.

Pemeriksaan log biner database sumber gagal

Skenario: Saat Anda memulai jadwal backup untuk database MySQL yang dikelola sendiri, pemeriksaan log biner gagal.

Solusi:

  1. Jalankan perintah berikut di CLI MySQL untuk memeriksa apakah binary logging diaktifkan:

    SHOW variables LIKE 'log_%';
  2. Jika nilai 'log_bin' dalam output adalah 'OFF', binary logging dinonaktifkan. Untuk mengaktifkannya pada sistem Linux, edit file konfigurasi my.cnf menggunakan perintah 'vim':

    mysql> show variables like 'log_%';
    +-----------------------------------------+---------------------+
    | Variable_name                           | Value               |
    +-----------------------------------------+---------------------+
    | log_bin                                 | OFF                 |
    | log_bin_basename                        |                     |
    | log_bin_index                           |                     |
    | log_bin_trust_function_creators         | OFF                 |
    | log_bin_use_v1_row_events               | OFF                 |
    | log_builtin_as_identified_by_password   | OFF                 |
    | log_error                               | /var/log/mysqld.log |
    | log_error_verbosity                     | 3                   |
    | log_output                              | FILE                |
    | log_queries_not_using_indexes           | OFF                 |
    | log_slave_updates                       | OFF                 |
    | log_slow_admin_statements               | OFF                 |
    | log_slow_slave_statements               | OFF                 |
    | log_statements_unsafe_for_binlog        | ON                  |
    | log_syslog                              | OFF                 |
    | log_syslog_facility                     | daemon              |
    | log_syslog_include_pid                  | ON                  |
    | log_syslog_tag                          |                     |
    | log_throttle_queries_not_using_indexes  | 0                   |
    | log_timestamps                          | UTC                 |
    | log_warnings                            | 2                   |
    +-----------------------------------------+---------------------+
    21 rows in set (0.00 sec)
    # Buka file /etc/my.cnf.
    vim /etc/my.cnf
    
    # Tekan i untuk memasuki mode edit.
    # Tambahkan parameter berikut.
    log_bin = mysql_bin
    binlog_format = row
    server_id = 2
    expire_logs_days = 30
    
    # Tekan Esc untuk keluar dari mode edit, lalu masukkan :wq untuk menyimpan perubahan dan keluar.
  3. Restart database MySQL yang dikelola sendiri.

    systemctl restart mysqld
    Catatan

    Perubahan file konfigurasi hanya berlaku setelah Anda me-restart instansiasi database. Kami menyarankan untuk me-restart instansiasi database yang dikelola sendiri selama jam sepi.

    Setelah MySQL direstart, jalankan perintah di Langkah 1 untuk memverifikasi bahwa binary logging diaktifkan. Kemudian, restart jadwal backup.

Pemeriksaan mesin penyimpanan gagal

Solusi: Pemeriksaan ini menentukan apakah database sumber menggunakan mesin penyimpanan yang tidak didukung untuk migrasi data inkremental. Migrasi data inkremental dari MySQL ke MySQL tidak mendukung mesin penyimpanan FEDERATED dan MRG_MyISAM. Jika pemeriksaan gagal, artinya tabel yang akan dimigrasikan menggunakan salah satu mesin penyimpanan tersebut.

Di halaman Configure Task jadwal backup, klik Edit Backup Objects. Hapus database dan tabel yang menggunakan mesin penyimpanan yang tidak didukung, lalu jalankan ulang backup.

Catatan

Setelah perubahan pada objek backup Anda berlaku, sistem segera memulai backup baru. Proses ini dapat memengaruhi database sumber dan beban kerja Anda. Kami menyarankan agar Anda memodifikasi konfigurasi selama jam sepi.

Pemeriksaan format password MySQL

Skenario: Precheck untuk jadwal backup atau tugas pemulihan gagal.

Solusi: Terdeteksi format password lama. Lihat old_passwords.

Konflik nama objek

Skenario: Objek yang Anda pilih untuk dipulihkan memiliki nama yang sama dengan objek database yang sudah ada di tujuan.

Solusi: Konfigurasikan tugas pemulihan baru dan pilih Rename Object with the Same Name atau klik Edit untuk mengganti nama objek tujuan. Anda kemudian dapat menghapus tugas pemulihan yang gagal.

Kesalahan umum untuk tugas unduh lanjutan

Gejala: Di halaman detail Backup and Restoration untuk sebuah instans di konsol ApsaraDB RDS, Anda tidak dapat mengklik tombol Download Instance Backup File untuk membuat tugas unduh lanjutan.

DBS-DownloadTask.Region

Penyebab: Fitur ini tidak tersedia di wilayah saat ini.

Solusi: Hubungi tim dukungan kami di grup DingTalk (ID: 35585947) untuk meminta fitur ini.

DBS-DownloadTask.InstanceInfo

Penyebab: Layanan unduh gagal mengambil informasi tentang instans ApsaraDB RDS.

Solusi: Periksa apakah instans ApsaraDB RDS berada dalam kondisi abnormal atau telah dihapus.

DBS-DownloadTask.DbType

Penyebab: Mesin database instans ApsaraDB RDS tidak mendukung fitur unduh lanjutan.

Solusi: Fitur unduh lanjutan hanya tersedia untuk ApsaraDB RDS for MySQL dan ApsaraDB RDS for PostgreSQL.

DBS-DownloadTask.CustinId

Penyebab: Fitur ini belum diaktifkan untuk instans ApsaraDB RDS Anda.

Solusi: Fitur ini mungkin sedang dalam masa rilis bertahap dan belum tersedia untuk instans Anda. Anda dapat menghubungi dukungan teknis di grup dukungan pelanggan (grup DingTalk ID: 35585947) dan menyampaikan kebutuhan Anda.

DBS-DownloadTask.CustinName

Penyebab: Fitur ini belum diaktifkan untuk instans ApsaraDB RDS Anda karena sedang dalam masa peluncuran bertahap.

Solusi: Untuk meminta akses, hubungi dukungan teknis di grup DingTalk (ID: 35585947).

DBS-DownloadTask.user

Penyebab: Fitur ini tidak diaktifkan untuk instans ApsaraDB RDS Anda.

Solusi: Fitur ini mungkin sedang dalam periode rilis bertahap dan belum tersedia untuk instans Anda. Anda dapat menghubungi dukungan teknis di grup DingTalk (ID Grup: 35585947) untuk mengajukan permintaan Anda.

DBS-DownloadTask.Instance.Version

Penyebab yang mungkin terjadi: Versi mesin minor instans ApsaraDB RDS sudah usang.

Solusi: Versi mesin minor instans Anda harus 20201031 atau lebih baru. Untuk meningkatkan versi mesin minor, lihat Tingkatkan versi mesin minor. Jika Anda mengalami masalah selama peningkatan, hubungi dukungan teknis ApsaraDB RDS.

Catatan

Untuk informasi lebih lanjut, lihat Prasyarat untuk mengunduh backup.

DBS-DownloadTask.Instance.Storage.Type

Penyebab: Jenis penyimpanan instans ApsaraDB RDS Anda tidak mendukung fitur unduh lanjutan.

Solusi: Hanya instans yang menggunakan cloud disk yang mendukung fitur unduh lanjutan. Buka halaman Basic Information instans ApsaraDB RDS Anda untuk memverifikasi bahwa Storage Type adalah cloud disk.

DBS-DownloadTask.Instance.Param

Penyebab: Fitur unduh lanjutan tidak tersedia karena pengaturan parameter yang salah pada instans ApsaraDB RDS.

Solusi: Pastikan versi mesin minor instans ApsaraDB RDS Anda tidak usang dan data backup tidak dienkripsi. Untuk detailnya, lihat Prasyarat untuk unduh lanjutan.

DBS-DownloadTask

Penyebab yang mungkin terjadi: Instans ApsaraDB RDS tidak mendukung fitur unduh lanjutan.

Solusi: Pastikan instans ApsaraDB RDS Anda memenuhi prasyarat untuk fitur unduh lanjutan. Untuk informasi lebih lanjut, lihat topik berikut:

Catatan

Sebelum menggunakan fitur unduh lanjutan, baca dokumentasi untuk memahami detailnya, termasuk batasan-batasannya.

Kesalahan tugas umum

DBS-000000

Skenario: Backup penuh fisik gagal.

Penyebab: Layanan tidak dapat terhubung ke gateway backup yang ditentukan dalam jadwal backup, dan tugas gagal setelah mencapai maksimum 100 kali percobaan ulang. Penyebab umum adalah gateway backup offline.

Contoh:

DBS-000000 Scheduling failed, the task has been retried, exceeding the maximum limit

Solusi:

  1. Di halaman Configure Task untuk jadwal backup target, periksa apakah status gateway backup adalah Offline.

  2. Di panel navigasi kiri, klik Backup Gateways. Di halaman Backup Gateways, temukan gateway target berdasarkan Backup Gateway Hostname-nya. Verifikasi bahwa alamat IP, hostname, dan waktu heartbeat terakhir benar. Status saat ini ditampilkan di kolom Status.

  3. Periksa status berjalan dan konfigurasi jaringan server tempat gateway backup diinstal.

    Jika server berjalan dengan benar dan koneksi jaringan stabil, restart gateway backup. Beberapa versi gateway backup yang lebih lama mungkin memiliki kerentanan. Kami menyarankan untuk meningkatkan gateway backup. Untuk informasi lebih lanjut, lihat tingkatkan gateway backup.

    Catatan

    Jika gateway backup masih gagal dimulai setelah menyelesaikan langkah-langkah ini, hubungi dukungan teknis di grup DingTalk.

DBS-000001

Skenario: Tugas backup penuh logis gagal.

Penyebab: Tugas gagal setelah melebihi batas maksimum percobaan ulang.

Contoh:

DBS-000001 Scheduling failed, the task has been retried, exceeding the maximum limit or hang more than 7 hours

Solusi: Restart tugas dan pantau statusnya. Jika kesalahan berlanjut, hubungi dukungan di grup DingTalk.

DBS-000002

Skenario: Kegagalan selama backup skema logis atau backup penuh.

Penyebab: Tidak ada sumber daya layanan yang tersedia.

Contoh:

DBS-000002 Because the current system has no available resources, scheduling timeout...

Solusi: Hubungi dukungan teknis di grup DingTalk untuk mendiagnosis kegagalan.

DBS-000003

Skenario: Tugas link gagal.

Penyebab: Tidak ditemukan instans untuk tugas tersebut.

Contoh:

DBS-000003  No instance was found for this task

Solusi: Hubungi dukungan teknis di grup DingTalk untuk bantuan.

DBS-000004

Skenario: Tugas backup atau pemulihan fisik gagal dimulai.

Penyebab: Terjadi pengecualian saat menjadwalkan tugas backup atau pemulihan fisik.

Contoh:

DBS-000004 + [Detailed error message]

Solusi: Coba ulang tugas tersebut. Jika kesalahan berlanjut, hubungi dukungan teknis di grup DingTalk.

DBS-000005

Skenario: Tugas backup atau pemulihan logis gagal dimulai.

Penyebab: Terjadi kesalahan penjadwalan.

Contoh:

DBS-000005 + [Detailed error message]

Solusi: Coba ulang tugas tersebut. Jika kesalahan berlanjut, hubungi dukungan teknis di grup DingTalk.

DBS-000006

Skenario: Tugas backup atau pemulihan fisik mengalami timeout sebelum dimulai.

Penyebab: Tugas gagal dimulai karena kesalahan penjadwalan atau masalah sumber daya.

Contoh:

DBS-000006 + [Detailed error message]

Solusi: Coba ulang tugas yang gagal. Jika tugas gagal lagi, hubungi dukungan teknis di grup DingTalk.

DBS-000007

Skenario: Terjadi timeout saat memulai tugas backup atau pemulihan logis.

Penyebab: Terjadi kesalahan penjadwalan atau masalah sumber daya selama startup tugas.

Contoh:

DBS-000007 + [Detailed error message]

Solusi: Restart tugas yang gagal. Jika kesalahan berlanjut, hubungi dukungan melalui grup pelanggan.

DBS-002003

Skenario: Backup penuh fisik native database SQL Server gagal.

Penyebab: Database tidak dapat diakses. Hal ini dapat terjadi jika Anda tidak memiliki izin database yang diperlukan, database tidak ada, atau statusnya mencegah akses.

Contoh:

DBS-002003, message:User does not have permission to alter database 'UFTData305999_000002', the database does not exist, or the database is not in a state that allows access checks..
DBS-002003, message:User does not have permission to alter database 'UFDATA
DBS-002003, message:User 'guest' does not have permission to run DBCC LOGIN
DBS-002003 ["The TCP/IP connection to the host localhost, port 1433 has failed. Error: "Connection refused: connect. Verify the connection properties, check that an instance of SQL Server is running on the host and accepting TCP/IP connections at the port, and that no firewall is blocking TCP connections to the port."."].

Solusi:

  1. Verifikasi bahwa database sedang online. Jika offline, bawa ke status online.

  2. Jika database sedang dipulihkan, tunggu hingga pemulihan selesai sebelum Anda me-restart tugas.

  3. Periksa apakah koneksi dienkripsi.

    SELECT encrypt_option FROM sys.dm_exec_connections WHERE session_id = @@SPID
  4. Periksa registri untuk melihat apakah enkripsi Transport Layer Security (TLS) diaktifkan.

    HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.x\Server
    ## 1.x menunjukkan versi TLS, misalnya, 1.0, 1.1, 1.2, atau 1.3.

    Jika entri registri ini ada dan nilainya adalah 1, enkripsi TLS diaktifkan. Untuk menonaktifkan enkripsi TLS, ikuti langkah-langkah berikut:

    1. Ubah nilai entri registri dari 1 menjadi 0.

    2. Di kotak pencarian Start Windows, cari Internet Options. Klik tab Advanced, gulir ke bawah, kosongkan kotak centang untuk Use TLS 1.0, Use TLS 1.1, Use TLS 1.2, dan Use TLS 1.3, lalu klik OK. Perubahan berlaku setelah Anda me-restart komputer.

    3. Restart komputer Anda dan coba ulang tugas backup.

DBS-002009

Skenario: Backup skema gagal.

Penyebab yang mungkin terjadi:

  • Nama akun database atau password salah.

  • Izin akun database telah berubah, atau database membatasi akses dari IP sumber.

  • Aturan firewall database atau servernya telah berubah.

  • Masalah konektivitas jaringan, misalnya, pemetaan jaringan telah berubah.

Contoh:

DBS-002009 com.alibaba.dts.exception.message.LocalException: DBS-002009 Connect db jdbc:mysql://*:*?useSSL=false timeout.

Solusi: Untuk troubleshooting, lihat bagian "Gagal menguji koneksi ke database sumber" dalam topik ini. Pertama, periksa apakah koneksi gagal karena perubahan nama akun database, password, izin akun, IP sumber, atau aturan firewall. Jika pengaturan ini tidak berubah, periksa dan hasilkan ulang pemetaan jaringan:

  1. Buka halaman Configure Task jadwal backup target dan klik Edit Backup Objects di pojok kanan atas bagian Basic Information.

  2. Masukkan kembali nama akun database dan password, lalu klik Test Connection.

    Selama uji koneksi, sistem memeriksa dan menghasilkan ulang pemetaan jaringan di latar belakang sesuai kebutuhan. Halaman konfigurasi mencakup bidang untuk nama akun database dan password. Untuk metode koneksi, Anda dapat memilih koneksi tidak terenkripsi atau koneksi aman SSL.

    Catatan

    Jika uji koneksi masih gagal meskipun konfigurasi database sumber benar, hubungi dukungan teknis di grup DingTalk.

  3. Setelah uji koneksi berhasil, klik Next.

  4. Pilih ulang database dan tabel yang akan di-backup dan klik Save untuk memperbarui jadwal backup.

    Setelah Anda mengklik Save, konfigurasi baru berlaku dan backup segera dimulai. Tindakan ini dapat memengaruhi database sumber dan beban kerja Anda. Kami menyarankan mengubah konfigurasi selama jam sepi.

DBS-102001

Skenario: Dapat terjadi dalam berbagai situasi.

Penyebab: Backup selesai, tetapi pelaporan objek backup ke metadatabase gagal. Ini adalah masalah umum dengan backup skema. Mencoba ulang tugas mungkin menyelesaikan masalah.

Contoh:

DBS-102001 java.lang.IllegalStateException: The RecordSplit must be in FAILED or SUCCE

Solusi: Coba ulang tugas tersebut. Jika masalah berlanjut, hubungi dukungan teknis di grup DingTalk.

DBS-105001

Skenario: Kesalahan ini dapat terjadi selama berbagai operasi.

Penyebab: Pelaporan heartbeat ke metadatabase mengalami timeout.

Contoh:

DBS-105001 com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Could not create connection to database server. Attempted reconnect 3 times. Giving up.
com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Too many connections

Solusi: Coba ulang tugas tersebut. Jika masalah berlanjut, hubungi dukungan teknis di grup DingTalk.

DBS-106001

Skenario: Kesalahan ini dapat terjadi pada berbagai tahap.

Penyebab yang mungkin terjadi: Kesalahan internal OSS.

Contoh:

DBS-106001 java.lang.RuntimeException: com.taobao.amp.error.RequestError: Please conta...
DBS-106001  error task count 2 reached to the max limit.

Solusi: Untuk bantuan, hubungi kami di grup DingTalk.

DBS-202002

Skenario: Tugas gagal melakukan backup data ke bucket OSS milik pelanggan.

Penyebab: Layanan OSS ditangguhkan karena pembayaran tertunda.

Contoh:

DBS-202002 java.io.IOException: com.taobao.amp.error.RequestError: UserDisable

Solusi:

  • Di halaman Backup Task Configuration untuk rencana backup target, periksa apakah rencana backup Anda saat ini menggunakan bucket OSS milik pelanggan. Anda dapat mengonfirmasi ini dengan memeriksa bidang Backup Storage OSS Bucket di bagian Basic Information. Jika Anda menggunakan bucket OSS milik pelanggan, periksa tagihan OSS Anda untuk pembayaran tertunda. Setelah membayar tagihan, coba ulang tugas backup.

  • Jika Anda tidak menggunakan bucket OSS milik pelanggan, hubungi dukungan teknis di grup DingTalk.

DBS-203101

Skenario: Backup penuh fisik native database SQL Server gagal.

Penyebab yang mungkin terjadi:

  • Database tidak berjalan.

  • Enkripsi SSL diaktifkan untuk database.

Contoh:

DBS-203101 Connect db failure

Solusi:

  1. Gunakan SQL Server Management Studio (SSMS) untuk login menggunakan nomor port dan verifikasi bahwa database ada dan berjalan.

    Secara default, Anda dapat login tanpa nomor port. Untuk menentukan nomor port, tambahkan setelah hostname dengan koma, misalnya, localhost,1433.

    Catatan

    Hanya koneksi TCP yang didukung.

  2. Pastikan enkripsi SSL tidak diaktifkan untuk database. Buka SQL Server Configuration Manager. Di panel kiri, navigasi ke SQL Server network configuration > protocols for MSSQLSERVER. Klik kanan dan pilih properties. Di tab flags, periksa apakah force encryption diatur ke yes. Jika diatur ke yes, ubah menjadi no.

DBS-203102

Skenario: Backup fisik native database SQL Server gagal.

Penyebab yang mungkin terjadi:

  • Database dihapus.

  • Database sumber diganti namanya.

  • Database berada dalam kondisi abnormal dan tidak dapat di-backup.

Contoh:

DBS-203102 Could not find database ......

Solusi:

  1. Periksa apakah database dihapus. Jika ya, konfigurasi ulang objek backup.

    Di halaman Configure Task untuk jadwal backup target, klik Edit Backup Objects di bagian Basic Information.

    Catatan

    Menyimpan konfigurasi baru segera memulai backup. Proses ini dapat memengaruhi database sumber dan operasi bisnis Anda.

  2. Periksa apakah database sumber diganti namanya. Jika ya, ikuti instruksi pada langkah sebelumnya untuk mengonfigurasi ulang objek backup.

  3. Pastikan database sedang online.

  4. Jika database sedang dalam proses recovery, tunggu hingga recovery selesai, lalu restart tugas.

  5. Jika fitur auto-close database diaktifkan, atur ke False. Di SQL Server Management Studio (SSMS), klik kanan database target dan pilih Properties. Di halaman Options, temukan pengaturan di bagian Auto.

DBS-203103

Skenario: Backup penuh fisik native database SQL Server gagal.

Penyebab: Server database dimatikan.

Contoh:

DBS-203103 The database server already shutdown

Solusi: Mulai layanan database.

DBS-203104

Skenario: Backup penuh fisik native database SQL Server gagal.

Penyebab: Masalah dengan komponen VDI.

Contoh:

DBS-203104 Wait VDI timeout 30s

Solusi: Periksa event Windows untuk troubleshooting masalah dengan komponen VDI. Setelah menyelesaikan masalah, coba ulang tugas. Jika Anda tidak menemukan masalah, tunggu beberapa saat lalu coba ulang backup. Jika kesalahan berlanjut, hubungi grup DingTalk untuk bantuan.

DBS-203201

Skenario: Kesalahan ini terjadi selama backup penuh fisik native database SQL Server.

Penyebab yang mungkin terjadi:

  • Banyak tugas backup berjalan secara bersamaan untuk database yang sama.

  • Kesalahan disebabkan oleh pemotongan log. Penyebab yang mungkin termasuk:

    • Backup bersamaan oleh tool lain.

    • Operasi shrink database baru-baru ini.

    • Perubahan model recovery database.

    • Tindakan lain yang dapat menyebabkan pemotongan log.

Contoh:

DBS-203201 database xxx backupable lsn {1} exceeded limit {2}
database XXXXXX  backupable lsn 10000000000000000009 exceeded limit 10000000000000000001,,already increment backup name:,backup datetime:2024-01-19 00:00:00

Solusi:

  • Banyak tugas backup berjalan secara bersamaan untuk database yang sama.

    • Jika banyak tugas backup dikonfigurasi untuk berjalan pada database yang sama secara bersamaan, tangguhkan tugas lain untuk memastikan hanya satu tugas yang berjalan pada satu waktu.

    • Jika Anda menggunakan skrip untuk backup terjadwal, pastikan tidak ada tugas backup lain yang berjalan bersamaan pada database yang sama.

    • Jika tugas backup inkremental yang mencakup banyak database gagal untuk beberapa di antaranya, nonaktifkan lalu aktifkan kembali tugas tersebut.

  • Kesalahan disebabkan oleh pemotongan log.

    • Backup tidak lengkap karena pemotongan log. Mulai backup penuh baru dari konsol.

DBS-203202

Skenario: Backup inkremental database SQL Server gagal.

Penyebab yang mungkin terjadi:

  • Backup inkremental dimulai sebelum backup penuh selesai. Masalah ini mungkin terjadi saat Anda mengonfigurasi tugas backup untuk pertama kali.

  • Opsi CopyOnly dipilih dalam konfigurasi tugas backup. Backup penuh yang dibuat dengan opsi ini tidak dapat berfungsi sebagai dasar untuk backup inkremental.

Contoh:

DBS-203202 BACKUP LOG {0} cannot be performed because there is no current database backup

Solusi: Jalankan secara manual backup penuh lalu restart backup inkremental yang gagal.

DBS-203203

Skenario: Terjadi kesalahan selama backup penuh fisik native database SQL Server.

Penyebab: Backup log transaksi tidak didukung karena model recovery database tidak diatur ke FULL.

Contoh:

DBS-203203 Only support increment trnsaction log backup in FULL MODE, database {0}

Solusi: Jalankan pernyataan SQL berikut untuk mengubah model recovery ke FULL:

ALTER DATABASE [your_database_name] SET RECOVERY FULL

DBS-203205

Skenario: Backup penuh fisik native database SQL Server gagal.

Penyebab: Database sedang offline.

Contoh:

DBS-203205 database  state is; DBS-203205 database AIS20210425120342 state is {1}

Solusi:

  • Verifikasi bahwa database sedang online. Jika tidak, bawa ke status online.

  • Jika database sedang dipulihkan, tunggu hingga pemulihan selesai sebelum Anda me-restart tugas.

DBS-203206

Skenario: Backup penuh fisik native database SQL Server gagal.

Penyebab: Database tidak dapat dibuka karena tidak tersedia atau rusak.

Contoh:

DBS-203206 message:Database 'UFTData992044_000002' cannot be opened due to

Solusi:

  • Pastikan database sedang online.

  • Jika database sedang dipulihkan, tunggu hingga recovery selesai sebelum me-restart tugas.

DBS-203240

Skenario: Backup penuh fisik native SQL Server.

Penyebab: Akun tidak memiliki izin sysadmin.

Contoh:

DBS-203240, message:User 'guest' does not have permission to run DBCC LOGIN

Solusi: Perbarui jadwal backup untuk menggunakan akun dengan izin yang diperlukan, atau berikan izin sysadmin ke akun saat ini. Untuk detail tentang mengubah akun database, lihat Ubah database sumber untuk backup.

DBS-203301

Skenario: Pemulihan penuh database SQL Server gagal.

Penyebab yang mungkin terjadi: Untuk mencegah kehilangan data, Anda harus melakukan backup tail log sebelum memulihkan database. Kesalahan ini terjadi jika tail log belum di-backup.

Catatan

Tail log berisi catatan log transaksi yang dihasilkan sejak backup log terakhir.

Contoh:

DBS-203301 The tail of the log for the database {0} has not been backed up. Use BACKUP LOG WITH NORECOVERY to backup the log if it contains work you do not want to lose. Use the WITH REPLACE or WITH STOPAT clause of the RESTORE statement to just overwrite the contents of the log

Solusi:

  1. Untuk melakukan backup tail log, jalankan perintah berikut.

    BACKUP LOG [Name of the database to restore] TO DISK='C:\backupdir\moyun_test.trn' WITH NORECOVERY;
  2. Restart tugas pemulihan penuh yang gagal.

DBS-203302

Skenario: Pemulihan dari backup penuh fisik native database SQL Server gagal.

Penyebab: Backup log transaksi berakhir di LSN {0}, yang lebih awal dari LSN {1} yang diperlukan untuk melanjutkan pemulihan. Hal ini menunjukkan adanya celah dalam rantai backup log.

Contoh:

DBS-203302 the log in this backup set terminates at LSN {0}, which is too early to apply to the database. A more recent log backup that includes LSN {1} can be restored

Solusi: Hubungi dukungan teknis di grup DingTalk untuk bantuan.

DBS-301005

Skenario: Backup penuh fisik instans Oracle gagal.

Penyebab: Instans Oracle tidak dalam mode arsip, yang diperlukan untuk backup penuh fisik.

Contoh:

DBS-301005, message:INNER_ERROR[301005]:database is no archive mode
DBS-301005, message:INNER_ERROR[301005]:user="" ConnectString="" standalone params= ......

Solusi: Aktifkan mode arsip. Untuk instruksi detail, lihat Aktifkan mode arsip.

DBS-301502

Skenario: Terjadi kesalahan selama backup fisik MySQL.

Penyebab: Operasi DDL yang tidak dapat dicatat dalam redo log dieksekusi selama backup.

Contoh:

DBS-301502, without redo logging

Solusi: Coba ulang backup saat tidak ada operasi DDL yang berjalan.

DBS-301503

Skenario: Backup fisik MySQL gagal.

Penyebab: Kecepatan pembuatan redo log melebihi kecepatan backup.

Contoh:

DBS-301503, log copying being too slow

Solusi: Tingkatkan ukuran file redo dan jadwalkan backup selama jam sepi.

DBS-301504

Skenario: Backup fisik instans MySQL gagal.

Penyebab: Kesalahan ini terjadi karena satu atau lebih tabel dalam instans MySQL memiliki enkripsi yang diaktifkan, fitur yang tidak didukung oleh Database Backup Service.

Contoh:

DBS-301504, missing encryption

Solusi: Nonaktifkan enkripsi dan coba ulang backup. Jika Anda lebih memilih untuk tidak menonaktifkan enkripsi, hubungi layanan pelanggan untuk meminta pengembalian dana untuk jadwal backup.

DBS-301505

Skenario: Backup fisik database MySQL gagal.

Penyebab: Sistem menghentikan proses backup.

Contoh:

DBS-301505, signal: terminated

Solusi: Restart tugas.

DBS-302035

Skenario: Backup penuh fisik database Oracle gagal.

Penyebab: Tidak dapat memperoleh peran instans Oracle.

Contoh:

DBS-302035 USER_CAN_NOT_LOAD_INSTANCE_ROLE[302035]

Solusi:

  1. Login ke server yang menghosting instans database.

  2. Jalankan perintah berikut untuk login ke database sebagai administrator sistem:

    sqlplus / as sysdba
  3. Jalankan pernyataan SQL berikut untuk memeriksa apakah hasil dikembalikan:

    select database_role from v$database;

    Jika tidak ada hasil yang dikembalikan, selidiki penyebabnya. Jika hasil dikembalikan, hubungi dukungan di grup DingTalk.

DBS-400001

Skenario: Backup penuh fisik native atau tugas konversi data penuh gagal.

Penyebab: Tugas kehabisan memori karena spesifikasi jadwal backup tidak mencukupi.

Contoh:

DBS-400001 , message :Java heap space. 
DBS-400001 java.lang.OutOfMemoryError: Java heap space

Solusi: Tingkatkan spesifikasi jadwal backup. Untuk sementara meningkatkan batas memori untuk tugas mendesak, seperti tugas pemulihan, hubungi dukungan teknis di grup DingTalk. Untuk instruksi, lihat Tingkatkan jadwal backup.

DBS-999999 atau tanpa kode kesalahan

Skenario: Terjadi kesalahan selama tugas apa pun.

Penyebab: Pengecualian tidak terdefinisi, atau sistem gagal mengembalikan kode kesalahan yang sesuai.

Contoh:

DBS-999999 + [error message]

Solusi: Salin pesan kesalahan dan cari di topik ini untuk melihat apakah kode kesalahan berbeda menggambarkan masalah tersebut. Jika Anda tidak dapat menemukan solusi, hubungi dukungan teknis di grup DingTalk.