Documentation
Home Page Data Management Support FAQ Common errors and troubleshooting for Data Disaster Recovery (DBS)

Common errors and troubleshooting for Data Disaster Recovery (DBS)

Updated at:
Copy as MD

This topic describes errors, such as exception messages and error codes, that you might encounter while configuring a backup schedule, running a precheck, or executing a restore job, and explains how to resolve them.

Note

If you encounter an error not described in this topic, or if the provided solution does not resolve the issue, contact technical support via the DingTalk group (ID: 35585947).

Errors

Backup schedule configuration errors

Source database connection test failure

Backup and restore precheck errors

Advanced download task errors

Task execution errors

Backup schedule errors

Source database connection failed

Scenario: A connection test fails while you configure a backup schedule.

Possible causes:

  • The database account or password is incorrect.

  • Access to the database is restricted by source IP address.

  • Firewall restrictions on the source database's server or network.

  • Network connectivity issues.

Solution:

  1. Click Check in the console to view details of the connection failure. The Check dialog box displays diagnostic results for MySQL JDBC Connect and Telnet. Use the diagnostic results and error messages to determine the cause of the failure.

  2. Check if the following diagnostic checks passed.

    • First, check whether the database account or password is incorrect or the database has restricted access from the source IP.

      1. Verify the database account and password.

        From a client that can connect to the source database, use the database account and password specified in the backup schedule to verify the credentials. If the credentials are incorrect, update them in the backup schedule configuration and test the connection again.

      2. If the account and password are correct, the database may be restricting access based on source IP address.

        • If the source database is MySQL, use a MySQL client to connect to it and run the following SQL statement. Then, check the output to confirm that the authorized IP address list allows remote access.

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

          Replace [$Username] with the database account specified in your backup schedule.

        • If the source database is SQL Server:

          • If the backup gateway is installed on the source database server, set Address to localhost.

          • Check if a firewall is configured on the SQL Server host, or if an endpoint or trigger in the source database restricts access by IP address.

        • If the source database is Oracle, check its sqlnet.ora configuration file to confirm whether the TCP.VALIDNODE_CHECKING parameter is set to YES. If the value is YES, the source database restricts access based on source IP addresses.

    • Then, check whether the server and network that host the database have firewall restrictions or there are network communication issues.

      1. Check if a firewall is enabled on the source database server and if firewall policies are configured.

        • If the source database is installed on a Windows server, open the Control Panel, navigate to Windows Defender Firewall, and check if any firewall policies are configured.

        • If the source database is installed on a Linux server, run the iptables -L command to check if firewall policies are configured.

        • If the database is installed on an Alibaba Cloud ECS instance, refer to the Add a security group rule documentation to check if the security group allows access from the required CIDR block. You can find the CIDR block information in the console.

      2. Check if the network firewall restricts access from the required CIDR block. The following instructions use Cloud Firewall as an example.

        1. Log on to the Cloud Firewall console. In the left-side navigation pane, click Access Control.

        2. Check for any Cloud Firewall policies that block access from the required CIDR block. You can find the CIDR block information in the console.

        Note

        If you have ruled out firewall restrictions but the Telnet check still fails, the cause is likely a network connectivity issue. For assistance, contact support through the DingTalk group.

Backup and restoration precheck errors

Source database connection failed

This error occurs during the precheck for a backup schedule or a restoration task.

Possible causes:

  • The database account or password is incorrect.

  • The database restricts access from the source IP address.

  • A firewall is configured on the database's server or network.

  • Network communication issues exist.

Solution: See the resolution for source database connection test failed, which is described under common errors for backup schedule configuration.

Database permission check failed

Scenario: This error occurs during the precheck for a backup schedule or a restoration task.

Possible causes:

  • The database account for the backup schedule lacks the required permissions to access database data.

  • The database account for the restoration task lacks permissions to write data or modify the database schema.

Solution: Check the permissions of the database account. If they are insufficient, grant the required permissions to the account or use a different account that has them.

