DocsICP FilingConsole
官方文档
首页

Database backup FAQ

更新时间：
复制 MD 格式
产品详情
我的收藏

Troubleshoot common issues with database backups in Cloud Backup.

FAQ

Database instance issues

Client issues

Backup issues

Restore issues

Backup vault issues

Database instance issues

Failed database instance registration

Check whether the database backup client is already installed on the server (local or ECS). If so, uninstall the client and remove its configuration files, then register the instance again.

Inactive database instance status

image.png

MySQL

  1. The Database Account or Password entered during registration is incorrect, or the user lacks sufficient permissions. Verify the credentials and grant the necessary permissions to the backup account. We recommend creating a dedicated backup user.

    Create a MySQL backup account and configure permissions.

  2. Run the systemctl restart dbackup3-agent command to restart the database backup client.

  3. If the instance remains inactive after restarting the client, collect logs for analysis.

    The client log path is /var/log/dbackup3/agent.log.

Oracle

  1. The Database Account or Password entered during registration is incorrect, or the user lacks sufficient permissions. Verify the credentials and grant the necessary permissions to the backup account. We recommend creating a dedicated backup user.

    Create an Oracle backup account and configure permissions.

  2. Restart the database backup client.

    • On Linux systems, run the systemctl restart dbackup3-agent command to restart the database backup client.

    • On Windows systems:

      1. Press Win+R to open the Run dialog box.

      2. Enter services.msc and press Enter to open the Services console.

      3. In the list of services, find the dbackup3-agent service.

      4. Check the service status. If it is not "Running", right-click the dbackup3-agent service and select "Restart".

  3. If the instance remains inactive after restarting the client, collect logs for analysis.

    • The client log path on Linux systems is /var/log/dbackup3/agent.log.

    • The client log path on Windows systems is C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log.

SQL Server

  1. The Database Account or Password entered during registration is incorrect, or the user lacks sufficient permissions. Verify the credentials and grant the necessary permissions to the backup account. We recommend creating a dedicated backup user.

    Create an SQL Server backup account and configure permissions.

  2. Restart the dbackup3-agent service.

    1. Press Win+R to open the Run dialog box.

    2. Enter services.msc and press Enter to open the Services console.

    3. In the list of services, find the dbackup3-agent service.

    4. Check the service status. If it is not "Running", right-click the dbackup3-agent service and select "Restart".

  3. If the instance remains inactive after restarting the dbackup3-agent service, collect logs for analysis.

    The client log path is C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log.

Database offline status

image

MySQL

  1. Check the status of the MySQL database.

    Log on to the ECS instance and run the systemctl status mysqld command to check the status of the MySQL database. If the process is inactive, the MySQL database service is not running.

  2. Restart the MySQL service.

    Run the systemctl start mysqld command to restart the MySQL service. After the service restarts, the Database Status in the console changes to Online.

Oracle

  1. Check the status of the Oracle database listener.

    Log on to the ECS instance and run the following commands:

    su - oracle
lsnrctl status

    If the service is running, the status is displayed as running. If the service is not running, a TNS: no listener message is returned.

  2. Check the running status of the Oracle database.

    su - oracle
sqlplus /nolog
conn /as sysdba
SELECT name, status FROM v$instance;

    The v$instance view provides information about the database instance. The status column shows the instance status. If the status is OPEN, the database is open and can accept connections.

  3. Restart the Oracle listener.

    Start the Oracle listener service.

    su - oracle
lsnrctl start

  4. Restart the Oracle database instance.

    Log on to SQL*Plus as a system administrator and start the Oracle instance.

    sqlplus / as sysdba;
STARTUP;

    After the instance starts, the Database Status in the console changes to Online.

SQL Server

  1. Check the status of the SQL Server database.

    1. Press Win+R to open the Run dialog box.

    2. Enter services.msc and press Enter to open the Services console.

    3. In the list of services, find the SQL Server service, such as "SQL Server (MSSQLSERVER)".

    4. Check the service status. The status can be "Running", "Stopped", or "Paused".

  2. Restart the SQL Server service.

    If the status of the SQL Server service is "Stopped" or "Paused", right-click the service and select "Start". If the "Start" option is dimmed, reopen the Services console as an administrator and try again. After the service starts, the Database Status in the console changes to Online.

Multiple instances after registration

If an ECS instance hosts multiple database instances, the Cloud Backup console displays all of them after registration.

image

Cannot retrieve database status

  • Symptom

    After a database instance is registered, the Cloud Backup console continuously fails to retrieve the database status.

    image

  • Cause

    The database backup client does not support the current operating system.

  • Solution

    Switch to a supported operating system and register the instance again.

