Common errors that are returned by DBS and troubleshooting - Database Backup

An error may occur when you configure a backup schedule, precheck a backup schedule or restore task, or run a restore task in Database Backup (DBS). This topic describes the common errors and how to troubleshoot these errors.

Note

If the error that you encounter is not described in this topic, or your issue persists after you use the solution provided in this topic, contact technical support in the DingTalk group (ID 35585947) for DBS users.

List of common errors by type

Common error that may occur when you configure a backup schedule

Failed to test the connection to the source database

Common errors that may occur when you precheck a backup schedule or restore task

Failed to check the connection to the source database
Failed to check the permissions on the source database
Failed to check the connection to OSS
Failed to check whether the binary logging feature is enabled for the source database
Failed to check the binary log format of the source database
Failed to check whether the binlog_row_image parameter of the source database is set to FULL
Failed to check the server ID of the source database
Failed to check the existence of binary log files in the source database
Failed to check storage engines
Failed to check the password format of a MySQL database
Object name conflicts

Common error codes that may be returned for the advanced download feature

DBS-DownloadTask.Region
DBS-DownloadTask.InstanceInfo
DBS-DownloadTask.DbType
DBS-DownloadTask.CustinId
DBS-DownloadTask.CustinName
DBS-DownloadTask.user
DBS-DownloadTask.Instance.Version
DBS-DownloadTask.Instance.Storage.Type
DBS-DownloadTask.Instance.Param
DBS-DownloadTask

Common error codes that may be returned when you run a task

Common error that may occur when you configure a backup schedule

Failed to test the connection to the source database

Scenario: The connection test fails when you configure a backup schedule.

Causes:

The database account name or password is invalid.
The database denies access from the IP address of DBS.
A firewall is configured for the server or network on which the database resides.
Network communication is abnormal.

Solution:

Click Check in the DBS console to view the details of the connection test failure.
Perform the following checks to troubleshoot the issue:
- Check whether the database account name or password is invalid, or whether the database denies access from the IP address of DBS.
  1. Check whether the database account name and password are valid.
    Find a server that can be connected to the source database. On the server, use the database account name and password that you specify when you configure the backup schedule to connect to the database. This way, you can check whether the database account name and password are valid. If the database account name or password is invalid, specify the valid database account name and password and test the connection again.
  2. If the database account name and password are valid, check whether the database blocks the IP address of DBS.
    - If the database is a MySQL database, use a MySQL client to connect to the database and execute the following SQL statement to obtain the IP address of the database account that you specify. Then, check whether remote access to the database is allowed from the IP address.
```
SELECT host,user,authentication_string,password_expired,account_locked FROM mysql.user WHERE user='[$Username]';
```
      Note
      Replace [$Username] with the database account that you specify when you configure the backup schedule.
    - If the database is an SQL Server database,
      - If the backup gateway is installed on the source database server, set the Address parameter to localhost.
      - Check whether a firewall is configured for the server on which the database resides. In addition, check whether an endpoint or trigger in the source database denies access from the IP address of DBS.
    - If the database is an Oracle database, check whether the TCP.VALIDNODE_CHECKING parameter in the sqlnet.ora file is set to YES. If the parameter is set to YES, the database denies access from the IP address of DBS.
- Check whether a firewall is configured for the server on which the database resides and a firewall policy is configured to deny access to the server, or whether network communication is abnormal.
  1. Check whether a firewall is configured for the server on which the database resides and a firewall policy is configured to deny access to the server.
    - If the database is deployed on a Windows server, find Windows Defender Firewall from the Control Panel and check whether a firewall policy is configured to deny access to the server.
    - If the database is deployed on a Linux server, run the iptables -L command and check whether a firewall policy is configured to deny access to the server.
    - If the source database is deployed on an Elastic Compute Service (ECS) instance, check whether the CIDR block of DBS servers is added to the security group rules of the ECS instance. For more information, see Add a security group rule. You can obtain the CIDR block of DBS servers in the DBS console.
  2. Check whether access from the CIDR block of DBS servers is allowed on the network firewall of the database. In this example, Cloud Firewall is used.
    1. Log on to the Cloud Firewall console. In the left-side navigation pane, choose Access Control > Internet Border.
    2. On the Internet Border page, check whether a policy is configured for Cloud Firewall to deny access from the CIDR block of DBS servers. You can obtain the CIDR block of DBS servers in the DBS console.
    Note
    If the error is not caused by a firewall but the Telnet connection test still fails, the network communication of DBS may be abnormal. Contact technical support in the DingTalk group for DBS users.