Note

  • For backup schedules: To change the database account, see Modify the backup source.

  • For restoration tasks: Configure a new restoration task, and then delete the original one that failed the precheck.

OSS check failed

Scenario: A precheck for a backup schedule or restoration task fails.

Possible causes:

  • The backup storage is a user-owned OSS bucket, but Data Disaster Recovery has not been granted service authorization to access it.

  • An internal service issue has occurred.

Solution:

  • On the Configure Task page for the target backup schedule, check the Backup Storage OSS Bucket field in the Basic Information section to see if a user-owned OSS bucket is used. If so, sign in to the OSS console to verify that the bucket shown in the Data Disaster Recovery console exists and that service authorization has been granted.

  • If an internal service issue occurs, contact technical support in the DingTalk group.

Source database binlog precheck fails

Scenario: The source database binlog precheck fails.

Solution: This precheck verifies that the binary logging feature is enabled on the source database. A failed precheck indicates that the feature is disabled. To resolve this issue, follow these steps.

  1. Log on to the server that hosts your self-managed MySQL source database.

  2. Modify the following settings in the MySQL configuration file my.cnf.

    log_bin=mysql_bin
binlog_format=row
server_id=2 # Must be an integer greater than 1. This is an example value.
binlog_row_image=full # This parameter is required if the source database runs MySQL 5.6 or later.
    Note

    The default path of the my.cnf configuration file is /etc/my.cnf. The actual path may vary depending on your installation.

  3. Restart the MySQL service by running the following commands.

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

    Replace [$Mysql_Dir] with the MySQL installation directory.

  4. Log on to your self-managed MySQL source database and run the following SQL statement to confirm that the binary logging feature is enabled.

    SHOW variables LIKE '%log_bin%';

    The following output indicates that the feature is enabled:

    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. Run the DBS precheck again.

Source binlog format check failed

Scenario: The precheck for the binary log format of the source database fails.

Solution: This check verifies that the binary log format of the source database is set to ROW. If the precheck fails, the format is not set to ROW. To resolve this issue, follow these steps.

  1. Log on to the server where your self-managed MySQL source database is running.

  2. Modify the MySQL configuration file my.cnf to set the binlog_format parameter to ROW.

    log_bin=mysql_bin
binlog_format=ROW  # Set the binary log format to ROW.
server_id=2 # This must be an integer greater than 1. This is an example value.
binlog_row_image=full # This parameter is required if the source database runs MySQL 5.6 or later.
    Note

    The default path of the my.cnf configuration file is /etc/my.cnf. The actual path may vary based on your installation.

  3. Restart MySQL by running the following commands.

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

    Replace [$Mysql_Dir] with the MySQL installation directory.

  4. Log on to your self-managed MySQL source database and run the following SQL statement to verify that the binary log format is set to ROW.

    SHOW variables LIKE "%binlog_format%";

    The following output indicates that the binary log format is set to ROW:

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

  5. Run the DBS precheck again.

binlog_row_image check failed

Scenario: The precheck for the source database's binlog_row_image parameter fails.

Solution: This check applies to MySQL 5.6 or later. It verifies whether the binlog_row_image parameter is set to full. A failure indicates that the binary log does not record full row images. To resolve this issue, follow these steps.

  1. Log on to the server hosting your self-managed MySQL source database.

  2. Modify the MySQL my.cnf configuration file to set the binlog_row_image parameter to full.

    log_bin=mysql_bin
binlog_format=row  # Set the binlog format to row.
server_id=2 # Must be an integer greater than 1. This is an example value.
binlog_row_image=full # This parameter is required if the source database is MySQL 5.6 or later.
    Note

    The default path of the my.cnf configuration file is /etc/my.cnf. The actual path may vary.

  3. Run the following commands to restart MySQL.

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

    Replace [$Mysql_Dir] with your MySQL installation directory.

  4. Log on to your self-managed MySQL source database again and run the following SQL statement to confirm that the binlog_row_image parameter is set to full.

    show variables like "%binlog_row_image%";

  5. Run the precheck again.

Source database server_id check failed

