Cloud Backup:Database backup FAQ

Database instance issues

• What should I do if a database instance fails to register with Database Backup?

• How do I resolve the "Inactivated" status for a database instance?

• How do I resolve the "DB Offline" status for a database instance?

• Why do multiple database instances appear on the ECS Database Instance tab after I register a database instance?

• What should I do if the database status cannot be retrieved after I register a database instance?

Client issues

• How do I view the client process status, find the log path, and restart the client?

• How do I resolve the "Offline" status for a database client?

• How do I resolve the "Failed to run install script:exit status 4" error when installing the backup client for a local SQL Server database?

• How do I resolve a backup client installation failure when backing up a local SQL Server database?

• How do I resolve a Database Backup client installation failure on an ECS instance?

Backup issues

• How can I get a free trial of the local database backup feature?

• What are the network requirements for backing up a local database?

• What is the minimum interval for real-time backup? Can I configure real-time backup and incremental backup at the same time?

• How do I change the username and password for Database Backup?

• Are database backups encrypted?

• What should I do if a database backup fails?

• What should I do if an Oracle data backup fails and the log contains the "Failed to get install path from registry" error?

• What should I do if an incremental backup of Oracle data takes as long as or longer than a full backup?

• How do I resolve the "RMAN reports a non-fatal error" error during an Oracle incremental backup?

• What should I do if I fail to view database details when backing up an SQL Server 2019 database?

• What should I do if the IP address of a registered local SQL Server database displayed on the Cloud Backup console does not match its actual IP address?

• Can I back up an SQL Server database to Alibaba Cloud after enabling Transparent Data Encryption (TDE)?

• What should I do if the client is offline, cannot be uninstalled, and the anti-ransomware policy cannot be deleted after I deploy the anti-ransomware service for a SQL Server database?

• What should I do if I cannot properly install or use Database Backup after transferring an ECS instance from one Alibaba Cloud account to another?

• What MySQL database versions and operating systems are supported for backup?

• How do I back up a newly created database in MySQL?

• How do I cancel a database backup?

• Why does the backup history contain duplicate or unexpected backup records?

• Why does a backup fail and the backup plan status show "Error"?

• Why is the alert time different from the time when the error actually occurred?

• Why do I receive a failure alert, but the backup history shows both a successful and a failed backup record for the same time?

Restore issues

• How does the "View Offline Instances Only" feature work?

• What should I do if an SQL Server database restore fails?

• How do I resolve an SQL Server restore failure when the agent log indicates a file initialization error?

• How do I perform a cross-database restore between a local database and a database on an ECS instance?

Backup vault issues

• What is a database backup vault?

• How is expired data purged from a database backup vault?

• How do I view backup data size and backup vault usage? How is billing calculated?

Instance registration failure

First, check if the backup client is installed on your server (a local server or an ECS instance). If it is, uninstall it and remove its configuration files by following the instructions in Uninstall the client. Then, try registering the instance again.

Inactive instance status

Offline instance status

Multiple instances after registration

If multiple database instances are deployed on a single ECS instance, the Cloud Backup console scans and displays all of them during registration.

On the ECS database instance tab, the console displays multiple database instances on the same ECS instance as separate records. Each record corresponds to a different instance name and port number.

Cannot retrieve database status

• Symptom

  After a database instance is registered, the Cloud Backup console cannot retrieve its status.

  In the console, the database status column continuously displays a loading icon.

• Cause

  The current operating system is not supported by the database.

• Solution

  Switch to a supported operating system and try again.

Check client status, log path, and restart

• Linux

  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.

     An output of active or 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.

     After you restart the client process by running the systemctl restart dbackup3-agent or service dbackup3-agent restart command, the client status has returned to normal if the database Client Status on the console is Installed.

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

• Windows

  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 service list, find the dbackup3-agent service.

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

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

Resolve "Offline" client status

• Symptom

  The database's Client Status is Offline.

  At this point, the Client Status is Offline, and the database status is Unknown.

• Cause

  The Offline status indicates a loss of heartbeat from the client, commonly caused by the client process being terminated due to insufficient memory or the host device being powered off.

• Solution

  Check and restart the client as described in How do I check the client process status, find the log path, and restart the client?. After the client status changes to Running, wait until the database's Client Status in the console changes to Installed. This indicates that the client has returned to normal.