Client-related issues

Check client status, log path, and restart

  • Linux systems

    1. Check the process status of the backup client.

      Run the systemctl status dbackup3-agent or service dbackup3-agent status command to check the process status of the Database Backup client.

      A status of active or the message dbackup3-agent is running... indicates that the client is running correctly.

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

Dec 11 13:47:34 iZbp1******gktZ systemd[1]: Started dbackup3 agent daemon.

    2. Restart the backup client.

      Run the systemctl restart dbackup3-agent or service dbackup3-agent restart command to restart the client process. When the database Client Status on the console displays Installed, the client is functioning normally.

      image

    The client log path is /var/log/dbackup3/agent.log.

  • Windows systems

    1. Press Win+R to open the Run dialog box.

    2. Enter services.msc and press Enter to open the Services console.

    3. In the services list, find the dbackup3-agent service.

    4. Check the status of the service. If the status is not Running, right-click the dbackup3-agent service and select Restart.

    The client log path is C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log.

What to do if the client is offline

  • Symptom

    The database Client Status is Offline.

    image

  • Cause

    An Offline status means Cloud Backup is not receiving heartbeat signals from the client. Common causes include the client process being terminated due to insufficient memory or the host device being shut down.

  • Solution

    Follow the instructions in How do I check the client process status, find the log path, and restart the client? to verify and restart the client. After the client status changes to Running, wait a few moments. When the database Client Status on the console changes to Installed, the client is functioning normally.

SQL Server client error: exit status 4

This error occurs because the User Account Control: Admin Approval Mode for the Built-in Administrator account policy is not enabled. Set this policy to Enabled to resolve the issue.

  1. Press Win+R to open the Run dialog box, enter gpedit.msc, and press Enter to open the Local Group Policy Editor.

  2. In the Local Group Policy Editor, navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. In the right pane, find User Account Control: Admin Approval Mode for the Built-in Administrator account and set it to Enabled.

SQL Server client installation failure

  1. Log on to the server and check the backup logs.

    Windows client log path: C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log

  2. In the log file, review the entries around the time the installation failed.

    If the log contains the error "Failed to install dbackup3-agent service, errno=1783, The stub received bad data", the system may have rejected the installation. Check if antivirus or other security software is blocking the installation and review the block logs. Add the installer to the software's allowlist or temporarily disable the security software, and then try the installation again.

ECS client installation failure

To ensure a successful installation, check the following:

  1. Cloud Assistant status: Verify that Cloud Assistant is installed on the ECS instance and is running.

    If an installation fails, you can find the record for the failed command on the Cloud Assistant console. Copy the command and run it manually on the ECS instance. If you encounter network connectivity issues or script execution errors, specific error messages appear on the screen. Use these messages to resolve the issues, for example, by adjusting your network settings.

    After you resolve all issues and the script runs successfully, the client installation is complete. Then, trigger the installation again on the Cloud Backup console to complete the process.

  2. C drive space: Ensure that the C drive has sufficient free space. Insufficient space can cause the installation to fail.

Backup issues

Free trial for local backup

The free trial for local database backup is the same as for ECS database backup. 30-day free trial.

Network requirements for local backup

The local database server must be connected to an Alibaba Cloud VPC through a leased line or VPN. Routes must be configured to allow traffic between your on-premises network and the cloud for the CIDR blocks 100.64.0.0/10 or both 100.64.0.0/11 and 100.96.0.0/11.

Real-time and incremental backup

Real-time backup can theoretically achieve seconds-level RPO and currently supports MySQL and Oracle. After you enable real-time backup, separate traditional log backup is no longer available, but you can combine it with incremental backup.

Changing backup credentials

You can use Reactivate to update the username and password for a database, for example, when a password expires. Reactivation does not affect existing backup plans but affects in-progress backup jobs. Recommended steps:

  1. On the Backup Plans tab, pause any ongoing real-time log backups.

  2. In the Actions column for the database, choose More > Reactivate.

Backup encryption

Database backups are encrypted in transit and at rest to protect your data from security risks in the cloud.

  • Encryption in transit:Data is transmitted over HTTPS with SSL/TLS encryption by default.

  • Encryption at rest: Cloud Backup encrypts backup data in the vault with AES-256. Keys are managed by Cloud Backup.

Database backup failures

MySQL

In Job History, the job status is Error.image.png