Scenario: The server_id check fails for the source database.

Solution: When you start a MySQL incremental data migration task, a server_id check is performed on the source database during the precheck phase. The following section describes how to resolve a server_id check failure for a self-managed MySQL source database.

  1. Log on to your self-managed MySQL database server and run the following SQL statement to check the value of the server_id parameter.

    SHOW variables LIKE '%server_id%';

  2. The server_id parameter must be set to an integer greater than 1. Run the following SQL statement to modify the server_id value.

    SET global server_id=[$ID];
    Note

    • Replace [$ID] with an integer greater than 1. Ensure the ID is unique and not used by another database server.

    • If your self-managed database is in a primary/secondary mode, ensure that this change does not affect primary-secondary replication.

    • After you run this statement, you must also modify the server_id value in the configuration file. Otherwise, a restart reverts this change.

  3. Rerun the precheck.

Source database binary log check failed

Scenario: When you start a backup schedule for a self-managed MySQL database, the binary log check fails.

Solution:

  1. Run the following command in the MySQL CLI to check if binary logging is enabled:

    SHOW variables LIKE 'log_%';

  2. If the 'log_bin' value in the output is 'OFF', binary logging is disabled. To enable it on a Linux system, edit the my.cnf configuration file using the 'vim' command:

    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)
    # Open the /etc/my.cnf file.
vim /etc/my.cnf

# Press i to enter edit mode.
# Add the following parameters.
log_bin = mysql_bin
binlog_format = row
server_id = 2
expire_logs_days = 30

# Press Esc to exit edit mode, and then enter :wq to save your changes and exit.

  3. Restart the self-managed MySQL database.

    systemctl restart mysqld
    Note

    Configuration file changes take effect only after you restart the database instance. We recommend restarting your self-managed database instance during off-peak hours.

    After MySQL restarts, run the command in Step 1 to verify that binary logging is enabled. Then, restart the backup schedule.

Storage engine check fails

Solution: This check determines if the source database uses a storage engine that is unsupported for incremental data migration. Incremental data migration from MySQL to MySQL does not support the FEDERATED and MRG_MyISAM storage engines. If the check fails, it means the tables to be migrated use one of these storage engines.

On the Configure Task page of the backup schedule, click Edit Backup Objects. Remove the databases and tables that use an unsupported storage engine, and then rerun the backup.

Note

After your changes to the backup objects take effect, the system immediately starts a new backup. This process may affect the source database and your workloads. We recommend that you modify the configuration during off-peak hours.

MySQL password format check

Scenario: The precheck for a backup schedule or a restoration task fails.

Solution: An old password format was detected. See old_passwords.

Object name conflict

Scenario: The object you select to restore has the same name as an existing database object in the destination.

Solution: Configure a new restoration task and select Rename Object with the Same Name or click Edit to rename the destination object. You can then delete the failed restoration task.

Common errors for advanced download tasks

Symptom: On the Backup and Restoration details page for an instance in the ApsaraDB RDS console, you are unable to click the Download Instance Backup File button to create an advanced download task.

DBS-DownloadTask.Region

Cause: The feature is not available in the current region.

Solution: Contact our support team in the DingTalk group (ID: 35585947) to request this feature.

DBS-DownloadTask.InstanceInfo

Cause: The download service failed to retrieve information about the ApsaraDB RDS instance.

Solution: Check if the ApsaraDB RDS instance is in an abnormal state or has been deleted.

DBS-DownloadTask.DbType

Cause: The ApsaraDB RDS instance's database engine does not support the advanced download feature.

Solution: The advanced download feature is available only for ApsaraDB RDS for MySQL and ApsaraDB RDS for PostgreSQL.

DBS-DownloadTask.CustinId

Cause: This feature is not yet enabled for your ApsaraDB RDS instance.

Solution: This feature may be in a phased release and is not yet available for your instance. You can contact technical support in the customer support group (DingTalk group ID: 35585947) and state your requirements.

DBS-DownloadTask.CustinName