Common errors that may occur when you precheck a backup schedule or restore task

Failed to check the connection to the source database

Scenario: The precheck fails for a backup schedule or restore task when you start the backup schedule or restore task.

Causes:

The database account name or password is invalid.
The database denies access from the IP address of DBS.
A firewall is configured for the server or network on which the database resides.
Network communication is abnormal.

Solution: For more information, see the Failed to test the connection to the source database section of this topic.

Failed to check the permissions on the source database

Scenario: The precheck fails for a backup schedule or restore task when you start the backup schedule or restore task.

Causes:

The database account that you specify for the backup schedule does not have the permissions to access the database.
The database account that you specify for the restore task does not have the permissions to write data to the database or update tables in the database.

Solution: Check the permissions of the database account that you use. If the database account does not have sufficient permissions, we recommend that you grant required permissions to the database account or use another database account with the required permissions.

Note

Backup schedule: For more information about how to change the database account for a backup schedule, see How do I change or modify the backup source database in a backup schedule?
Restore task: We recommend that you configure another restore task. You can delete a restore task that has passed the precheck.

Failed to check the connection to OSS

Scenario: The precheck fails for a backup schedule or restore task when you start the backup schedule or restore task.

Causes:

When you configure the backup schedule, you set the Backup Storage Type parameter to OSS For User and specify your own Object Storage Service (OSS) bucket as the backup storage. However, DBS is not authorized to access OSS.
An internal error occurred.

Solution:

On the Configure Task page of the backup schedule, check whether the built-in DBS storage or your own OSS bucket is used as the backup storage for the backup schedule. If your own OSS bucket is used, log on to the OSS console and check whether the bucket displayed in the DBS console exists and whether DBS is authorized to access the bucket. For more information, see How do I activate DBS?
If the OSS bucket exists and DBS is authorized to access OSS, an internal service error may occur. Contact technical support in the DingTalk group for DBS users.

Failed to check whether the binary logging feature is enabled for the source database

Scenario: DBS fails to check whether the binary logging feature is enabled for the source database.

Solution: This check item is used to check whether the binary logging feature is enabled for the source database. If the check fails, the binary logging feature is disabled for the source database. To resolve the issue, perform the following steps:

Log on to the server on which the self-managed MySQL database resides.

Modify the my.cnf configuration file of the self-managed MySQL database in the following way:

log_bin=mysql_bin
binlog_format=row
server_id=2 // The server ID is an integer greater than 1. The value in this example is for reference only. 
binlog_row_image=FULL // This parameter is required if the version of 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 be different.

Run the following command to restart the MySQL database:
```
[$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
[$Mysql_Dir]/bin/safe_mysqld &
```
Note
Replace [$Mysql_Dir] with the installation directory of the MySQL database.
Log on to the self-managed MySQL database and execute the following SQL statement to check whether the binary logging feature is enabled:
```
SHOW variables LIKE '%log_bin%';
```
If information similar to the following output appears, the binary logging feature is enabled.
Perform the precheck in the DBS console again.

Failed to check the binary log format of the source database

Scenario: DBS fails to check the binary log format of the source database.

Solution: This check item is used to check whether the binary log format of the source database is set to ROW. If the check fails, the binary log format of the source database is not set to ROW. To resolve the issue, perform the following steps:

Log on to the server on which the self-managed MySQL database resides.

Modify the my.cnf configuration file in the following way. Set the binlog_format parameter to ROW.

log_bin=mysql_bin
binlog_format=ROW  // Set the binary log format to ROW. 
server_id=2 // The server ID is an integer greater than 1. The value in this example is for reference only. 
binlog_row_image=FULL // This parameter is required if the version of 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 be different.

Run the following command to restart the MySQL database:
```
[$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
[$Mysql_Dir]/bin/safe_mysqld &
```
Note
Replace [$Mysql_Dir] with the installation directory of the MySQL database.
Log on to the self-managed MySQL database and execute the following SQL statement to check whether the binary log format is set to ROW:
```
SHOW variables LIKE "%binlog_format%";
```
If information similar to the following output appears, the binary log format is set to ROW.
Perform the precheck in the DBS console again.