Troubleshoot as follows:

  1. Log on to the ECS instance or local server and check the status of the MySQL service.

    Run the systemctl status mysqld command. A status of active indicates a normal state, whereas inactive is abnormal. If the status is inactive, restart the service and try again.

  2. Verify that the database username, password, and permissions are correctly configured. This issue can also occur if a password expires or if a user has insufficient permissions after a change.

    The Database Account or Password that you entered during registration is incorrect, or the account has insufficient permissions. Verify that the credentials are correct and grant sufficient permissions to the backup account. We recommend creating a dedicated backup user.

    The minimum required permissions are RELOAD, LOCK TABLES, REPLICATION, and PROCESS.

  3. Log on to the server and check the backup logs.

    Log path for the Linux client: /var/log/dbackup3/agent.log

    • If the log contains the keyword uploadPart SecurityTokenExpired, the local time is incorrect. Correct the local time.

    • If the log contains the keyword ib_logfile0, a restore operation was performed before a previous one completed. This caused ib_logfile0 to be deleted but not recreated, leading to subsequent backup failures.

    • If the log contains the error message Error: failed to execute query LOCK TABLES FOR BACKUP: Access denied; you need (at least one of) the RELOAD privilege(s) for this operation, the backup account has insufficient permissions. To perform a backup job, the account needs at least the following permissions: RELOAD, LOCK TABLES, REPLICATION, and PROCESS. In MySQL 8.0, the BACKUP_ADMIN permission is also required.

    • If the log contains the error message no space left on device, a restore job for MySQL backup client version 29292 failed due to insufficient disk space. Incremental backup files need to be restored to a cache. To resolve this issue, you can create a symbolic link to point the storage path to another disk.

    • If the log backup status in the console is "Error" and the log contains the keyword @LM_ERROR@agent|To backup binlog in slave node needs to set log_slave_updates to ON, the backup node is a slave node. To perform log backups correctly, you must set log_slave_updates=1. After changing this configuration, we recommend performing a full backup before the next log backup.

Oracle

  1. Log on to the server and check the backup logs.

    Log path for the Linux client: /var/log/dbackup3/agent.log

    Log path for the Windows client: C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log

  2. In the log file, review the entries around the time the job failed. If the backup log contains any of the following error messages, use the corresponding solution:

    • If the log contains the keyword ORA-12560: TNS:protocol adapter error, check if the ORACLE_SID environment variable is unset or incorrect, as this can prevent a connection to Oracle. Try to log on by using the sqlplus command with sysdba permissions. If you can log on successfully after you correctly configure the ORACLE_SID environment variable, the issue is resolved.

    • If the log contains the keyword sbtclose2 returned error-failed to close file, the local time differs significantly from the server time, or the system time zone is set incorrectly. Change the time on the database server and restart the dbackup3-agent service. How do I check the client process status, find the log path, and restart the client?.

    • If the log contains the keyword Failed to probe oracle instances, there are two possible causes:

    • If the log contains the keyword ORA-12154: TNS:could not resolve the connect identifier specified, this error occurs when the password contains special characters that cause validation to fail.

    • If the log contains the keyword ORA-01017: invalid username/password; logon denied, reactivate the instance with the correct username and password and then perform the backup again.

    • If the log contains the keyword The difference between the request time and the current time is too large, this indicates a time mismatch between the server hosting the Cloud Backup client and the Cloud Backup server.

      Solution:

      1. Check and synchronize the time: To ensure that the server time is synchronized with Coordinated Universal Time (UTC), we recommend that you use the Network Time Protocol (NTP) service for automatic synchronization. On Linux systems, you can use the ntpdate or chrony command to synchronize the time. For manual synchronization, run the sudo ntpdate pool.ntp.org command.

      2. Check the time zone settings: To ensure that the time zone is set correctly, use the timedatectl command to view and set the time zone.

      3. Restart the backup client, then run the backup job again in the Cloud Backup console. How do I check the client process status, find the log path, and restart the client?.

SQL Server