Cause: This feature is not yet enabled for your ApsaraDB RDS instance because it is in a phased rollout.

Solution: To request access, contact technical support in the DingTalk group (ID: 35585947).

DBS-DownloadTask.user

Cause: This feature is not enabled for your ApsaraDB RDS instance.

Solution: This feature may be in a phased release period and is not yet available for your instance. You can contact technical support in the DingTalk group (Group ID: 35585947) to submit your request.

DBS-DownloadTask.Instance.Version

Possible cause: The minor engine version of the ApsaraDB RDS instance is outdated.

Solution: Your instance's minor engine version must be 20201031 or newer. To upgrade the minor engine version, see Upgrade the minor engine version. If you encounter issues during the upgrade, contact ApsaraDB RDS technical support.

Note

For more information, see Prerequisites for downloading backups.

DBS-DownloadTask.Instance.Storage.Type

Cause: The storage type of your ApsaraDB RDS instance does not support the advanced download feature.

Solution: Only instances that use cloud disks support the advanced download feature. Go to the Basic Information page of your ApsaraDB RDS instance to verify that the Storage Type is cloud disk.

DBS-DownloadTask.Instance.Param

Cause: The advanced download feature is unavailable because of incorrect parameter settings on the ApsaraDB RDS instance.

Solution: Ensure that the minor engine version of your ApsaraDB RDS instance is not outdated and that the backup data is unencrypted. For details, see Prerequisites for advanced download.

DBS-DownloadTask

Possible cause: The ApsaraDB RDS instance does not support the advanced download feature.

Solution: Ensure your ApsaraDB RDS instance meets the prerequisites for the advanced download feature. For more information, see the following topics:

Note

Before using the advanced download feature, read the documentation to understand its details, including its limitations.

Common task errors

DBS-000000

Scenario: A physical full backup fails.

Cause: The service cannot connect to the backup gateway specified in the backup schedule, and the task fails after reaching the maximum of 100 retries. A common cause is an offline backup gateway.

Example:

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

Solution:

  1. On the Configure Task page for the target backup schedule, check if the backup gateway status is Offline.

  2. In the left-side navigation pane, click Backup Gateways. On the Backup Gateways page, find the target gateway by its Backup Gateway Hostname. Verify that the IP address, hostname, and last heartbeat time are correct. The current status is shown in the Status column.

  3. Check the running status and network configuration of the server where the backup gateway is installed.

    If the server is running correctly and the network connection is stable, restart the backup gateway. Some earlier versions of the backup gateway may have vulnerabilities. We recommend upgrading the backup gateway. For more information, see upgrade backup gateway.

    Note

    If the backup gateway still fails to start after completing these steps, contact technical support in the DingTalk group.

DBS-000001

Scenario: A logical full backup task fails.

Cause: The task failed after exceeding the maximum retry limit.

Example:

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

Solution: Restart the task and monitor its status. If the error persists, contact support in the DingTalk group.

DBS-000002

Scenario: Failure during a logical schema backup or a full backup.

Cause: No service resources are available.

Example:

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

Solution: Contact technical support in the DingTalk group to diagnose the failure.

DBS-000003

Scenario: A link task fails.

Cause: No instance was found for the task.

Example:

DBS-000003  No instance was found for this task

Solution: Contact technical support in the DingTalk group for assistance.

DBS-000004

Scenario: A physical backup or restoration task fails to start.

Cause: An exception occurred while scheduling the physical backup or restoration task.

Example:

DBS-000004 + [Detailed error message]

Solution: Retry the task. If the error persists, contact technical support in the DingTalk group.

DBS-000005

Scenario: A logical backup or restoration task fails to start.

Cause: A scheduling error occurred.

Example:

DBS-000005 + [Detailed error message]

Solution: Retry the task. If the error persists, contact technical support in the DingTalk group.

DBS-000006

Scenario: A physical backup or restoration task times out before starting.

Cause: The task fails to start due to a scheduling error or a resource issue.

Example:

DBS-000006 + [Detailed error message]