Failed to check whether the binlog_row_image parameter of the source database is set to FULL

Scenario: DBS fails to check whether the binlog_row_image parameter of the source database is set to FULL.

Solution: This check item is applicable only to databases of MySQL 5.6 or later. This check item is used to check whether the binlog_row_image parameter of the source database is set to FULL. If the check fails, the binlog_row_image parameter of the source database is not set to FULL. As a result, the binary log files of the source database do not record full images. To resolve the issue, perform the following steps:

Log on to the server on which the self-managed MySQL database resides.

Modify the my.cnf configuration file in the following way. Set the binlog_row_image parameter to FULL.

log_bin=mysql_bin
binlog_format=ROW  // Set the binary log format to ROW. 
server_id=2 // The server ID is an integer greater than 1. The value in this example is for reference only. 
binlog_row_image=FULL // This parameter is required if the version of 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 be different.

Run the following command to restart the MySQL database:
```
[$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
[$Mysql_Dir]/bin/safe_mysqld &
```
Note
Replace [$Mysql_Dir] with the installation directory of the MySQL database.
Log on to the self-managed MySQL database and execute the following SQL statement to check whether the binlog_row_image parameter is set to FULL:
```
show variables like "%binlog_row_image%";
```
Perform the precheck in the DBS console again.

Failed to check the server ID of the source database

Scenario: DBS fails to check the server ID of the source database.

Solution: Before an incremental data migration task is started for a MySQL database, DBS checks the value of the server_id parameter of the source database. If DBS fails to check the value of the server_id parameter of a self-managed MySQL database, perform the following steps to resolve the issue:

Log on to the self-managed MySQL database server and execute the following SQL statement to view the value of the server_id parameter:
```
SHOW variables LIKE '%server_id%';
```
Execute the following SQL statement to modify the value of the server_id parameter. The value of the server_id parameter must be set to an integer greater than 1.
```
SET global server_id=[$ID];
```
Note
- Replace [$ID] with an integer greater than 1. Make sure that the value that you enter is not used by another database.
- If the self-managed database is deployed in primary/secondary mode, make sure that primary-secondary replication is not affected.
- After the preceding statement is executed, you must modify the value of the server_id parameter in the configuration file. Otherwise, the value that you specify for the server_id parameter becomes invalid after the database is restarted.
Perform the precheck in the DBS console again.

Failed to check the existence of binary log files in the source database

Scenario: When you start a backup schedule for a self-managed MySQL database, DBS fails to check the existence of binary log files in the source database.

Solution:

Run the following command in the MySQL CLI to check whether the binary logging feature is enabled.
```
SHOW variables LIKE 'log_%';
```

Enable the binary logging feature if the feature is disabled. The following command output indicates that the binary logging feature is disabled. In this case, you must modify the my.cnf configuration file to enable the feature. On a Linux server, you can run the Vim command to edit the configuration file.

off

# Go to the /etc/my.cnf directory.
vim /etc/my.cnf

# Press the I key to enter the edit mode.
# Set the log_bin parameter to mysql_bin and specify other parameters.
log_bin = mysql_bin
binlog_format = row
server_id = 2
expire_logs_days = 30

# Press the ESC key to exit the edit mode and enter :wq to save the file.

Run the following command to restart the self-managed MySQL database:
```
systemctl restart mysqld
```
Note
The modification to the configuration file takes effect after you restart the database. We recommend that you restart the database during off-peak hours.
After you restart the database, run the command in Step 1 to check whether the binary logging feature is enabled. If the binary logging feature is enabled, start the backup schedule again.

Failed to check storage engines

Solution: This check item is used to check whether the storage engines of the source database support incremental data migration. The FEDERATED and MRG_MYISAM storage engines do not support incremental data migration between MySQL databases. If the check fails, tables in the source database may use one of the preceding storage engines. Perform the following operation to resolve the issue:

On the Configure Task page of the backup schedule, click Edit Backup Objects. Remove the tables whose storage engines do not support incremental data migration from backup objects.

Note

After the modification takes effect, the system immediately backs up data. This may affect the source database and your business. We recommend that you modify the configuration during off-peak hours.

Failed to check the password format of a MySQL database