If a backup fails when you use Cloud Backup to back up an SQL Server database, follow these steps:

  1. Log on to the server and check the backup logs.

    The Windows client log path is: C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log

  2. In the log file, find entries corresponding to the failure time from the console's error record. If the backup log contains any of the following error messages, use the corresponding solution:

    • Error: The login does not have sufficient permissions.

      Cause: The SQL Server backup user has insufficient permissions.

      Solution: Check the backup account and its permissions. Step 2: Create a backup account and configure permissions.

    • Error: Login failed for user 'xxx'.

      Cause: The password for the SQL Server backup user has expired (Error Code: 18487, SQL State: 28000).

      Solution: Change the backup user's password in SQL Server. Then, log on to the Cloud Backup console and in the Actions column for the database, choose More > Reactivate.

      image

    • Error: Cannot overwrite the file.

      Cause: The SQL Server database restore path is being used by another database.

      Solution: Create a new restore job. When you restore from a specified backup, double-click the restore path to modify it.

      image

    • Error: The target SQL Server database does not exist. Please ensure that you have entered the name correctly.

      Cause: The target SQL Server database does not exist.

      Solution: Confirm that the target database exists. If the database no longer exists, edit the backup plan and remove it.

    • Error: The database is participating in a database mirroring session or an availability group. Some operations are not allowed on a database that is participating in a database mirroring session or an availability group.

      Cause: SQL Server Always On is enabled for the SQL Server database.

      Solution: The target instance is not bound to an Always On availability group. Select the correct availability group.

    • Error: The database is configured for database mirroring or is joined to an availability group. If you want to restore the database, use ALTER DATABASE to remove mirroring or remove the database from its availability group.

      Cause: SQL Server Always On is enabled for the SQL Server database.

      Solution: The target instance is not bound to an Always On availability group. Select the correct availability group.

    • Error:

      The backup job fails in the console with the message "Job failed, error: -1 Backup or restore of database ""xxx"" failed, VDI error "0x80770004"". 

      image

      Troubleshooting steps:

      1. Go to the C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log directory and open the log file. Based on the time range (start and end times) of the error record in the console, locate the logs around the time the job failed.

      2. If the log contains "Failed to receive WebSocket data from x.x.x.x:60305, errno=10054, connection reset" or "Failed to open socket x.x.x.x:60305, errno=10060, connection timed out", the connection between the client and the backup server was interrupted. Check your network connectivity.

      3. When "Channel xxxxxxxxxxxxxx is registered" appears in subsequent logs, the client has reconnected to the server after retrying. At this point, you can trigger a new backup job or wait for the next scheduled job to run and check whether the backup proceeds normally.

      4. If the backup still fails or other errors occur, we recommend that you join the internal support group or contact a service expert for further technical support. You can send logs through DingTalk.

        • Cloud Backup technical support group

          Get quick answers to questions about costs, features, and usage. Click to join Cloud Backup online support (we recommend using Chrome). Search for the public group and join. The DingTalk group number is 88650005148.

        • Cloud Backup expert support

          Technical experts provide on-site analysis to quickly resolve product issues. Click to contact Cloud Backup support (we recommend using Chrome). Add the DingTalk contact. The DingTalk ID is d37_g935gslgo.

Oracle: Failed to get install path error

  • Symptom

    An Oracle data backup fails, and the following error appears in the log.

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

  • Cause

    Oracle 12c and later versions support running the Oracle service as a virtual user. However, the Cloud Backup client runs as the system user. As a result, the Oracle service might not have permission to access certain directories created by the backup software.

  • Solution

    Manually grant the Users group Full Control permissions. To do this, perform the following steps:

    1. Open Registry Editor. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\scutech\dbackup3, right-click the agent directory, and select Permissions.

    2. In the Permissions for agent dialog box, click the Users group, select the Allow check box for the Full Control permission, and then click OK.

      image

Slow Oracle incremental backups

  • Symptom

    An incremental backup or log backup takes as long as or longer than a full backup.

  • Solution

    Enable Block Change Tracking (BCT) in Oracle. BCT accelerates RMAN incremental backups by tracking data block changes and is disabled by default.

    Pros and cons of BCT

    Pros

    Cons

    • Accelerates RMAN incremental backups

      The BCT file records data block modifications, allowing RMAN to locate changed blocks directly from the file instead of scanning the entire database during an incremental backup. For large databases, this can reduce incremental backup time by more than 90%. For example, a full scan of a 1 TB database might take 1 hour, while BCT can complete an incremental backup in a few minutes.

    • Reduces I/O load

      BCT reduces physical reads by reading the BCT file directly, which avoids full table scans and lessens the backup's impact on the production environment.

    • Low resource consumption

      BCT has minimal memory overhead. The BCT file is typically only a few hundred megabytes. For example, a 1 TB database requires a BCT file of about 100 to 200 MB.

    • Compatibility

      BCT supports all Oracle versions from 10g R2. In Oracle 12c and later, it supports redundant configurations with multiple BCT file replicas for improved fault tolerance.

    • Additional disk space usage

      • File size: Although the file is only a few hundred megabytes, ensure the storage path has enough space.

      • Redundancy configuration: If you configure multiple replicas (such as REDUNDANCY 2), the disk usage will double.

    • Minor performance impact

      • Write operation overhead: Each time a data block is modified, the BCT file needs to be updated, which may have a slight performance impact on systems with high write loads.

      • Test scenario: In an OLTP system with tens of thousands of transactions per second, the performance impact of BCT is usually negligible. However, monitoring is required in extreme high-concurrency scenarios.

    • Risk of file corruption

      • Single point of failure: If the BCT file is corrupted and no redundancy is configured, incremental backups may fail.

      • Repair complexity: You need to re-enable BCT and rebuild the file, which may require a short downtime.

    Recommended scenarios for enabling BCT:

    • Frequent incremental backups: Systems that perform daily or hourly RMAN incremental backups.

    • Large databases: Optimization of incremental backup time for terabyte-scale databases.

    • High availability requirements: Production environments that require fast recovery and rely on incremental backups.

    Scenarios where you should enable BCT with caution:

    • Very small databases: For databases smaller than 1 GB, the benefits of BCT may not be significant.

    • Extreme high-write loads: For OLTP systems with tens of thousands of transactions per second, the performance impact needs to be considered.

    • Limited storage space: If disk space is limited, the storage requirements of the BCT file need to be evaluated.