Solution: Retry the failed task. If the task fails again, contact technical support in the DingTalk group.

DBS-000007

Scenario: A timeout occurs when starting a logical backup or restoration task.

Cause: A scheduling error or a resource issue occurs during task startup.

Example:

DBS-000007 + [Detailed error message]

Solution: Restart the failed task. If the error persists, contact support through the customer group.

DBS-002003

Scenario: A native physical full backup of a SQL Server database fails.

Cause: The database cannot be accessed. This can occur if you lack the required database permissions, the database does not exist, or its state prevents access.

Example:

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."."].

Solution:

  1. Verify that the database is online. If it is offline, bring it online.

  2. If the database is being restored, wait for the restore to complete before you restart the task.

  3. Check whether the connection is encrypted.

    SELECT encrypt_option FROM sys.dm_exec_connections WHERE session_id = @@SPID

  4. Check the registry to see if Transport Layer Security (TLS) encryption is enabled.

    HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.x\Server
## 1.x indicates the version of TLS, for example, 1.0, 1.1, 1.2, or 1.3.

    If this registry entry exists and its value is 1, TLS encryption is enabled. To disable TLS encryption, follow these steps:

    1. Change the value of the registry entry from 1 to 0.

    2. In the Windows Start search box, search for Internet Options. Click the Advanced tab, scroll down, clear the check boxes for Use TLS 1.0, Use TLS 1.1, Use TLS 1.2, and Use TLS 1.3, and then click OK. The changes take effect after you restart your computer.

    3. Restart your computer and retry the backup task.

DBS-002009

Scenario: A schema backup fails.

Possible causes:

  • The database account name or password is incorrect.

  • The permissions of the database account have changed, or the database restricts access from the source IP.

  • The firewall rules of the database or its server have changed.

  • Network connectivity issues, for example, the network mappings have changed.

Example:

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

Solution: For troubleshooting, see the "Failed to test the connection to the source database" section of this topic. First, check if the connection failed due to changes in the database account name, password, account permissions, source IP, or firewall rules. If these settings are unchanged, check and regenerate the network mappings:

  1. Go to the Configure Task page of the target backup schedule and click Edit Backup Objects in the upper-right corner of the Basic Information section.

  2. Re-enter the database account name and password, and then click Test Connection.

    During the connection test, the system checks and regenerates the network mappings in the background as required. The configuration page includes fields for the database account name and password. For the connection method, you can select unencrypted connection or SSL secure connection.

    Note

    If the connection test still fails even with the correct source database configuration, contact technical support in the DingTalk group.

  3. After the connection test succeeds, click Next.

  4. Re-select the databases and tables to back up and click Save to update the backup schedule.

    After you click Save, the new configuration takes effect and a backup immediately starts. This action may affect the source database and your workloads. We recommend changing the configuration during off-peak hours.

DBS-102001

Scenario: Can occur in various situations.

Cause: The backup completes, but reporting the backup objects to the metadatabase fails. This is a common issue with schema backups. Retrying the task may resolve the issue.

Example:

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

Solution: Retry the task. If the issue persists, contact technical support in the DingTalk group.

DBS-105001

Scenario: This error can occur during various operations.

Cause: Reporting the heartbeat to the metadatabase times out.

Example:

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

Solution: Retry the task. If the issue persists, contact technical support in the DingTalk group.

DBS-106001

Scenario: This error can occur at various stages.

Possible Cause: An OSS internal error.

Example:

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

Solution: For help, contact us in the DingTalk group.

DBS-202002

Scenario: A task fails to back up data to a customer-owned OSS bucket.

Cause: The OSS service is suspended due to an overdue payment.

Example:

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

Solution:

  • On the Backup Task Configuration page for the target backup plan, check whether your current backup plan uses a customer-owned OSS bucket. You can confirm this by checking the Backup Storage OSS Bucket field in the Basic Information section. If you are using a customer-owned OSS bucket, check your OSS bill for any overdue payments. After you pay the bill, retry the backup task.

  • If you are not using a customer-owned OSS bucket, contact technical support in the DingTalk group.