Resolve "exit status 4" installation error

This error occurs because the local security policy setting "User Account Control: Admin Approval Mode for the Built-in Administrator account" is not enabled. This policy must be set to Enabled.

1. Press Win+R to open the Run command, enter gpedit.msc to run 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 change its status to Enabled.

Resolve client installation failures for local SQL Server

1. Log on to the server and check 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 error message Failed to install dbackup3-agent service, errno=1783, The stub received bad data, the system may have rejected the installation. Check if any antivirus or security software has blocked the installation and review the block records. Add the installer to the allowlist or temporarily disable the security software, then try the installation again.

Resolve client installation failures on ECS

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 properly.

   If the installation fails, you can usually find a failed command record in the Cloud Assistant console. Copy the command and run it manually on the ECS host. During manual installation, if network or script execution errors occur, specific error messages will appear. Use these messages to resolve the issues, for example, by adjusting network settings.

   After you resolve the issues and the script runs successfully, the client is installed. Then, re-trigger the installation from the console to complete the process.

2. C drive space: Ensure that the C drive has enough free space. Insufficient space will prevent the client installation.

Free trial for local database backup

The free trial process for local database backup is the same as for ECS database backup. For details, see 30-day free trial.

Network requirements

You must connect your on-premises database server to an Alibaba Cloud virtual private cloud (VPC) through a leased line or VPN. You must also configure routing from your on-premises network to the following CIDR blocks in the cloud: 100.64.0.0/10 and 100.96.0.0/11.

Real-time backup interval and incremental backup

A real-time backup can achieve a seconds-level RPO and currently supports MySQL and Oracle databases. After you enable real-time backup, you cannot configure a separate traditional log backup. However, you can combine it with an incremental backup to improve your data protection.

Change database backup credentials

Use Reactivate to change the backup credentials, for example, when a password expires. Reactivation does not affect existing backup plans but does affect any backup jobs in progress. To minimize the impact, do the following:

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

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

Database backup encryption

Yes, database backups are encrypted to protect your data from security risks. This includes both encryption in transit and encryption at rest.

• Encryption in transit:By default, data is encrypted in transit using HTTPS, which is based on secure sockets layer/transport layer security (SSL/TLS). SSL/TLS ensures confidentiality and data integrity between communicating applications.

• Encryption at rest: Cloud Backup encrypts your backup data in the backup vault using the AES-256 algorithm and provider-managed keys.

Handling database backup failures

Oracle backup error: Failed to get install path from registry

• Symptom

  An Oracle data backup fails, and the log contains the following error message:

  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. This can cause a permission conflict that prevents Oracle from accessing directories created by the backup software.

• Solution

  Manually grant the Full Control permission to the Users group. Follow these steps:

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

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

Incremental backup is as slow as full backup

• Symptom

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

• Solution

  Enable Block Change Tracking (BCT) in your Oracle database. BCT accelerates RMAN incremental backups by tracking data block changes to reduce backup time. This feature is disabled by default and must be enabled manually.

  Pros and cons of BCT

  Pros

  Cons

  Accelerates RMAN incremental backups The BCT file records changes to data blocks. During an RMAN incremental backup, RMAN locates changed blocks by reading the BCT file instead of scanning the entire database. For large databases, this can reduce the incremental backup time by more than 90%. For example, a full scan of a 1 TB database might take an hour, while an incremental backup using BCT takes only minutes. Reduces I/O load It reduces physical reads. During a backup, the BCT file is read directly, which avoids a full table scan and reduces the impact on the production environment. Low resource consumption Requires almost no memory overhead. The BCT file is typically only a few hundred megabytes. For example, the BCT file for a 1 TB database is about 100 MB to 200 MB. Compatibility Supports all Oracle versions starting from 10g R2. Oracle 12c and later support redundant configurations with multiple BCT file copies to improve fault tolerance.

  Requires additional storage space File size: Although the file is only a few hundred megabytes, you must ensure that the storage path has enough space. Redundant configuration: If you configure multiple copies, for example, with REDUNDANCY 2, the required storage space doubles. Minor performance impact Write operation overhead: When a data block is modified, the BCT file must also be updated. This can slightly impact performance on systems with a high write load. Example scenario: In an online transactional processing (OLTP) system with tens of thousands of transactions per second, the performance impact of BCT is usually negligible. However, you should monitor performance 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 may need to re-enable BCT and rebuild the file, which could require brief downtime.

  Recommended scenarios for enabling BCT:

  • Systems that perform daily or hourly RMAN incremental backups.

  • Terabyte-scale databases that require faster incremental backups.

  • Production environments that require high availability and fast recovery, and rely on incremental backups.

  Use caution when enabling BCT in the following scenarios:

  • Very small databases, such as those under 1 GB, where the benefits of BCT are minimal.

  • OLTP systems with an extremely high write load, such as tens of thousands of transactions per second, where you must weigh the potential performance impact.

  • Environments with limited storage space, where you need to evaluate the storage requirements of the BCT file.