Oracle: RMAN non-fatal error

  • Symptom

    Oracle full backups are successful, but incremental backups consistently fail. The following error is reported:

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

  • Cause

    The required archived logs cannot be found. They may have been backed up and moved by another backup script or tool. Check whether any scripts or software other than Cloud Backup is performing backups.

  • Solution

    We strongly recommend against using Cloud Backup concurrently with other backup software or scripts, as this can cause backups to fail or become unrecoverable.

SQL Server: Failed to browse database

  • Symptom

    When you create or edit a backup plan for SQL Server 2019 and select a database instance, the console displays the error message "Failed to list unibackup instance detail".

  • Cause

    When you back up SQL Server 2019, if other backup software or scripts are running at the same time, browsing database details may fail when you create or edit a backup plan and select a database instance.

    image

  • Solution

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

    2. In the Services console (services.msc), find and restart the dbackup3-agent service.

SQL Server: Incorrect IP in console

  • Symptom

    After registering a local SQL Server database, the IP address in the console does not match the machine's local IP, even though the client status is normal.

    image

  • Cause

    In a multi-NIC environment, Cloud Backup may retrieve the IP address from an unused NIC.

  • Solution

    Disable the unused NIC and reinstall the client.

SQL Server: TDE backup support

Cloud Backup does not support backing up SQL Server databases that have Transparent Data Encryption (TDE) enabled.

SQL Server: Anti-ransomware service issues

  • Symptom

    After you deploy the anti-ransomware service for an SQL Server database, the client is offline, the anti-ransomware policy cannot be deleted, and the client cannot be uninstalled.

    image

    In Windows Task Manager, the dbackup3-agent service is stopped, and the agent log contains entries similar to "Stopping all jobs".

    image

  • Cause

    The client is blocked by antivirus software. Check the antivirus software for any related block records from around that time.

  • Solution

    Add the client to the allowlist in the antivirus software, and then restart the client service or reinstall the client.

Backup issues after ECS account transfer

When an ECS instance is transferred to a new Alibaba Cloud account, its metadata is not automatically synchronized with Cloud Backup. Contact Cloud Backup support to complete the backend synchronization before installing and using the feature.

  • Cloud Backup technical support group

    Get quick answers to questions about costs, features, and usage. Click to join Cloud Backup online support (we recommend using Chrome). Search for the public group and join. The DingTalk group number is 88650005148.

  • Cloud Backup expert support

    Technical experts provide on-site analysis to quickly resolve product issues. Click to contact Cloud Backup support (we recommend using Chrome). Add the DingTalk contact. The DingTalk ID is d37_g935gslgo.

MySQL backup limitations

Yes. Limits apply to supported database versions, operating systems, and backup features. For example, MySQL on Windows is not supported. Compatibility list and limits.

Backing up a new MySQL database

MySQL backups are performed at the instance level. New databases are automatically included in the next backup job.

Canceling a database backup

MySQL

After you correctly cancel a database backup, you will not incur further fees, and all associated resources will be released.

Important

Canceling a database backup permanently deletes your backup data. This action cannot be undone. Please evaluate the impact before proceeding.

  1. Delete the backup plan.

  2. Unregister the instance. When you unregister an ECS instance database, the installed backup client is automatically uninstalled.

  3. If the database is on a local server, log on to the server and uninstall the client.

    • Linux:

      • CentOS

        sudo rpm --erase "dbackup3-agent-mysql"
sudo rpm --erase "dbackup3-agent"
sudo rpm --erase "dbackup3-common"

      • Ubuntu

        sudo dpkg -r "dbackup3-agent-mysql" "dbackup3-agent" "dbackup3-common"

  4. Delete the following directories:

    • Linux:

      /etc/default/dbackup3*