DBS-203101

Scenario: A native physical full backup of a SQL Server database fails.

Possible causes:

  • The database is not running.

  • SSL encryption is enabled for the database.

Example:

DBS-203101 Connect db failure

Solution:

  1. Use SQL Server Management Studio (SSMS) to log on using the port number and verify that the database exists and is running.

    By default, you can log on without a port number. To specify a port number, add it after the hostname with a comma, for example, localhost,1433.

    Note

    Only TCP connections are supported.

  2. Ensure that SSL encryption is not enabled for the database. Open SQL Server Configuration Manager. In the left pane, navigate to SQL Server network configuration > protocols for MSSQLSERVER. Right-click and select properties. On the flags tab, check whether force encryption is set to yes. If it is set to yes, change it to no.

DBS-203102

Scenario: A native physical backup of a SQL Server database fails.

Possible causes:

  • The database was deleted.

  • The source database was renamed.

  • The database is in an abnormal state and cannot be backed up.

Example:

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

Solution:

  1. Check if the database was deleted. If so, reconfigure the backup objects.

    On the Configure Task page for the target backup schedule, click Edit Backup Objects in the Basic Information section.

    Note

    Saving the new configuration immediately starts a backup. This process can affect your source database and business operations.

  2. Check if the source database was renamed. If so, follow the instructions in the previous step to reconfigure the backup objects.

  3. Ensure the database is online.

  4. If the database is in a recovery state, wait for the recovery to finish, then restart the task.

  5. If the database's auto-close feature is enabled, set it to False. In SQL Server Management Studio (SSMS), right-click the target database and select Properties. On the Options page, find the setting in the Auto section.

DBS-203103

Scenario: A full native physical backup of a SQL Server database fails.

Cause: The database is shut down.

Example:

DBS-203103 The database server already shutdown

Solution: Start the database service.

DBS-203104

Scenario: A native physical full backup of a SQL Server database fails.

Cause: An issue with the VDI components.

Example:

DBS-203104 Wait VDI timeout 30s

Solution: Check Windows events to troubleshoot issues with the VDI components. After resolving any issues, retry the task. If you find no issues, wait a while and then retry the backup. If the error persists, contact the DingTalk group for assistance.

DBS-203201

Scenario: This error occurs during a native physical full backup of a SQL Server database.

Possible causes:

  • Multiple backup tasks are running concurrently for the same database.

  • The error is caused by log truncation. Possible causes include:

    • Concurrent backup by another tool.

    • A recent shrink database operation.

    • A change in the database's recovery model.

    • Other actions that can cause log truncation.

Example:

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

Solution:

  • Multiple backup tasks are running concurrently for the same database.

    • If multiple backup tasks are configured to run on the same database simultaneously, suspend the other tasks to ensure only one task runs at a time.

    • If you use a script for scheduled backups, ensure that no other backup tasks run concurrently on the same database.

    • If an incremental backup task that covers multiple databases fails for some of them, disable and then re-enable the task.

  • The error is caused by log truncation.

    • The backup is incomplete due to log truncation. Initiate a new full backup from the console.

DBS-203202

Scenario: An incremental backup of a SQL Server database fails.

Possible causes:

  • An incremental backup starts before a full backup is complete. This issue may occur when you configure a backup task for the first time.

  • The CopyOnly option is selected in the backup task configuration. Full backups created with this option cannot serve as a base for incremental backups.

Example:

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

Solution: Manually run a full backup and then restart the failed incremental backup.

DBS-203203

Scenario: An error occurs during a native physical full backup of a SQL Server database.

Cause: Transaction log backups are not supported because the database's recovery model is not set to FULL.

Example:

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

Solution: Execute the following SQL statement to change the recovery model to FULL:

ALTER DATABASE [your_database_name] SET RECOVERY FULL

DBS-203205

Scenario: A native physical full backup of a SQL Server database fails.

Cause: The database is offline.

Example:

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