Scenario: The precheck fails for a backup schedule or a restore task when you start the backup schedule or restore task.

Solution: DBS checks whether a MySQL database uses the password format of the previous version. For more information, see old_passwords.

Object name conflicts

Scenario: A restore object that you select uses the same name as an existing object in the destination database.

Solution: Create another restore task and select Rename Object with the Same Name or click Edit to rename the object to be restored to the destination database. You can delete the failed restore task.

Common error codes that may be returned for the advanced download feature

Scenario: On the Backup and Restoration page of the ApsaraDB RDS console, Download Instance Backup File is dimmed.

DBS-DownloadTask.Region

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

Solution: Contact technical support in the DingTalk group (ID 35585947) for DBS users.

DBS-DownloadTask.InstanceInfo

Cause: The information about the ApsaraDB RDS instance failed to be obtained.

Solution: Check whether the ApsaraDB RDS instance is abnormal or whether the instance is deleted.

DBS-DownloadTask.DbType

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

Solution: Make sure that the database engine of the ApsaraDB RDS instance is MySQL or PostgreSQL. The feature is not supported by other types of ApsaraDB RDS instances.

DBS-DownloadTask.CustinId

Cause: The advanced download feature is not available for the ApsaraDB RDS instance.

Solution: Please wait. The advanced download feature is available in phases. You can contact technical support in the DingTalk group (ID 35585947) for DBS users.

DBS-DownloadTask.CustinName

Cause: The advanced download feature is not available for the ApsaraDB RDS instance.

Solution: Please wait. The advanced download feature is available in phases. You can contact technical support in the DingTalk group (ID 35585947) for DBS users.

DBS-DownloadTask.user

Cause: The advanced download feature is not available for the ApsaraDB RDS instance.

Solution: Please wait. The advanced download feature is available in phases. You can contact technical support in the DingTalk group (ID 35585947) for DBS users.

DBS-DownloadTask.Instance.Version

Cause: The minor engine version of the ApsaraDB RDS instance does not meet the prerequisite for creating an advanced download task.

Solution: The minor engine version of your ApsaraDB RDS instance must be later than 20201031. For more information about how to update the minor engine version of an ApsaraDB RDS instance, see Update the minor engine version. If you have problems during the update, contact technical support for ApsaraDB RDS users.

Note

For more information, see Download backup files.

DBS-DownloadTask.Instance.Storage.Type

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

Solution: Only ApsaraDB RDS instances that use standard SSDs or Enterprise SSDs (ESSDs) support the advanced download feature. You can go to the Basic Information page of the ApsaraDB RDS console to check the storage type of the ApsaraDB RDS instance.Storage Type

DBS-DownloadTask.Instance.Param

Cause: The ApsaraDB RDS instance is not properly configured.

Solution: Make sure that the minor engine version of the ApsaraDB RDS instance meets the prerequisite for creating an advanced download task and the backup data is not encrypted. For more information, see the Download methods section of the "Download backup files" topic.

DBS-DownloadTask

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

Solution: Make sure that the ApsaraDB RDS instance meets the prerequisites for the advanced download feature described in the following topics:

ApsaraDB RDS for MySQL: Download the backup files of an ApsaraDB RDS for MySQL instance
ApsaraDB RDS for PostgreSQL: Download the backup files of an ApsaraDB RDS for PostgreSQL instance

Note

We recommend that you understand the limits and usage notes on the advanced download feature before you use this feature.

Common error codes that may be returned when you run a task

DBS-000000

Scenario: A native physical full backup task fails.

Cause: DBS cannot connect to the database server by using the backup gateway that is used by the backup schedule, and the number of retries has reached the upper limit of 100. A common cause is that the backup gateway is disconnected.

Example:

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

Solution:

Go to the Configure Task page of the backup schedule and check whether the backup gateway that is used by the backup schedule is in the Offline state.
On the Backup Gateways page, check whether the IP address, hostname, and last heartbeat time of the backup gateway are abnormal.
Check the status and network configurations of the server on which the backup gateway is installed.
If the server is running as expected and the network is connected, you can try to restart the backup gateway. Backup gateways of earlier versions may have vulnerabilities. Upgrade the backup gateway to the latest version. For more information, see Install a backup gateway.
Note
If the backup gateway cannot be started after you perform the preceding operations, contact technical support in the DingTalk group for DBS users.