/opt/scutech
/var/opt/scutech/
/var/log/dbackup3/
/etc/opt/scutech/

  5. Delete the backup vault.

    In the left-side navigation pane, select Vault Management, find the corresponding backup vault, and delete it.

Oracle

After you correctly cancel a database backup, you will not incur further fees, and all associated resources will be released.

Important

Canceling a database backup permanently deletes your backup data. This action cannot be undone. Please evaluate the impact before proceeding.

  1. Delete the backup plan.

  2. Unregister the instance. When you unregister an ECS instance database, the installed backup client is automatically uninstalled.

  3. If the database is on a local server, log on to the server and uninstall the client.

    • Windows:

      1. Go to the backup client installation directory in PowerShell. For example, C:\Program Files\aliyun\unibackup>.

      2. Run the command.

         .\uninstall-unibackup.exe /S /NCRC

    • Linux:

      • CentOS

        sudo rpm --erase "dbackup3-agent-oracle"
sudo rpm --erase "dbackup3-agent"
sudo rpm --erase "dbackup3-common"

      • Ubuntu

        sudo dpkg -r "dbackup3-agent-oracle" "dbackup3-agent" "dbackup3-common"

  4. Clear the configuration files.

    • Windows:

      Delete all configuration files under c:\programdata\scutech.

    • Linux:

      Delete the following directories:

      /etc/default/dbackup3*
/opt/scutech
/var/opt/scutech/
/var/log/dbackup3/
/etc/opt/scutech/

  5. Delete the backup vault.

    In the left-side navigation pane, click Vault Management, find the corresponding backup vault, and delete it.

SQL Server

After you correctly cancel a database backup, you will not incur further fees, and all associated resources will be released.

Important

Canceling a database backup permanently deletes your backup data. This action cannot be undone. Please evaluate the impact before proceeding.

  1. Delete the backup plan.

  2. Unregister the instance. When you unregister an ECS instance database, the installed backup client is automatically uninstalled.

  3. If the database is on a local server, log on to the server and uninstall the client.

    • Windows:

      1. Go to the backup client installation directory in PowerShell. For example, C:\Program Files\aliyun\unibackup>.

      2. Run the uninstall-unibackup.exe command and follow the wizard to complete the uninstallation.

  4. Delete all configuration files under c:\programdata\scutech.

  5. Delete the backup vault.

    In the left-side navigation pane, click Vault Management, find the corresponding backup vault, and delete it.

Duplicate backup records

This issue occurs when the server hosting the backup client is cloned, or a new instance is created from an image that contains the client. The cloned server retains the original client's identity, causing duplicate records. Log on to the cloned server and uninstall the client:

MySQL

When you unregister an ECS instance database, the installed backup client is automatically uninstalled. If the MySQL database is installed on a local server, uninstall the client as follows:

  1. Uninstall the client.

    Linux:

    • CentOS

      sudo rpm --erase "dbackup3-agent-mysql"
sudo rpm --erase "dbackup3-agent"
sudo rpm --erase "dbackup3-common"

    • Ubuntu

      sudo dpkg -r "dbackup3-agent-mysql" "dbackup3-agent" "dbackup3-common"

  2. Delete the following directories:

    Linux:

    /etc/default/dbackup3*
/opt/scutech
/var/opt/scutech/
/var/log/dbackup3/
/etc/opt/scutech/

Oracle

When you unregister an ECS instance database, the installed backup client is automatically uninstalled. If the Oracle database is installed on a local server, uninstall the client as follows:

  1. Uninstall the client.

    • Windows:

      1. Go to the backup client installation directory in PowerShell. For example, C:\Program Files\aliyun\unibackup>.

      2. Run the command.

         .\uninstall-unibackup.exe /S /NCRC

    • Linux:

      • CentOS

        sudo rpm --erase "dbackup3-agent-oracle"
sudo rpm --erase "dbackup3-agent"
sudo rpm --erase "dbackup3-common"

      • Ubuntu

        sudo dpkg -r "dbackup3-agent-oracle" "dbackup3-agent" "dbackup3-common"

  2. Clear the configuration files.

    • Windows:

      Delete all configuration files under c:\programdata\scutech.

    • Linux:

      Delete the following directories:

      /etc/default/dbackup3*
/opt/scutech
/var/opt/scutech/
/var/log/dbackup3/
/etc/opt/scutech/

SQL Server