Solution:

  • Verify that the database is online. If not, bring it online.

  • If the database is being restored, wait for the restore to complete before you restart the task.

DBS-203206

Scenario: A native physical full backup of a SQL Server database fails.

Cause: The database cannot be opened because it is unavailable or corrupted.

Example:

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

Solution:

  • Make sure the database is online.

  • If the database is being restored, wait for the recovery to complete before restarting the task.

DBS-203240

Scenario: SQL Server native physical full backup.

Cause: The account does not have the sysadmin permission.

Example:

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

Solution: Update the backup schedule to use an account with the required permissions, or grant the sysadmin permission to the current account. For details on changing the database account, see Modify the source database for backup.

DBS-203301

Scenario: A full restoration of a SQL Server database fails.

Possible Cause: To prevent data loss, you must back up the tail log before restoring a database. This error occurs if the tail log was not backed up.

Note

A tail log contains the transaction log records generated since the last log backup.

Example:

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

Solution:

  1. To back up the tail log, run the following command.

    BACKUP LOG [Name of the database to restore] TO DISK='C:\backupdir\moyun_test.trn' WITH NORECOVERY;

  2. Restart the failed full restoration task.

DBS-203302

Scenario: A restore from a native physical full backup of a SQL Server database fails.

Cause: The transaction log backup ends at LSN {0}, which is earlier than the LSN {1} required to continue the restore. This indicates a gap in the log backup chain.

Example:

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

Solution: Contact technical support in the DingTalk group for assistance.

DBS-301005

Scenario: A physical full backup of an Oracle instance fails.

Cause: The Oracle instance is not in archive mode, which is required for a physical full backup.

Example:

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

Solution: Enable archive mode. For detailed instructions, see Enable archive mode.

DBS-301502

Scenario: An error occurs during a MySQL physical backup.

Cause: A DDL operation that cannot be recorded in the redo log is executed during the backup.

Example:

DBS-301502, without redo logging

Solution: Retry the backup when no DDL operations are running.

DBS-301503

Scenario: A MySQL physical backup fails.

Cause: The redo log generation speed exceeds the backup speed.

Example:

DBS-301503, log copying being too slow

Solution: Increase the size of the redo file and schedule backups during off-peak hours.

DBS-301504

Scenario: A physical backup of a MySQL instance fails.

Cause: This error occurs because one or more tables in the MySQL instance have encryption enabled, a feature that Database Backup Service does not support.

Example:

DBS-301504, missing encryption

Solution: Disable encryption and retry the backup. If you prefer not to disable encryption, contact customer service to request a refund for the backup schedule.

DBS-301505

Scenario: A physical backup of a MySQL database fails.

Cause: The system terminates the backup process.

Example:

DBS-301505, signal: terminated

Solution: Restart the task.

DBS-302035

Scenario: A full physical backup of an Oracle database fails.

Cause: Unable to obtain the role of the Oracle instance.

Example:

DBS-302035 USER_CAN_NOT_LOAD_INSTANCE_ROLE[302035]

Solution:

  1. Log on to the server hosting the database instance.

  2. Run the following command to log on to the database as a system administrator:

    sqlplus / as sysdba

  3. Run the following SQL statement to check whether a result is returned:

    select database_role from v$database;

    If no result is returned, investigate the cause. If a result is returned, contact support in the DingTalk group.

DBS-400001

Scenario: A full native physical backup or a full data conversion task fails.

Cause: The task runs out of memory because the backup schedule specifications are insufficient.

Example:

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

Solution: Upgrade the backup schedule specifications. To temporarily increase the memory limit for an urgent task, such as a restoration task, contact technical support in the DingTalk group. For instructions, see Upgrade a backup schedule.

DBS-999999 or no error code

Scenario: An error occurs during any task.

Cause: The exception is undefined, or the system failed to return the corresponding error code.

Example:

DBS-999999 + [error message]

Solution: Copy the error message and search for it in this topic to see if a different error code describes the issue. If you cannot find a solution, contact technical support in the DingTalk group.

Previous：Security hostingNext：Database backup service (DBS)