DBS-000001

Scenario: A logical full backup task fails.

Cause: The task fails and the number of retries has reached the upper limit.

Example:

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

Solution: Try to restart the task and observe the status of the task. If the error persists, contact technical support in the DingTalk group for DBS users.

DBS-000002

Scenario: A logical schema backup or full backup task fails.

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 for DBS users.

DBS-000003

Scenario: A task fails.

Cause: The task is invalid.

Example:

DBS-000003  No instance was found for this task

Solution: Contact technical support in the DingTalk group for DBS users.

DBS-000004

Scenario: A physical backup or restore task fails.

Cause: The physical backup or restore task fails to be scheduled when the task is started.

Example:

DBS-000004 + [Error message]

Solution: Try to restart the task. If the issue persists, contact technical support in the DingTalk group for DBS users.

DBS-000005

Scenario: A logical backup or restore task fails.

Cause: The logical backup or restore task is abnormally scheduled when it is started.

Example:

DBS-000005 + [Error message]

Solution: Try to restart the abnormal task. If the issue persists, contact technical support in the DingTalk group for DBS users.

DBS-000006

Scenario: A timeout occurs when you start a physical backup or restore task.

Cause: The physical backup or restore task is abnormally scheduled when it is started, or resources are abnormal.

Example:

DBS-000006 + [Error message]

Solution: Try to restart the task. If the issue persists, contact technical support in the DingTalk group for DBS users.

DBS-000007

Scenario: A timeout occurs when you start a logical backup or restore task.

Cause: The logical backup or restore task is abnormally scheduled when it is started, or resources are abnormal.

Example:

DBS-000007 + [Error message]

Solution: Try to restart the task. If the issue persists, contact technical support in the DingTalk group for DBS users.

DBS-002003

Scenario: An error occurs when native physical backup is performed in full backup mode for an SQL Server database.

Cause: The database cannot be accessed. You may not have permissions on the database, the database does not exist, or the database is inaccessible.

Examples:

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:

Check whether the database is offline. Make sure that the database is online.
If the database is being restored, wait until the database is restored before you restart another task.

Check whether the connection is encrypted.

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

