Todos los productos
Search

Este producto

    Data Management:Errores comunes y solución de problemas para Data Disaster Recovery (DBS)

    Centro de documentos

    Data Management:Errores comunes y solución de problemas para Data Disaster Recovery (DBS)

    Última actualización: Sep 03, 2026

    Este tema describe los errores, como mensajes de excepción y códigos de error, que puede encontrar al configurar un plan de copia de seguridad, ejecutar una comprobación previa o realizar una tarea de restauración, y explica cómo resolverlos.

    Nota

    Si encuentra un error no descrito en este tema, o si la solución proporcionada no resuelve el problema, póngase en contacto con el soporte técnico a través del grupo de DingTalk (ID: 35585947).

    Errores

    Errores de configuración del plan de copia de seguridad

    Source database connection test failure

    Errores de comprobación previa de copia de seguridad y restauración

    Errores de tareas de descarga avanzada

    Errores de ejecución de tareas

    Errores del plan de copia de seguridad

    Error de conexión a la base de datos de origen

    Escenario: Una prueba de conexión falla mientras configura un plan de copia de seguridad.

    Causas posibles:

    • La cuenta o la contraseña de la base de datos es incorrecta.

    • El acceso a la base de datos está restringido por dirección IP de origen.

    • Restricciones de firewall en el servidor o la red de la base de datos de origen.

    • Problemas de conectividad de red.

    Solución:

    1. Haga clic en Check en la consola para ver los detalles del fallo de conexión. El cuadro de diálogo Check muestra los resultados de diagnóstico para MySQL JDBC Connect y Telnet. Utilice los resultados de diagnóstico y los mensajes de error para determinar la causa del fallo.

    2. Compruebe si pasaron las siguientes verificaciones de diagnóstico.

      • Primero, compruebe si la cuenta o la contraseña de la base de datos es incorrecta o si la base de datos tiene acceso restringido desde la IP de origen.

        1. Verifique la cuenta y la contraseña de la base de datos.

          Desde un cliente que pueda conectarse a la base de datos de origen, utilice la cuenta y la contraseña especificadas en el plan de copia de seguridad para verificar las credenciales. Si las credenciales son incorrectas, actualícelas en la configuración del plan de copia de seguridad y pruebe la conexión nuevamente.

        2. Si la cuenta y la contraseña son correctas, es posible que la base de datos esté restringiendo el acceso según la dirección IP de origen.

          • Si la base de datos de origen es MySQL, utilice un cliente de MySQL para conectarse a ella y ejecute la siguiente sentencia SQL. Luego, revise la salida para confirmar que la lista de direcciones IP autorizadas permite el acceso remoto.

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

            Reemplace [$Username] con la cuenta de base de datos especificada en su plan de copia de seguridad.

          • Si la base de datos de origen es SQL Server:

            • Si la puerta de enlace de copia de seguridad está instalada en el servidor de la base de datos de origen, establezca Address en localhost.

            • Compruebe si hay un firewall configurado en el host de SQL Server, o si un endpoint o desencadenador en la base de datos de origen restringe el acceso por dirección IP.

          • Si la base de datos de origen es Oracle, revise su archivo de configuración sqlnet.ora para confirmar si el parámetro TCP.VALIDNODE_CHECKING está establecido en YES. Si el valor es YES, la base de datos de origen restringe el acceso según las direcciones IP de origen.

      • A continuación, compruebe si el servidor y la red que alojan la base de datos tienen restricciones de firewall o si existen problemas de comunicación de red.

        1. Compruebe si hay un firewall habilitado en el servidor de la base de datos de origen y si existen políticas de firewall configuradas.

          • Si la base de datos de origen está instalada en un servidor Windows, abra el Panel de control, vaya a Windows Defender Firewall y compruebe si hay alguna política de firewall configurada.

          • Si la base de datos de origen está instalada en un servidor Linux, ejecute el comando iptables -L para comprobar si hay políticas de firewall configuradas.

          • Si la base de datos está instalada en una instancia de ECS de Alibaba Cloud, consulte la documentación de Add a security group rule para comprobar si el security group permite el acceso desde el bloque CIDR requerido. Puede encontrar la información del bloque CIDR en la consola.

        2. Compruebe si el firewall de red restringe el acceso desde el bloque CIDR requerido. Las siguientes instrucciones utilizan Cloud Firewall como ejemplo.

          1. Inicie sesión en la consola de Cloud Firewall. En el panel de navegación izquierdo, haga clic en Access Control.

          2. Busque cualquier política de Cloud Firewall que bloquee el acceso desde el bloque CIDR requerido. Puede encontrar la información del bloque CIDR en la consola.

          Nota

          Si ha descartado restricciones de firewall pero la verificación de Telnet sigue fallando, es probable que la causa sea un problema de conectividad de red. Para obtener asistencia, póngase en contacto con el soporte técnico a través de DingTalk group.

    Errores de comprobación previa de copia de seguridad y restauración

    Error de conexión a la base de datos de origen

    Este error ocurre durante la comprobación previa de un plan de copia de seguridad o una tarea de restauración.

    Causas posibles:

    • La cuenta o la contraseña de la base de datos es incorrecta.

    • La base de datos restringe el acceso desde la dirección IP de origen.

    • Hay un firewall configurado en el servidor o la red de la base de datos.

    • Existen problemas de comunicación de red.

    Solución: Consulte la solución para source database connection test failed, descrita en la sección de errores comunes de configuración del plan de copia de seguridad.

    Error en la verificación de permisos de la base de datos

    Escenario: Este error ocurre durante la comprobación previa de un plan de copia de seguridad o una tarea de restauración.

    Causas posibles:

    • La cuenta de base de datos del plan de copia de seguridad carece de los permisos necesarios para acceder a los datos de la base de datos.

    • La cuenta de base de datos de la tarea de restauración carece de permisos para escribir datos o modificar el esquema de la base de datos.

    Solución: Compruebe los permisos de la cuenta de base de datos. Si son insuficientes, otorgue los permisos necesarios a la cuenta o utilice una cuenta diferente que ya los tenga.

    Nota

    • Para planes de copia de seguridad: Para cambiar la cuenta de base de datos, consulte Modify the backup source.

    • Para tareas de restauración: Configure una nueva tarea de restauración y luego elimine la original que falló en la comprobación previa.

    Error en la comprobación de OSS

    Escenario: Falla una comprobación previa para un plan de copia de seguridad o una tarea de restauración.

    Causas posibles:

    • El almacenamiento de copia de seguridad es un bucket de OSS propiedad del usuario, pero no se ha concedido autorización de servicio a Data Disaster Recovery para acceder a él.

    • Ha ocurrido un problema interno del servicio.

    Solución:

    • En la página Configure Task del plan de copia de seguridad objetivo, revise el campo Backup Storage OSS Bucket en la sección Basic Information para ver si se utiliza un bucket de OSS propiedad del usuario. De ser así, inicie sesión en la consola de OSS para verificar que el bucket mostrado en la consola de Data Disaster Recovery existe y que se ha concedido service authorization.

    • Si ocurre un problema interno del servicio, póngase en contacto con el soporte técnico en DingTalk group.

    Fallo en la comprobación previa de binlog de la base de datos de origen

    Escenario: La comprobación previa de binlog de la base de datos de origen falla.

    Solución: Esta comprobación previa verifica que la función de registro binario esté habilitada en la base de datos de origen. Un fallo indica que la función está deshabilitada. Para resolver este problema, siga estos pasos.

    1. Inicie sesión en el servidor que aloja su base de datos de origen MySQL autogestionada.

    2. Modifique los siguientes ajustes en el archivo de configuración de MySQL my.cnf.

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

      La ruta predeterminada del archivo de configuración my.cnf es /etc/my.cnf. La ruta real puede variar dependiendo de su instalación.

    3. Reinicie el servicio de MySQL ejecutando los siguientes comandos.

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

      Reemplace [$Mysql_Dir] con el directorio de instalación de MySQL.

    4. Inicie sesión en su base de datos de origen MySQL autogestionada y ejecute la siguiente sentencia SQL para confirmar que la función de registro binario está habilitada.

      SHOW variables LIKE '%log_bin%';

      La siguiente salida indica que la función está habilitada:

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

    5. Ejecute la comprobación previa de DBS nuevamente.

    Fallo en la comprobación del formato de binlog de origen

    Escenario: La comprobación previa del formato de registro binario de la base de datos de origen falla.

    Solución: Esta comprobación verifica que el formato de registro binario de la base de datos de origen esté establecido en ROW. Si la comprobación previa falla, el formato no está establecido en ROW. Para resolver este problema, siga estos pasos.

    1. Inicie sesión en el servidor donde se ejecuta su base de datos de origen MySQL autogestionada.

    2. Modifique el archivo de configuración de MySQL my.cnf para establecer el parámetro binlog_format en ROW.

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

      La ruta predeterminada del archivo de configuración my.cnf es /etc/my.cnf. La ruta real puede variar según su instalación.

    3. Reinicie MySQL ejecutando los siguientes comandos.

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

      Reemplace [$Mysql_Dir] con el directorio de instalación de MySQL.

    4. Inicie sesión en su base de datos de origen MySQL autogestionada y ejecute la siguiente sentencia SQL para verificar que el formato de registro binario esté establecido en ROW.

      SHOW variables LIKE "%binlog_format%";

      La siguiente salida indica que el formato de registro binario está establecido en ROW:

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

    5. Ejecute la comprobación previa de DBS nuevamente.

    Fallo en la comprobación de binlog_row_image

    Escenario: La comprobación previa del parámetro binlog_row_image de la base de datos de origen falla.

    Solución: Esta comprobación aplica a MySQL 5.6 o posterior. Verifica si el parámetro binlog_row_image está establecido en full. Un fallo indica que el registro binario no registra imágenes completas de fila. Para resolver este problema, siga estos pasos.

    1. Inicie sesión en el servidor que aloja su base de datos de origen MySQL autogestionada.

    2. Modifique el archivo de configuración my.cnf de MySQL para establecer el parámetro binlog_row_image en full.

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

      La ruta predeterminada del archivo de configuración my.cnf es /etc/my.cnf. La ruta real puede variar.

    3. Ejecute los siguientes comandos para reiniciar MySQL.

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

      Reemplace [$Mysql_Dir] con su directorio de instalación de MySQL.

    4. Inicie sesión nuevamente en su base de datos de origen MySQL autogestionada y ejecute la siguiente sentencia SQL para confirmar que el parámetro binlog_row_image está establecido en full.

      show variables like "%binlog_row_image%";

    5. Ejecute la comprobación previa nuevamente.

    Fallo en la comprobación de server_id de la base de datos de origen

    Escenario: La comprobación de server_id falla para la base de datos de origen.

    Solución: Al iniciar una tarea de migración de datos incrementales de MySQL, se realiza una comprobación de server_id en la base de datos de origen durante la fase de comprobación previa. La siguiente sección describe cómo resolver un fallo en la comprobación de server_id para una base de datos de origen MySQL autogestionada.

    1. Inicie sesión en su servidor de base de datos MySQL autogestionada y ejecute la siguiente sentencia SQL para comprobar el valor del parámetro server_id.

      SHOW variables LIKE '%server_id%';

    2. El parámetro server_id debe establecerse en un número entero mayor que 1. Ejecute la siguiente sentencia SQL para modificar el valor de server_id.

      SET global server_id=[$ID];
      Nota

      • Reemplace [$ID] con un número entero mayor que 1. Asegúrese de que el ID sea único y no lo utilice otro servidor de base de datos.

      • Si su base de datos autogestionada está en modo primario/secundario, asegúrese de que este cambio no afecte la replicación primaria-secundaria.

      • Después de ejecutar esta sentencia, también debe modificar el valor de server_id en el archivo de configuración. De lo contrario, un reinicio revertirá este cambio.

    3. Vuelva a ejecutar la comprobación previa.

    Fallo en la comprobación del registro binario de la base de datos de origen

    Escenario: Al iniciar un plan de copia de seguridad para una base de datos MySQL autogestionada, la comprobación del registro binario falla.

    Solución:

    1. Ejecute el siguiente comando en la CLI de MySQL para comprobar si el registro binario está habilitado:

      SHOW variables LIKE 'log_%';

    2. Si el valor 'log_bin' en la salida es 'OFF', el registro binario está deshabilitado. Para habilitarlo en un sistema Linux, edite el archivo de configuración my.cnf utilizando el comando 'vim':

      mysql> show variables like 'log_%';