When you unregister an ECS instance database, the installed backup client is automatically uninstalled. If the SQL Server database is installed on a local server, uninstall the client as follows:

  1. Uninstall the client.

    • Windows:

      1. Go to the backup client installation directory in PowerShell. For example, C:\Program Files\aliyun\unibackup>.

      2. Run the uninstall-unibackup.exe command and follow the wizard to complete the uninstallation.

  2. Clear the configuration files.

    • Windows:

      Delete all configuration files under c:\programdata\scutech.

Backup plan status: Error

image

If a backup plan fails and its status changes to "Error," the host server may have been cloned, reimaged, or had its system disk reset. These actions sever the link between the backup plan and the client. To resolve this:

  1. Uninstall the client and its configuration files from the cloned server. Uninstall the client.

  2. Make sure that the client status on the current server is "Installed".

    image

  3. After you complete the preceding steps, delete the original backup plan from the console and create a new one.

Alert time mismatch

SMS alerts triggered between 20:00 and 08:00 (UTC+8) are delayed until after 08:00. Email alerts are sent immediately.

Conflicting backup history records

This issue occurs when the server hosting the backup client is cloned, or a new instance is created from an image that contains the client. The cloned server retains the original client's identity, causing duplicate records. Log on to the cloned server and uninstall the client:

MySQL

When you unregister an ECS instance database, the installed backup client is automatically uninstalled. If the MySQL database is installed on a local server, uninstall the client as follows:

  1. Uninstall the client.

    Linux:

    • CentOS

      sudo rpm --erase "dbackup3-agent-mysql"
sudo rpm --erase "dbackup3-agent"
sudo rpm --erase "dbackup3-common"

    • Ubuntu

      sudo dpkg -r "dbackup3-agent-mysql" "dbackup3-agent" "dbackup3-common"

  2. Delete the following directories:

    Linux:

    /etc/default/dbackup3*
/opt/scutech
/var/opt/scutech/
/var/log/dbackup3/
/etc/opt/scutech/

Oracle

When you unregister an ECS instance database, the installed backup client is automatically uninstalled. If the Oracle database is installed on a local server, uninstall the client as follows:

  1. Uninstall the client.

    • Windows:

      1. Go to the backup client installation directory in PowerShell. For example, C:\Program Files\aliyun\unibackup>.

      2. Run the command.

         .\uninstall-unibackup.exe /S /NCRC

    • Linux:

      • CentOS

        sudo rpm --erase "dbackup3-agent-oracle"
sudo rpm --erase "dbackup3-agent"
sudo rpm --erase "dbackup3-common"

      • Ubuntu

        sudo dpkg -r "dbackup3-agent-oracle" "dbackup3-agent" "dbackup3-common"

  2. Clear the configuration files.

    • Windows:

      Delete all configuration files under c:\programdata\scutech.

    • Linux:

      Delete the following directories:

      /etc/default/dbackup3*
/opt/scutech
/var/opt/scutech/
/var/log/dbackup3/
/etc/opt/scutech/

SQL Server

When you unregister an ECS instance database, the installed backup client is automatically uninstalled. If the SQL Server database is installed on a local server, uninstall the client as follows:

  1. Uninstall the client.

    • Windows:

      1. Go to the backup client installation directory in PowerShell. For example, C:\Program Files\aliyun\unibackup>.

      2. Run the uninstall-unibackup.exe command and follow the wizard to complete the uninstallation.

  2. Clear the configuration files.

    • Windows:

      Delete all configuration files under c:\programdata\scutech.

Restore issues

"View offline instances only" feature

The View offline instances only feature is useful in scenarios where a client can no longer connect to its original instance server or restore backup data. This can happen if the client machine's operating system is reinstalled or if malicious software deletes the client process and configuration. In these cases, if you install a new client, the system assigns a different instance ID to distinguish the new client from the offline instance and prevent confusion. You can then restore data from the offline instance to the new instance. For restore steps, see Restore MySQL, Restore Oracle, and Restore SQL Server.

SQL Server database restore failure

  1. Log on to the server and view the backup log.

    Windows client log path: C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log

  2. In the log, check the entries around the time the task failed.

    If the backup log contains the keyword RestoreContainer::ValidateTargetForCreation, it indicates that you tried to restore a database to a new path without changing its name. This caused a name conflict and the restore operation failed. To restore the database successfully, change both the database name and path.