View the registry to check whether 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. Examples: 1.0, 1.1, and 1.2.
```
If the relevant configuration item exists and its value is 1, TLS encryption is enabled. To disable TLS encryption, perform the following steps:
1. Modify the value of the configuration item from 1 to 0.
2. In Windows, search for Internet Options in the Start search box. In the Internet Properties dialog box, click the Advanced tab and clear the check boxes related to TLS.
3. Restart the computer and restart the backup task.

DBS-002009

Scenario: The schema backup fails.

Causes:

The database account name or password is invalid.
The permissions of the database account are changed, or the database denies access from the IP address of DBS.
The firewall rules of the server on which the database is deployed are modified.
The network connection of DBS is abnormal. For example, the network mappings are changed.

Example:

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

Solution: For more information, see the "Failed to test the connection to the source database" section of this topic. First, check whether the connection failure is caused by changes in the database account name or password, the permissions of the database account, the IP address of DBS, or firewall rules. If the preceding items are not changed, check and regenerate the network mappings.

Go to the Configure Task page of the backup schedule and click Edit Backup Objects.
Enter the database account name and password again, and then click Test Connection.
During the connection test, the system checks and regenerates the network mappings based on your business requirements in the background.
Note
If the source database is configured as expected but the connection test still fails, contact technical support in the DingTalk group for DBS users.
After the test is passed, click Next.
Select the databases and tables that you want to back up and click Save to save the configurations to the backup schedule.
After you click Save, the preceding configurations take effect and DBS immediately initiates a backup. The backup affects the source database and your business. We recommend that you modify and save the configurations during off-peak hours.

DBS-102001

Scenario: An error occurs when a task is run.

Cause: After the backup task is complete, an error is returned when the backup objects are reported to the metadatabase. This is a common error that occurs in the schema backup. You can restart the task to troubleshoot the error.

Example:

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

Solution: Try to restart the task. If the issue persists, contact technical support in the DingTalk group for DBS users.

DBS-105001

Scenario: An error occurs when a task is run.

Cause: A timeout occurs when the heartbeats are reported to the metadatabase.

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: Try to restart the task. If the issue persists, contact technical support in the DingTalk group for DBS users.

DBS-106001

Scenario: An error occurs when a task is run.

Cause: An OSS internal error occurs.

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: Contact technical support in the DingTalk group for DBS users.

DBS-202002

Scenario: An error occurs when a task is run to back up data to an OSS bucket.

Cause: You have an overdue payment for the OSS service.

Example:

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

Solution:

On the Configure Task page of the backup schedule, check whether your own OSS bucket is used as the backup storage for the backup schedule. If your own OSS bucket is used, check the overdue payment of your OSS service, renew your OSS service, and then retry the backup task.
If you are not using your OSS bucket, contact technical support in the DingTalk group for DBS users.

DBS-203101

Scenario: An error occurs when native physical backup is performed in full backup mode for an SQL Server database.

Causes:

The database no longer works.
SSL encryption is enabled for the database.

Example:

DBS-203101 Connect db failure

Solution:

Use SQL Server Management Studio (SSMS) to log on to the SQL Server database by using the port number of the database. Check whether the database exists or is running.
By default, you can log on to the database without using a port number. For example, localhost,1433 is separated by a comma (,).
Note
DBS supports only TCP connections to databases.
Make sure that SSL encryption is disabled for the current database.

DBS-203102

Scenario: An error occurs when native physical backup is performed in full backup mode for an SQL Server database.

Causes:

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

Example:

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

Solution:

Check whether the database is deleted. If the database is deleted, reconfigure the backup objects.
Go to the Configure Task page of the backup schedule, click Edit Backup Objects, and then configure the backup objects.
Note
A backup is immediately initiated after the reconfigured backup objects are saved and take effect. Take note of the impact on your business and the source database.
Check whether the database is renamed. If the database is renamed, refer to the previous step to reconfigure the backup objects.
Check whether the database is offline. Make sure that the database is online.
If the database is being restored, wait until the database is restored before you restart another task.
If the auto-close feature is enabled for the database, set the auto-close feature to False.

DBS-203103

Scenario: An error occurs when native physical backup is performed in full backup mode for an SQL Server database.

Cause: The database is unavailable.

Example:

DBS-203103 The database server already shutdown

Solution: Make the database available.

DBS-203104

Scenario: An error occurs when native physical backup is performed in full backup mode for an SQL Server database.

Cause: An issue occurs in virtual desktop infrastructure (VDI) components.

Example:

DBS-203104 Wait VDI timeout 30s

Solution: We recommend that you check Windows events to troubleshoot VDI component issues and restart the task after the issue is resolved. If no such issue is reported, wait for a period of time and then restart the backup task. If the error persists, contact technical support in the DingTalk group for DBS users.

DBS-203201

Scenario: An error occurs when native physical backup is performed in full backup mode for an SQL Server database.

Cause: Multiple backup tasks are run to back up a database at the same time.

Example:

DBS-203201 database xxx backupable lsn {1} exceeded limit {2}

Solution:

If multiple backup tasks are run to back up a database at the same time, retain only one backup task at a time and suspend other backup tasks.
If a script is used to back up a database on a scheduled basis, suspend other backup tasks to ensure that only one backup task is run to back up the database at a time.
If incremental backup is performed for multiple databases, some databases may fail to be backed up. In this case, disable incremental backup and then enable incremental backup.

DBS-203202

Scenario: An error occurs when native physical backup is performed in full backup mode for an SQL Server database.

Causes:

Incremental backup is performed before full backup is performed. This issue may occur when you configure a backup task for the first time.
This issue may also occur if the CopyOnly option is selected when you configure a backup task.

Example:

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

Solution: You can manually perform full backup and then restart the failed incremental backup for the backup task.

DBS-203203

Scenario: An error occurs when native physical backup is performed in full backup mode for an SQL Server database.

Cause: Transaction logs cannot be backed up because you do not use the FULL recovery model.

Example:

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

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

ALTER DATABASE [xxx] SET RECOVERY FULL

DBS-203205

Scenario: An error occurs when native physical backup is performed in full backup mode for an SQL Server database.

Cause: The database is offline.

Example:

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

Solution:

Check whether the database is offline. Make sure that the database is online.
If the database is being restored, wait until the database is restored before you restart another task.

DBS-203206

Scenario: An error occurs when native physical backup is performed in full backup mode for an SQL Server database.

Cause: The database cannot be accessed. The database may be damaged. You must check whether the database is available.

Example:

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

Solution:

Check whether the database is offline. Make sure that the database is online.
If the database is being restored, wait until the database is restored before you restart another task.

DBS-203240

Scenario: An error occurs when native physical backup is performed in full backup mode for an SQL Server database.

Cause: The current database account does not have the permissions of a system administrator.

Example:

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

Solution: Modify the configurations of the backup schedule. Use a database account that has the required permissions or assign the system administrator role to the database account that is used. For more information about how to change the database account, see How do I change or modify the backup source database in a backup schedule?

DBS-203301

Scenario: An error occurs when native physical backup is performed in full restoration mode for an SQL Server database.

Cause: Tail logs are not backed up. To prevent data loss, you must back up the tail logs of the current database before you restore the database.

Note

Tail logs are the transaction logs generated after 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:

Run the following command to back up tail logs:

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

Restart the failed full restore task.

DBS-203302

Scenario: An error occurs when native physical backup is performed in full backup mode for an SQL Server database.

Cause: A full backup set cannot be used to restore data because the last transaction log LSN {0} in the current full backup set is generated earlier than the transaction log LSN {1} in another full backup set.

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 DBS users.

DBS-301005

Scenario: An error occurs when physical backup is performed in full backup mode for an Oracle database.

Cause: The ARCHIVELOG mode is disabled for the Oracle database. You must enable the ARCHIVELOG mode for the Oracle database first.

Example:

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

Solution: Enable the ARCHIVELOG mode for the Oracle database. For more information, see the "Enable the archive mode" section of the Prepare for physical backup of an Oracle database topic.

DBS-301502

Scenario: An error occurs when physical backup is performed for a MySQL database.

Cause: DDL operations cannot be recorded in redo logs during the backup.

Example:

DBS-301502, without redo logging

Solution: Restart the backup task when DDL operations are not performed.

DBS-301503

Scenario: An error occurs when physical backup is performed for a MySQL database.

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

Example:

DBS-301503, log copying being too slow

Solution: We recommend that you increase the capacity of the redo file and perform backup during off-peak hours.

DBS-301504

Scenario: An error occurs when physical backup is performed for a MySQL database.

Cause: Encryption is enabled for tables in the MySQL database. DBS does not support the backup of encrypted tables.

Example:

DBS-301504, missing encryption

Solution: We recommend that you disable the encryption feature for the tables and restart the backup task. If you do not want to disable the encryption feature and you want to stop using DBS, contact DBS customer service staff to explain the reason and apply for a refund for the backup schedule.

DBS-301505

Scenario: An error occurs when physical backup is performed for a MySQL database.

Cause: The backup process is terminated by the system.

Example:

DBS-301505, signal: terminated

Solution: Restart the task.

DBS-302035

Scenario: An error occurs when physical backup is performed in full backup mode for an Oracle database.

Cause: The database role information of the Oracle instance cannot be obtained.

Example:

DBS-302035 USER_CAN_NOT_LOAD_INSTANCE_ROLE[302035]

Solution:

Log on to the server on which the database instance is deployed.
Run the following command to log on to the database as a system administrator:
```
sqlplus / as sysdba
```
Execute the following SQL statement to check whether a result is returned:
```
select database_role from v$database;
```
If no result is returned, troubleshoot the error. If a result is returned, contact technical support in the DingTalk group for DBS users.

DBS-400001

Scenario: An error occurs when native physical backup is performed in full backup mode and the backup data is converted.

Cause: The specifications of the backup schedule do not meet your business requirements.

Example:

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

Solution: We recommend that you upgrade the specifications of the backup schedule. If you need to temporarily increase the memory limit for urgent tasks such as a restore task, contact technical support in the DingTalk group for DBS users. For more information about how to upgrade the specifications of a backup schedule, see Upgrade a backup schedule.

DBS-999999 or no error code

Scenario: An error occurs when a task is run.

Cause: The exception has not been defined by DBS, or an error code has been defined for the exception but the error code is not displayed.

Example:

DBS-999999 + [Error message]

Solution: We recommend that you copy the error message and search for the error in this topic to check whether the issue is defined by using another error code. If you cannot find a relevant error in this topic, contact technical support in the DingTalk group for DBS users.