+-----------------------------------------+---------------------+
| Variable_name                           | Value               |
+-----------------------------------------+---------------------+
| log_bin                                 | OFF                 |
| log_bin_basename                        |                     |
| log_bin_index                           |                     |
| log_bin_trust_function_creators         | OFF                 |
| log_bin_use_v1_row_events               | OFF                 |
| log_builtin_as_identified_by_password   | OFF                 |
| log_error                               | /var/log/mysqld.log |
| log_error_verbosity                     | 3                   |
| log_output                              | FILE                |
| log_queries_not_using_indexes           | OFF                 |
| log_slave_updates                       | OFF                 |
| log_slow_admin_statements               | OFF                 |
| log_slow_slave_statements               | OFF                 |
| log_statements_unsafe_for_binlog        | ON                  |
| log_syslog                              | OFF                 |
| log_syslog_facility                     | daemon              |
| log_syslog_include_pid                  | ON                  |
| log_syslog_tag                          |                     |
| log_throttle_queries_not_using_indexes  | 0                   |
| log_timestamps                          | UTC                 |
| log_warnings                            | 2                   |
+-----------------------------------------+---------------------+
21 rows in set (0.00 sec)
      # Open the /etc/my.cnf file.
vim /etc/my.cnf

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

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

    3. Reinicie la base de datos MySQL autogestionada.

      systemctl restart mysqld
      Nota

      Los cambios en el archivo de configuración solo surten efecto después de reiniciar la instancia de base de datos. Se recomienda reiniciar su instancia de base de datos autogestionada fuera del horario pico.

      Después de que MySQL se reinicie, ejecute el comando del Paso 1 para verificar que el registro binario esté habilitado. Luego, reinicie el plan de copia de seguridad.

    Fallo en la comprobación del motor de almacenamiento

    Solución: Esta comprobación determina si la base de datos de origen utiliza un motor de almacenamiento no compatible con la migración incremental de datos. La migración incremental de datos de MySQL a MySQL no admite los motores de almacenamiento FEDERATED y MRG_MyISAM. Si la comprobación falla, significa que las tablas a migrar utilizan uno de estos motores de almacenamiento.

    En la página Configure Task del plan de copia de seguridad, haga clic en Edit Backup Objects. Elimine las bases de datos y tablas que utilizan un motor de almacenamiento no compatible y luego vuelva a ejecutar la copia de seguridad.

    Nota

    Una vez que los cambios en los objetos de copia de seguridad surtan efecto, el sistema iniciará inmediatamente una nueva copia de seguridad. Este proceso puede afectar a la base de datos de origen y a sus cargas de trabajo. Se recomienda modificar la configuración fuera del horario pico.

    Comprobación del formato de contraseña de MySQL

    Escenario: La comprobación previa para un plan de copia de seguridad o una tarea de restauración falla.

    Solución: Se detectó un formato de contraseña antiguo. Consulte old_passwords.

    Conflicto de nombre de objeto

    Escenario: El objeto seleccionado para restaurar tiene el mismo nombre que un objeto de base de datos existente en el destino.

    Solución: Configure una nueva tarea de restauración y seleccione Rename Object with the Same Name o haga clic en Edit para cambiar el nombre del objeto de destino. Luego puede eliminar la tarea de restauración fallida.

    Errores comunes en tareas de descarga avanzada

    Síntoma: En la página de detalles de Backup and Restoration para una instancia en la consola de ApsaraDB RDS, no puede hacer clic en el botón Download Instance Backup File para crear una tarea de descarga avanzada.

    DBS-DownloadTask.Region

    Causa: La función no está disponible en la región actual.

    Solución: Póngase en contacto con nuestro equipo de soporte en el grupo de DingTalk (ID: 35585947) para solicitar esta función.

    DBS-DownloadTask.InstanceInfo

    Causa: El servicio de descarga no pudo recuperar información sobre la instancia de ApsaraDB RDS.

    Solución: Compruebe si la instancia de ApsaraDB RDS está en un estado anómalo o si ha sido eliminada.

    DBS-DownloadTask.DbType

    Causa: El motor de base de datos de la instancia de ApsaraDB RDS no admite la función de descarga avanzada.

    Solución: La función de descarga avanzada solo está disponible para ApsaraDB RDS for MySQL y ApsaraDB RDS for PostgreSQL.

    DBS-DownloadTask.CustinId

    Causa: Esta función aún no está habilitada para su instancia de ApsaraDB RDS.

    Solución: Es posible que esta función se encuentre en una fase de lanzamiento gradual y aún no esté disponible para su instancia. Puede ponerse en contacto con el soporte técnico en el grupo de atención al cliente (ID de grupo de DingTalk: 35585947) y expresar sus requisitos.

    DBS-DownloadTask.CustinName

    Causa: Esta función aún no está habilitada para su instancia de ApsaraDB RDS porque se encuentra en un despliegue gradual.

    Solución: Para solicitar acceso, póngase en contacto con el soporte técnico en el grupo de DingTalk (ID: 35585947).

    DBS-DownloadTask.user

    Causa: Esta función no está habilitada para su instancia de ApsaraDB RDS.

    Solución: Es posible que esta función se encuentre en un periodo de lanzamiento gradual y aún no esté disponible para su instancia. Puede ponerse en contacto con el soporte técnico en el grupo de DingTalk (ID de grupo: 35585947) para enviar su solicitud.

    DBS-DownloadTask.Instance.Version

    Causa posible: La versión menor del motor de la instancia de ApsaraDB RDS está desactualizada.

    Solución: La versión menor del motor de su instancia debe ser 20201031 o posterior. Para actualizar la versión menor del motor, consulte Upgrade the minor engine version. Si encuentra problemas durante la actualización, póngase en contacto con el soporte técnico de ApsaraDB RDS.

    Nota

    Para más información, consulte Prerequisites for downloading backups.

    DBS-DownloadTask.Instance.Storage.Type

    Causa: El tipo de almacenamiento de su instancia de ApsaraDB RDS no admite la función de descarga avanzada.

    Solución: Solo las instancias que utilizan discos en la nube admiten la función de descarga avanzada. Vaya a la página Basic Information de su instancia de ApsaraDB RDS para verificar que el Storage Type sea cloud disk.

    DBS-DownloadTask.Instance.Param

    Causa: La función de descarga avanzada no está disponible debido a una configuración incorrecta de parámetros en la instancia de ApsaraDB RDS.

    Solución: Asegúrese de que la versión menor del motor de su instancia de ApsaraDB RDS no esté desactualizada y de que los datos de la copia de seguridad no estén cifrados. Para obtener más detalles, consulte Prerequisites for advanced download.

    DBS-DownloadTask

    Posible causa: La instancia de ApsaraDB RDS no es compatible con la función de descarga avanzada.

    Solución: Asegúrese de que su instancia de ApsaraDB RDS cumpla con los requisitos previos para la función de descarga avanzada. Para obtener más información, consulte los siguientes temas:

    Nota

    Antes de utilizar la función de descarga avanzada, lea la documentación para comprender sus detalles, incluidas sus limitaciones.

    Errores comunes de tareas

    DBS-000000

    Escenario: Una copia de seguridad física completa falla.

    Causa: El servicio no puede conectarse a la puerta de enlace de copia de seguridad especificada en el programa de copia de seguridad, y la tarea falla tras alcanzar el límite máximo de 100 reintentos. Una causa común es que la puerta de enlace de copia de seguridad esté desconectada.

    Ejemplo:

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

    Solución:

    1. En la página Configure Task del programa de copia de seguridad objetivo, compruebe si el estado de la puerta de enlace de copia de seguridad es Offline.

    2. En el panel de navegación izquierdo, haga clic en Backup Gateways. En la página Backup Gateways, busque la puerta de enlace objetivo por su Backup Gateway Hostname. Compruebe que la dirección IP, el nombre de host y la hora del último latido sean correctos. El estado actual se muestra en la columna Status.

    3. Compruebe el estado de ejecución y la configuración de red del servidor donde está instalada la puerta de enlace de copia de seguridad.

      Si el servidor se ejecuta correctamente y la conexión de red es estable, reinicie la puerta de enlace de copia de seguridad. Algunas versiones anteriores de la puerta de enlace pueden tener vulnerabilidades. Se recomienda actualizar la puerta de enlace de copia de seguridad. Para obtener más información, consulte upgrade backup gateway.

      Nota

      Si la puerta de enlace de copia de seguridad sigue sin iniciarse después de completar estos pasos, póngase en contacto con el soporte técnico en DingTalk group.

    DBS-000001

    Escenario: Una tarea de copia de seguridad lógica completa falla.

    Causa: La tarea falló tras superar el límite máximo de reintentos.

    Ejemplo:

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

    Solución: Reinicie la tarea y supervise su estado. Si el error persiste, póngase en contacto con el soporte técnico en DingTalk group.

    DBS-000002

    Escenario: Fallo durante una copia de seguridad de esquema lógico o una copia de seguridad completa.

    Causa: No hay recursos de servicio disponibles.

    Ejemplo:

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

    Solución: Póngase en contacto con el soporte técnico en DingTalk group para diagnosticar el fallo.

    DBS-000003

    Escenario: Una tarea de vínculo falla.

    Causa: No se encontró ninguna instancia para la tarea.

    Ejemplo:

    DBS-000003  No instance was found for this task

    Solución: Póngase en contacto con el soporte técnico en DingTalk group para obtener asistencia.

    DBS-000004

    Escenario: Una tarea de copia de seguridad física o de restauración no se inicia.

    Causa: Ocurrió una excepción al programar la tarea de copia de seguridad física o de restauración.

    Ejemplo:

    DBS-000004 + [Detailed error message]

    Solución: Reintente la tarea. Si el error persiste, póngase en contacto con el soporte técnico en DingTalk group.

    DBS-000005

    Escenario: Una tarea de copia de seguridad lógica o de restauración no se inicia.

    Causa: Ocurrió un error de programación.

    Ejemplo:

    DBS-000005 + [Detailed error message]

    Solución: Reintente la tarea. Si el error persiste, póngase en contacto con el soporte técnico en DingTalk group.

    DBS-000006

    Escenario: Una tarea de copia de seguridad física o de restauración agota el tiempo de espera antes de iniciarse.

    Causa: La tarea no se inicia debido a un error de programación o a un problema de recursos.

    Ejemplo:

    DBS-000006 + [Detailed error message]

    Solución: Reintente la tarea fallida. Si la tarea vuelve a fallar, póngase en contacto con el soporte técnico en DingTalk group.

    DBS-000007

    Escenario: Se produce un tiempo de espera agotado al iniciar una tarea de copia de seguridad lógica o de restauración.

    Causa: Ocurre un error de programación o un problema de recursos durante el inicio de la tarea.

    Ejemplo:

    DBS-000007 + [Detailed error message]

    Solución: Reinicie la tarea fallida. Si el error persiste, póngase en contacto con el soporte técnico a través de customer group.

    DBS-002003

    Escenario: Una copia de seguridad física nativa completa de una base de datos SQL Server falla.

    Causa: No se puede acceder a la base de datos. Esto puede ocurrir si carece de los permisos de base de datos obligatorios, si la base de datos no existe o si su estado impide el acceso.

    Ejemplo:

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

    Solución:

    1. Compruebe que la base de datos esté en línea. Si está desconectada, conéctela.

    2. Si la base de datos se está restaurando, espere a que finalice la restauración antes de reiniciar la tarea.

    3. Compruebe si la conexión está cifrada.

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

    4. Revise el registro para ver si el cifrado de Transport Layer Security (TLS) está habilitado.

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

      Si esta entrada del registro existe y su valor es 1, el cifrado TLS está habilitado. Para deshabilitar el cifrado TLS, siga estos pasos:

      1. Cambie el valor de la entrada del registro de 1 a 0.

      2. En el cuadro de búsqueda de Inicio de Windows, busque Internet Options. Haga clic en la pestaña Advanced, desplácese hacia abajo, desmarque las casillas de Use TLS 1.0, Use TLS 1.1, Use TLS 1.2 y Use TLS 1.3, y luego haga clic en OK. Los cambios surten efecto después de reiniciar la computadora.

      3. Reinicie la computadora y reintente la tarea de copia de seguridad.

    DBS-002009

    Escenario: Una copia de seguridad de esquema falla.

    Posibles causas:

    • El nombre de la cuenta de la base de datos o la contraseña son incorrectos.

    • Los permisos de la cuenta de la base de datos han cambiado o la base de datos restringe el acceso desde la IP de origen.

    • Las reglas de firewall de la base de datos o de su servidor han cambiado.

    • Problemas de conectividad de red; por ejemplo, las asignaciones de red han cambiado.

    Ejemplo:

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

    Solución: Para solucionar problemas, consulte la sección "Fallo al probar la conexión a la base de datos de origen" de este tema. Primero, compruebe si la conexión falló debido a cambios en el nombre de la cuenta de la base de datos, la contraseña, los permisos de la cuenta, la IP de origen o las reglas de firewall. Si estas configuraciones no han cambiado, compruebe y regenere las asignaciones de red:

    1. Vaya a la página Configure Task del programa de copia de seguridad objetivo y haga clic en Edit Backup Objects en la esquina superior derecha de la sección Basic Information.

    2. Introduzca nuevamente el nombre de la cuenta de la base de datos y la contraseña, y luego haga clic en Test Connection.

      Durante la prueba de conexión, el sistema comprueba y regenera las asignaciones de red en segundo plano según sea necesario. La página de configuración incluye campos para el nombre de la cuenta de la base de datos y la contraseña. Para el método de conexión, puede seleccionar conexión no cifrada o conexión segura SSL.

      Nota

      Si la prueba de conexión sigue fallando incluso con la configuración correcta de la base de datos de origen, póngase en contacto con el soporte técnico en DingTalk group.

    3. Después de que la prueba de conexión tenga éxito, haga clic en Next.

    4. Seleccione nuevamente las bases de datos y tablas para la copia de seguridad y haga clic en Save para actualizar el programa de copia de seguridad.

      Después de hacer clic en Save, la nueva configuración entra en vigor e inicia inmediatamente una copia de seguridad. Esta acción puede afectar a la base de datos de origen y a sus cargas de trabajo. Se recomienda cambiar la configuración fuera de las horas pico.

    DBS-102001

    Escenario: Puede ocurrir en diversas situaciones.

    Causa: La copia de seguridad se completa, pero falla el reporte de los objetos de copia de seguridad a la metadatabase. Este es un problema común en las copias de seguridad de esquemas. Reintentar la tarea puede resolver el problema.

    Ejemplo:

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

    Solución: Reintente la tarea. Si el problema persiste, póngase en contacto con el soporte técnico en DingTalk group.

    DBS-105001

    Escenario: Este error puede ocurrir durante diversas operaciones.

    Causa: El reporte del latido a la metadatabase agota el tiempo de espera.

    Ejemplo:

    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

    Solución: Reintente la tarea. Si el problema persiste, póngase en contacto con el soporte técnico en DingTalk group.

    DBS-106001

    Escenario: Este error puede ocurrir en varias etapas.

    Posible causa: Un error interno de OSS.

    Ejemplo:

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

    Solución: Para obtener ayuda, póngase en contacto con nosotros en DingTalk group.

    DBS-202002

    Escenario: Una tarea falla al realizar una copia de seguridad de datos en un bucket de OSS propiedad del cliente.

    Causa: El servicio OSS está suspendido debido a un pago pendiente.

    Ejemplo:

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

    Solución:

    • En la página Backup Task Configuration del plan de copia de seguridad objetivo, compruebe si su plan de copia de seguridad actual utiliza un bucket de OSS propiedad del cliente. Puede confirmarlo revisando el campo Backup Storage OSS Bucket en la sección Basic Information. Si utiliza un bucket de OSS propiedad del cliente, revise su factura de OSS para detectar pagos pendientes. Después de pagar la factura, reintente la tarea de copia de seguridad.

    • Si no utiliza un bucket de OSS propiedad del cliente, póngase en contacto con el soporte técnico en DingTalk group.

    DBS-203101

    Escenario: Una copia de seguridad física nativa completa de una base de datos SQL Server falla.

    Posibles causas:

    • La base de datos no se está ejecutando.

    • El cifrado SSL está habilitado para la base de datos.

    Ejemplo:

    DBS-203101 Connect db failure

    Solución:

    1. Utilice SQL Server Management Studio (SSMS) para iniciar sesión mediante el número de puerto y compruebe que la base de datos exista y se esté ejecutando.

      De forma predeterminada, puede iniciar sesión sin un número de puerto. Para especificar un número de puerto, agréguelo después del nombre de host con una coma; por ejemplo, localhost,1433.

      Nota

      Solo se admiten conexiones TCP.

    2. Asegúrese de que el cifrado SSL no esté habilitado para la base de datos. Abra SQL Server Configuration Manager. En el panel izquierdo, vaya a SQL Server network configuration > protocols for MSSQLSERVER. Haga clic derecho y seleccione properties. En la pestaña flags, compruebe si force encryption está establecido en yes. Si está establecido en yes, cámbielo a no.

    DBS-203102

    Escenario: Una copia de seguridad física nativa de una base de datos SQL Server falla.

    Posibles causas:

    • La base de datos fue eliminada.

    • Se cambió el nombre de la base de datos de origen.

    • La base de datos está en un estado anómalo y no se puede respaldar.

    Ejemplo:

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

    Solución:

    1. Compruebe si la base de datos fue eliminada. De ser así, reconfigure los objetos de copia de seguridad.

      En la página Configure Task del programa de copia de seguridad objetivo, haga clic en Edit Backup Objects en la sección Basic Information.

      Nota

      Guardar la nueva configuración inicia inmediatamente una copia de seguridad. Este proceso puede afectar a su base de datos de origen y a las operaciones comerciales.

    2. Compruebe si se cambió el nombre de la base de datos de origen. De ser así, siga las instrucciones del paso anterior para reconfigurar los objetos de copia de seguridad.

    3. Asegúrese de que la base de datos esté en línea.

    4. Si la base de datos está en estado de recuperación, espere a que finalice la recuperación y luego reinicie la tarea.

    5. Si la función de cierre automático de la base de datos está habilitada, establézcala en False. En SQL Server Management Studio (SSMS), haga clic derecho en la base de datos objetivo y seleccione Properties. En la página Options, busque la configuración en la sección Auto.

    DBS-203103

    Escenario: Una copia de seguridad física nativa completa de una base de datos SQL Server falla.

    Causa: La base de datos está apagada.

    Ejemplo:

    DBS-203103 The database server already shutdown

    Solución: Inicie el servicio de base de datos.

    DBS-203104

    Escenario: Una copia de seguridad física nativa completa de una base de datos SQL Server falla.

    Causa: Un problema con los componentes VDI.

    Ejemplo:

    DBS-203104 Wait VDI timeout 30s

    Solución: Revise los eventos de Windows para solucionar problemas con los componentes VDI. Después de resolver cualquier problema, reintente la tarea. Si no encuentra problemas, espere un momento y luego reintente la copia de seguridad. Si el error persiste, póngase en contacto con DingTalk group para obtener asistencia.

    DBS-203201

    Escenario: Este error ocurre durante una copia de seguridad física nativa completa de una base de datos SQL Server.

    Posibles causas:

    • Varias tareas de copia de seguridad se ejecutan simultáneamente para la misma base de datos.

    • El error es causado por el truncamiento del registro. Las posibles causas incluyen:

      • Copia de seguridad simultánea por otra herramienta.

      • Una operación reciente de reducción de base de datos.

      • Un cambio en el modelo de recuperación de la base de datos.

      • Otras acciones que pueden causar el truncamiento del registro.

    Ejemplo:

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

    Solución:

    • Varias tareas de copia de seguridad se ejecutan simultáneamente para la misma base de datos.

      • Si hay varias tareas de copia de seguridad configuradas para ejecutarse en la misma base de datos simultáneamente, suspenda las otras tareas para asegurar que solo se ejecute una tarea a la vez.

      • Si utiliza un script para copias de seguridad programadas, asegúrese de que ninguna otra tarea de copia de seguridad se ejecute simultáneamente en la misma base de datos.

      • Si una tarea de copia de seguridad incremental que abarca varias bases de datos falla para algunas de ellas, deshabilite y vuelva a habilitar la tarea.

    • El error es causado por el truncamiento del registro.

      • La copia de seguridad está incompleta debido al truncamiento del registro. Inicie una nueva copia de seguridad completa desde la consola.

    DBS-203202

    Escenario: Una copia de seguridad incremental de una base de datos SQL Server falla.

    Posibles causas:

    • Una copia de seguridad incremental comienza antes de que se complete una copia de seguridad completa. Este problema puede ocurrir cuando configura una tarea de copia de seguridad por primera vez.

    • La opción CopyOnly está seleccionada en la configuración de la tarea de copia de seguridad. Las copias de seguridad completas creadas con esta opción no pueden servir como base para copias de seguridad incrementales.

    Ejemplo:

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

    Solución: Ejecute manualmente una copia de seguridad completa y luego reinicie la copia de seguridad incremental fallida.

    DBS-203203

    Escenario: Ocurre un error durante una copia de seguridad física nativa completa de una base de datos SQL Server.

    Causa: Las copias de seguridad del registro de transacciones no son compatibles porque el modelo de recuperación de la base de datos no está establecido en FULL.

    Ejemplo:

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

    Solución: Ejecute la siguiente sentencia SQL para cambiar el modelo de recuperación a FULL:

    ALTER DATABASE [your_database_name] SET RECOVERY FULL

    DBS-203205

    Escenario: Una copia de seguridad física nativa completa de una base de datos SQL Server falla.

    Causa: La base de datos está desconectada.

    Ejemplo:

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

    Solución:

    • Compruebe que la base de datos esté en línea. Si no lo está, conéctela.

    • Si la base de datos se está restaurando, espere a que finalice la restauración antes de reiniciar la tarea.

    DBS-203206

    Escenario: Una copia de seguridad física nativa completa de una base de datos SQL Server falla.

    Causa: La base de datos no se puede abrir porque no está disponible o está dañada.

    Ejemplo:

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

    Solución:

    • Asegúrese de que la base de datos esté en línea.

    • Si la base de datos se está restaurando, espere a que finalice la recuperación antes de reiniciar la tarea.

    DBS-203240

    Escenario: Copia de seguridad física nativa completa de SQL Server.

    Causa: La cuenta no tiene el permiso sysadmin.

    Ejemplo:

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

    Solución: Actualice el programa de copia de seguridad para usar una cuenta con los permisos obligatorios, o conceda el permiso sysadmin a la cuenta actual. Para obtener detalles sobre cómo cambiar la cuenta de la base de datos, consulte Modify the source database for backup.

    DBS-203301

    Escenario: Una restauración completa de una base de datos SQL Server falla.

    Posible causa: Para evitar la pérdida de datos, debe realizar una copia de seguridad del registro de cola antes de restaurar una base de datos. Este error ocurre si no se realizó la copia de seguridad del registro de cola.

    Nota

    Un registro de cola contiene los registros del registro de transacciones generados desde la última copia de seguridad del registro.

    Ejemplo:

    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

    Solución:

    1. Para realizar la copia de seguridad del registro de cola, ejecute el siguiente comando.

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

    2. Reinicie la tarea de restauración completa fallida.

    DBS-203302

    Escenario: Una restauración desde una copia de seguridad física nativa completa de una base de datos SQL Server falla.

    Causa: La copia de seguridad del registro de transacciones termina en LSN {0}, que es anterior al LSN {1} necesario para continuar la restauración. Esto indica un vacío en la cadena de copias de seguridad del registro.

    Ejemplo:

    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

    Solución: Póngase en contacto con el soporte técnico en DingTalk group para obtener asistencia.

    DBS-301005

    Escenario: Una copia de seguridad física completa de una instancia Oracle falla.

    Causa: La instancia Oracle no está en modo de archivado, lo cual es obligatorio para una copia de seguridad física completa.

    Ejemplo:

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

    Solución: Habilite el modo de archivado. Para obtener instrucciones detalladas, consulte Enable archive mode.

    DBS-301502

    Escenario: Ocurre un error durante una copia de seguridad física de MySQL.

    Causa: Se ejecuta una operación DDL que no se puede registrar en el registro redo durante la copia de seguridad.

    Ejemplo:

    DBS-301502, without redo logging

    Solución: Reintente la copia de seguridad cuando no haya operaciones DDL en ejecución.

    DBS-301503

    Escenario: Una copia de seguridad física de MySQL falla.

    Causa: La velocidad de generación del registro redo supera la velocidad de la copia de seguridad.

    Ejemplo:

    DBS-301503, log copying being too slow

    Solución: Aumente el tamaño del archivo redo y programe las copias de seguridad fuera de las horas pico.

    DBS-301504

    Escenario: Una copia de seguridad física de una instancia MySQL falla.

    Causa: Este error ocurre porque una o más tablas en la instancia MySQL tienen el cifrado habilitado, una función que Database Backup Service no admite.

    Ejemplo:

    DBS-301504, missing encryption

    Solución: Deshabilite el cifrado y reintente la copia de seguridad. Si prefiere no deshabilitar el cifrado, póngase en contacto con el servicio de atención al cliente para solicitar un reembolso del programa de copia de seguridad.

    DBS-301505

    Escenario: Una copia de seguridad física de una base de datos MySQL falla.

    Causa: El sistema finaliza el proceso de copia de seguridad.

    Ejemplo:

    DBS-301505, signal: terminated

    Solución: Reinicie la tarea.

    DBS-302035

    Escenario: Una copia de seguridad física completa de una base de datos Oracle falla.

    Causa: No se puede obtener el rol de la instancia Oracle.

    Ejemplo:

    DBS-302035 USER_CAN_NOT_LOAD_INSTANCE_ROLE[302035]

    Solución:

    1. Inicie sesión en el servidor que aloja la instancia de la base de datos.

    2. Ejecute el siguiente comando para iniciar sesión en la base de datos como administrador del sistema:

      sqlplus / as sysdba

    3. Ejecute la siguiente sentencia SQL para comprobar si se devuelve un resultado:

      select database_role from v$database;

      Si no se devuelve ningún resultado, investigue la causa. Si se devuelve un resultado, póngase en contacto con el soporte técnico en DingTalk group.

    DBS-400001

    Escenario: Una copia de seguridad física nativa completa o una tarea de conversión de datos completa falla.

    Causa: La tarea se queda sin memoria porque las especificaciones del programa de copia de seguridad son insuficientes.

    Ejemplo:

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

    Solución: Actualice las especificaciones del programa de copia de seguridad. Para aumentar temporalmente el límite de memoria para una tarea urgente, como una tarea de restauración, póngase en contacto con el soporte técnico en DingTalk group. Para obtener instrucciones, consulte Upgrade a backup schedule.

    DBS-999999 o sin código de error

    Escenario: Ocurre un error durante cualquier tarea.

    Causa: La excepción no está definida o el sistema no pudo devolver el código de error correspondiente.

    Ejemplo:

    DBS-999999 + [error message]

    Solución: Copie el mensaje de error y búsquelo en este tema para ver si un código de error diferente describe el problema. Si no encuentra una solución, póngase en contacto con el soporte técnico en DingTalk group.