RMAN non-fatal error during Oracle incremental backup

• Symptom

  A full backup of your Oracle database succeeds, but incremental backups consistently fail. You receive an error message similar to the following:

  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

  This issue is caused by missing archive logs. Another backup script or backup task may have moved the logs, preventing Cloud Backup from finding the files required for the incremental backup.

• Solution

  Do not use Cloud Backup concurrently with other backup software or backup scripts. Running multiple backup tools concurrently can cause conflicts, leading to backup failures or preventing successful restores.

Failed to list SQL Server 2019 database details

• 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

  This error occurs if another backup software or script performs a concurrent backup on SQL Server 2019 while you are creating or editing a backup plan.

  The console then displays an error dialog with the message: "Failed to list unibackup instance detail".

• 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.

Incorrect local SQL Server IP address

• Symptom

  After you register a local SQL Server database with Cloud Backup, the IP address in the Cloud Backup console does not match the host's local IP address. This issue occurs even when the local client is running normally and its IP address has not been changed.

  On the Local Database Instance tab, the IP address in the Client IP address column is in the 169.x.x.x range, which is different from the local IP address.

• Cause

  In a multi-NIC environment, Cloud Backup retrieves the IP address of an unused network interface on the host.

• Solution

  To resolve this issue, disable the unused network interface, and then reinstall the client.

SQL Server TDE backup

No, this is not supported.

Troubleshoot an offline client that cannot be uninstalled

• Symptom

  After you deploy the anti-ransomware service for an SQL Server instance, the client appears offline, attempts to delete the anti-ransomware policy fail, and you cannot uninstall the client.

  On the anti-ransomware management page on the console, the client status for the SQL Server instance is Offline, and you cannot delete the anti-ransomware policy.

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

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

• Cause

  Antivirus software has blocked the client. Check your antivirus software for any related block records from around that time.

• Solution

  Add the client to the allowlist in your antivirus software, and restart the client service (or reinstall the client).

Database backup issues after an ECS instance transfer

After an ECS instance is transferred from its original Alibaba Cloud account to a new one, its ECS metadata is not automatically synchronized to the Cloud Backup service. You must synchronize the ECS metadata in the Cloud Backup service backend before you can install and use the database backup feature. For detailed steps, contact Cloud Backup Support or join the Cloud Backup Online Support DingTalk group.

• Cloud Backup Technical Support Group

  Get quick answers to your questions about pricing, features, and usage. Click to join Cloud Backup Online Support (Chrome is recommended). Search for and join the public group using DingTalk ID 88650005148.

• Cloud Backup Expert Support

  Technical experts provide live analysis to quickly resolve product issues. Click to contact Cloud Backup support (Chrome is recommended). Add the contact on DingTalk using the ID: d37_g935gslgo.

MySQL version and OS limitations

There are limitations on supported database versions, operating systems, and backup features. For example, MySQL databases deployed on Windows are not supported. For more information, see Compatibility list and limits.

Backing up a new database

Since MySQL backups are performed at the instance level, any new databases are automatically included in the next backup cycle with no manual configuration required.

Cancel a database backup

Duplicate or unexpected backup records

This occurs when you clone a server (a local server or an ECS instance) that has the database backup client installed, or when you create a new ECS instance or local server from an image that includes the same client. The cloned server retains some client information from the original server, which causes duplicate backup records. To resolve this issue, log on to the cloned server and uninstall the client. To uninstall the database backup client, follow the relevant instructions below.

Backup plan error

If a backup fails and the backup plan status is "Error", first check whether the server (a local server or ECS instance) where the client is installed has been cloned, had its operating system reinstalled, or had its system disk reset. These operations can break the association between the backup plan and the client. To resolve this issue, follow these steps:

1. Uninstall the client and remove its configuration file from the cloned server. For more information, see Uninstall the client.

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

3. Delete the original backup plan in the console and create a new backup plan.

Alert time inconsistency

With nighttime suppression, text message alerts triggered between 8:00 PM and 8:00 AM are not sent until after 8:00 AM. In contrast, email alerts are sent immediately.

Duplicate success and failure backup records

This occurs when you clone a server (a local server or an ECS instance) that has the database backup client installed, or when you create a new ECS instance or local server from an image that includes the same client. The cloned server retains some client information from the original server, which causes duplicate backup records. To resolve this issue, log on to the cloned server and uninstall the client. To uninstall the database backup client, follow the relevant instructions below.

View Offline Instances Only feature

The View Offline Instances Only feature applies to scenarios where a client can no longer connect to its original instance, making it necessary to restore data from a backup. This can happen if the operating system on the client is reinstalled or if the client process and configuration are deleted, for example, by a malicious program. In such cases, if you install a new client, the system assigns it a different instance ID to distinguish it from the offline instance and prevent confusion. You can then restore data from the offline instance to the new one. For detailed instructions, see Restore MySQL, Restore Oracle, and Restore SQL Server.

Resolving SQL Server restore failures

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 the restore operation failed because you changed the database path but not the database name, which caused a name conflict. To successfully restore the database, change both the database name and the path.

SQL Server restore failure: File initialization error

• Symptom

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

  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 ErrorLog reports the message the file "xxx_log" failed to initialize correctly.

• Cause

  This error can occur when restoring a backup of a SQL Server 2008 R2 database that was previously encrypted. Even after disabling encryption, residual information can remain in the backup set, causing the file initialization error when you restore it. The analysis process is as follows.

  Note

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

  1. Confirm the database version from the SQL Server ErrorLog.

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

  2. This issue is often related to transparent data encryption (TDE). Confirm whether TDE was ever enabled on the source database, even if it is currently disabled.

     Run the following SQL statement on the database. If the key_algorithm and key_length columns for your database in the query result are not NULL, the database was likely encrypted in the past.

     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;

     An example query result is as follows.

     In the query results, if the values of the key_algorithm and key_length fields for a database are not NULL, it indicates that TDE encryption has been enabled for that database.

• Solution

  • Upgrade the source database to a later version and create a new backup. Use the new backup set to perform the restore operation. Previous backup sets are invalid.

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

    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 function correctly.

    Note

    Even if the data backup was created after TDE was disabled, the restore process still requires the private key and certificate. They are required to handle residual encrypted metadata in the backup. However, the restored database itself is not encrypted and can run normally without the certificate afterward.

    # On the source instance, run the following commands.
    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. On the target instance, run the following commands.
    USE master;
    
    # Restore the master key. If you receive the message 'The master key already exists in the database. Drop the master key before you perform this statement.', 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 when backing up the private key.
        );
    
    # 3. Perform the restore 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: Local and ECS

Direct restore between these two environments is not supported. You must first register the database on the ECS instance as a local database instance. After registration, you can restore data between different local database instances.

What is a database backup vault?

You must create a database backup vault before you can create a database backup plan.

A database backup vault is a repository that stores your database backups. The vault rental fee and the vault capacity determine the cost of a database backup. For more information, see Billing methods and billable items.

Purging expired backups

Incremental backups, cumulative incremental backups, and log backups all depend on a complete backup chain. This chain includes the initial full backup and all subsequent incremental, cumulative incremental, and log backups. In a backup chain, all dependent backups are retained and consume storage space until the last backup in the chain expires. You should configure your backup cycle and expiration time carefully to manage storage costs.

For example, if you perform a full backup on September 1 and an incremental backup every day from September 2 to September 7 with a retention period of seven days, the seven backups created from September 1 to September 7 are automatically deleted only after the entire chain expires on September 14.

Data size, usage, and billing

The Source Data Size represents the total amount of data you have backed up. For example, if you back up a 1 TB file twice, Cloud Backup stores two independent copies, and the Source Data Size is calculated as 2 TB. Cloud Backup uses deduplication and compression to reduce the storage your backups consume, which helps you save on costs. Billing is based on the actual Storage Vault Data Size. You can view the Source Data Size and Storage Vault Data Size for a database backup vault on the Vault Management page.