SQL Server restore failure: File initialization error

  • Symptom

    When an SQL Server restore fails, the agent log indicates that a file failed to initialize correctly. The log contains the following details:

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

    Additionally, the SQL Server error log contains the message the file "xxx_log" failed to initialize correctly.

    image

  • Cause

    If a source database on SQL Server 2008 R2 was previously encrypted, disabling encryption can leave behind residual information. When you back up this database and restore the backup set to another instance, an initialization error occurs. The analysis process is as follows:

    Note

    If the source database is SQL Server 2008 R2 and has TDE enabled, the restore operation fails even if the target instance is a later version, such as SQL Server 2014. The error message "Certificate not found" is returned. To complete the restore, you must manually restore the certificate and private key.

    1. Confirm the database version from the SQL Server error log.

      image

    2. This issue is likely related to Transparent Data Encryption (TDE). Confirm whether TDE is enabled on the source database and check if encryption was recently disabled.

      Execute the following SQL statement on the source database. If the key_algorithm and key_length fields in the query result are not NULL, the database was previously encrypted.

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

      The following figure shows a sample query result.

      image

  • Solution

    • Upgrade the source database to a later version and create a new backup. Use this new backup set for the restore, as previous backup sets are invalid.

    • Restore the private key and certificate from the source instance to the target instance, and then restore the database.

      After the restore is complete, delete the TDE certificate and database encryption key from the target instance. Then, back up the target instance. Subsequent backup and restore operations on the target instance will then work correctly.

      Note

      Even if the data backup was created after TDE was disabled, the restore process still requires the private key and certificate to process the residual encrypted metadata in the backup. However, the restored database is not encrypted and can be used normally without the certificate.

      # Perform the following operations on the source instance
USE master;

# 1. Query the certificate name for the TDE-encrypted database.
SELECT d.name AS DatabaseName,
       k.encryption_state,
       c.name AS CertificateName
FROM sys.dm_database_encryption_keys AS k
JOIN sys.certificates AS c
    ON k.encryptor_thumbprint = c.thumbprint
JOIN sys.databases AS d
    ON k.database_id = d.database_id

# Assume the CertificateName in the result is TDECert. Back up the TDE certificate and private key to a custom path.
BACKUP CERTIFICATE TDECert
   TO FILE = 'C:\Backup\TDECert.cer'  -- Specify a custom file path
   WITH PRIVATE KEY (
        FILE = 'C:\Backup\TDECert_PrivateKey.pvk',    -- Specify a custom file path
        ENCRYPTION BY PASSWORD = 'Strong_Password_123!'    -- Remember this password
   );

-- Copy the certificate and private key from the preceding path to the target instance.

# 2. Perform the following operations on the target instance.
USE master;

# Restore the database master key. If the message 'The master key already exists in the database. Drop the master key before you perform this statement.' is returned, skip this step.
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Another_Strong_Password_456!';

# Restore the TDE certificate.
CREATE CERTIFICATE TDECert -- Specify a custom certificate name. You will use it later for deletion.
    FROM FILE = 'C:\TDE_Test\TDECert.cer' -- The path where the copied files are located
    WITH PRIVATE KEY (
        FILE = 'C:\TDE_Test\TDECert_PrivateKey.pvk',
        DECRYPTION BY PASSWORD = 'Strong_Password_123!'  -- The password used to back up the private key
    );


# 3. Perform the restore steps in the Cloud Backup console as usual.


# 4. After the restore, delete the database encryption key.
USE TDE_TestDB_Restore -- The name of the target database
DROP DATABASE ENCRYPTION KEY;

# 5. Delete the certificate.
USE master;
DROP CERTIFICATE TDECert;

Cross-database restore between local and ECS databases

Direct restores between these database types are not supported. You can register the database on the ECS instance as a local database instance. After registration, you can restore data between the two instances.

Backup vault issues

Database backup vault

A database backup plan requires a database backup vault.

A database backup vault stores your database backups. You are billed for the vault rental fee and storage usage. Billing methods and billable items.

Purging expired data

Incremental, cumulative incremental, and log backups depend on a complete backup chain starting from the initial full backup. All backups in the chain are retained until the last one expires. Configure the backup cycle and retention period carefully.

For example, you perform a full backup on September 1 and an incremental backup every day from September 2 to September 7. The retention period is 7 days. When the entire chain expires on September 14, the seven backups are automatically deleted.

Data size, vault usage, and billing

The Source Data Size is the cumulative total of all data you back up. For example, if you back up a 1 TB file twice, Cloud Backup creates two independent copies, and the Source Data Size is 2 TB. Cloud Backup uses deduplication and compression to reduce the storage your backups consume in the vault, saving you storage costs. You are billed based on the actual Storage Vault Data Size. You can view both the Source Data Size and Storage Vault Data Size of a database backup vault on the Vault Management page.

Previous：Set alerts for Database BackupNext：SAP HANA Backup