Cloud Backup:Perguntas frequentes sobre backup de banco de dados

MySQL

1. Esse problema pode ser causado por uma Database Account ou Password incorreta, ou por uma conta de backup com permissões insuficientes. Verifique as credenciais, conceda as permissões necessárias e tente registrar novamente.

   Para mais informações, consulte Criar uma conta de backup MySQL e configurar permissões.

2. Execute systemctl restart dbackup3-agent para reiniciar o cliente de backup.

3. Se a instância de banco de dados permanecer inativa após reiniciar o cliente de backup, colete os arquivos de log para análise.

   O caminho do log do cliente é /var/log/dbackup3/agent.log.

Oracle

1. Esse problema pode ser causado por uma Database Account ou Password incorreta, ou por uma conta de backup com permissões insuficientes. Verifique as credenciais, conceda as permissões necessárias e tente registrar novamente.

   Para mais informações, consulte Criar uma conta de backup Oracle e configurar permissões.

2. Reinicie o cliente de backup.

   • Linux: Execute systemctl restart dbackup3-agent para reiniciar o cliente de backup.

   • Windows:

     1. Pressione Win + R para abrir a caixa de diálogo Run.

     2. Insira services.msc e pressione Enter para abrir o console de gerenciamento de Serviços.

     3. Na lista de serviços, localize o serviço dbackup3-agent.

     4. Verifique se o status do serviço é Running. Caso contrário, clique com o botão direito no serviço dbackup3-agent e selecione Restart.

3. Se a instância de banco de dados permanecer inativa após reiniciar o cliente de backup, colete os arquivos de log para análise.

   • O caminho do log do cliente no Linux é /var/log/dbackup3/agent.log.

   • O caminho do log do cliente no Windows é Local Disk (C) > ProgramData > scutech > dbackup3 > agent > log > dbackup3-agent.log.

SQL Server

1. Esse problema pode ser causado por uma Database Account ou Password incorreta, ou por uma conta de backup com permissões insuficientes. Verifique as credenciais, conceda as permissões necessárias e tente registrar novamente.

   Para mais informações, consulte Criar uma conta de backup SQL Server e configurar permissões.

2. Reinicie o serviço dbackup3-agent.

   1. Pressione Win + R para abrir a caixa de diálogo Run.

   2. Insira services.msc e pressione Enter para abrir o console de gerenciamento de Serviços.

   3. Na lista de serviços, localize o serviço dbackup3-agent.

   4. Verifique se o status do serviço é Running. Caso contrário, clique com o botão direito no serviço dbackup3-agent e selecione Restart.

3. Se a instância de banco de dados permanecer inativa após reiniciar o serviço, colete os arquivos de log para análise.

   O caminho do log do cliente é Local Disk (C) > ProgramData > scutech > dbackup3 > agent > log > dbackup3-agent.log.

MySQL

1. Verifique o status do banco de dados MySQL.

   Acesse a instância ECS e execute o comando systemctl status mysqld. Se o status for inactive, o serviço de banco de dados MySQL não está em execução.

2. Reinicie o serviço MySQL.

   Execute o comando systemctl start mysqld para reiniciar o serviço MySQL. O database status no console mudará para Online.

Oracle

1. Verifique o status do listener Oracle.

   Acesse a instância ECS e execute os seguintes comandos:

   su - oracle
   lsnrctl status

   Se o serviço estiver em execução, o status será running. Caso contrário, uma mensagem TNS: no listener será exibida.

2. Verifique o status de execução do banco de dados Oracle.

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

   A view v$instance fornece informações sobre a instância do banco de dados. A coluna status mostra o status da instância. Um status OPEN significa que o banco de dados está aberto e pronto para conexões.

3. Reinicie o listener Oracle.

   Inicie o serviço de listener Oracle para escutar solicitações de conexão dos clientes.

   su - oracle
   lsnrctl start

4. Reinicie a instância do banco de dados Oracle.

   No SQL*Plus, acesse com privilégios de administrador de sistema e inicie a instância Oracle.

   sqlplus / as sysdba;
   STARTUP;

   Após a inicialização da instância do banco de dados, o database status no console mudará para Online.

SQL Server

1. Verifique o status do banco de dados SQL Server.

   1. Pressione Win + R para abrir a caixa de diálogo Run.

   2. Insira services.msc e pressione Enter para abrir o console de gerenciamento de Serviços.

   3. Na lista de serviços, localize o serviço SQL Server, como "SQL Server (MSSQLSERVER)".

   4. Verifique o status do serviço, que pode ser Running, Stopped ou Paused.

2. Reinicie o serviço SQL Server.

   Se o status do banco de dados SQL Server for Stopped ou Paused, clique com o botão direito no serviço SQL Server e selecione Start. Se a opção Start estiver acinzentada, reabra o console de gerenciamento de Serviços como administrador e tente novamente. Após o início do serviço, o database status no console mudará para Online.

MySQL

Em Job History, o status do trabalho é Error.

Siga estas etapas:

1. Acesse a instância ECS ou servidor local para verificar o status do serviço MySQL.

   Execute o comando systemctl status mysqld. Um status ativo indica que o serviço está funcionando normalmente. Se o status for inativo, o serviço não está funcionando corretamente. Reinicie o serviço e tente novamente.

2. Verifique o nome de usuário, a senha e as permissões do banco de dados. Uma senha expirada ou permissões de usuário alteradas recentemente também podem causar esse problema.

   Se a Database Account ou Password inserida durante o registro do banco de dados estiver incorreta, ou se a conta de backup tiver permissões insuficientes, verifique se as credenciais estão corretas e conceda as permissões necessárias à conta de backup. Recomendamos criar um usuário dedicado para backup.

   O conjunto mínimo de permissões necessárias inclui RELOAD, LOCK TABLES, REPLICATION e PROCESS.

3. Acesse o servidor e visualize o log de backup.

   Caminho do log do cliente Linux: /var/log/dbackup3/agent.log

   • Se o log contiver a palavra-chave uploadPart SecurityTokenExpired, a hora local no seu servidor está incorreta. Corrija-a.

   • Se o log contiver a palavra-chave ib_logfile0, uma operação de restauração foi iniciada enquanto outro trabalho de restauração já estava em andamento. Isso fez com que o arquivo ib_logfile0 fosse excluído, mas não recriado, causando falhas subsequentes no backup.

   • Se o log contiver a mensagem de erro Error: failed to execute query LOCK TABLES FOR BACKUP: Access denied; you need (at least one of) the RELOAD privilege(s) for this operation, a conta de backup tem permissões insuficientes. Para realizar um trabalho de backup, a conta precisa de pelo menos as seguintes permissões: RELOAD, LOCK TABLES, REPLICATION e PROCESS. No MySQL 8.0, a permissão BACKUP_ADMIN também é necessária.

   • Se o log contiver a mensagem no space left on device, um trabalho de restauração falhou na versão 29292 do cliente de backup MySQL devido a espaço de cache insuficiente para restaurar arquivos de backup incremental. Você pode criar um link simbólico para apontar o caminho de armazenamento para outro disco e resolver o problema.

   • Se o status do backup de log no console for "Error" e o log contiver a palavra-chave @LM_ERROR@agent|To backup binlog in slave node needs to set log_slave_updates to ON, o nó de backup é um nó escravo. Para realizar backups de log corretamente, ative o parâmetro log_slave_updates=1. Após alterar essa configuração, recomendamos realizar um backup completo antes de executar outro backup de log.

Oracle

1. Acesse o servidor e visualize o log de backup.

   Caminho do log do cliente Linux: /var/log/dbackup3/agent.log

   Caminho do log do cliente Windows: C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log

2. No log, verifique as entradas próximas ao horário em que a tarefa falhou. Se o log de backup contiver alguma das seguintes mensagens de erro, use a solução correspondente:

   • Se o log contiver a palavra-chave ORA-12560: TNS:protocol adapter error, verifique se a variável de ambiente ORACLE_SID está indefinida ou definida incorretamente, o que pode impedir a conexão com o Oracle. Tente acessar usando o comando sqlplus com permissões sysdba. Se você conseguir acessar após configurar corretamente a variável de ambiente ORACLE_SID, o problema estará resolvido.

   • Se o log contiver a palavra-chave sbtclose2 returned error-failed to close file, a hora local no seu servidor está incorreta ou o fuso horário do sistema não está definido corretamente. Altere a hora no servidor de banco de dados e reinicie o serviço dbackup3-agent. Para obter instruções, consulte Como verifico o status do processo do cliente, encontro o caminho do log e reinicio o cliente?.

   • Se o log contiver a palavra-chave Failed to probe oracle instances, existem duas causas possíveis:

     • A instância Oracle não estava em execução quando o cliente foi instalado.

       Reinicie o serviço dbackup3-agent. Para obter instruções, consulte Como verifico o status do processo do cliente, encontro o caminho do log e reinicio o cliente?.

     • A variável de ambiente ORACLE_HOME não está configurada corretamente.

       1. Para sistemas Linux: Execute /etc/init.d/dbackup3-agent config oracle e insira o caminho real de $ORACLE_HOME.

       2. Reinicie o serviço dbackup3-agent. Para obter instruções, consulte Como verifico o status do processo do cliente, encontro o caminho do log e reinicio o cliente?.

   • Se o log contiver a palavra-chave ORA-12154: TNS:could not resolve the connect identifier specified, sua senha contém caracteres especiais, causando falha na validação e no backup.

   • Se o log contiver a palavra-chave ORA-01017: invalid username/password; logon denied, reative a instância com o nome de usuário e a senha corretos e execute o backup novamente.

   • Se o log contiver a palavra-chave The difference between the request time and the current time is too large, a hora no servidor onde o cliente Cloud Backup está instalado não corresponde à hora no servidor Cloud Backup.

     Solução:

     1. Verifique e sincronize a hora: Recomendamos usar o Network Time Protocol (NTP) para sincronizar a hora do servidor com o Tempo Universal Coordenado (UTC). Em um sistema Linux, use o comando ntpdate ou chrony para sincronizar a hora. Você pode executar o comando sudo ntpdate pool.ntp.org para sincronização manual.

     2. Verifique as configurações de fuso horário: Para garantir que o fuso horário esteja definido corretamente, use o comando timedatectl para visualizar e definir o fuso horário.

     3. Reinicie o cliente de backup e execute o trabalho de backup novamente no console Cloud Backup. Para obter instruções, consulte Como verifico o status do processo do cliente, encontro o caminho do log e reinicio o cliente?.

SQL Server

Se um backup falhar ao usar o Cloud Backup para fazer backup de um banco de dados SQL Server, siga estas etapas:

1. Acesse o servidor e visualize o log de backup.

   O caminho do log do cliente Windows é: C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log

2. Com base no intervalo de tempo (hora de início e término) do registro de erro no console, localize e analise as entradas de log próximas ao horário em que a tarefa falhou. Se o log de backup contiver alguma das seguintes mensagens de erro, use a solução correspondente:

   • Erro: O login tem permissões insuficientes.

     Causa: A conta de backup do SQL Server tem permissões insuficientes.

     Solução: Verifique a conta de backup e suas permissões. Para mais informações, consulte Etapa 2: Criar uma conta de backup e configurar permissões.

   • Erro: Login failed for user 'xxx'.

     Causa: A senha do usuário de backup do SQL Server expirou (Código de Erro: 18487, Estado SQL: 28000).

     Solução: Altere a senha do usuário de backup no SQL Server. Em seguida, acesse o console Cloud Backup e, na coluna Ações do banco de dados, escolha More > Reactivate.

   • Erro: Cannot overwrite file.

     Causa: O caminho de restauração do banco de dados SQL Server está ocupado por outro banco de dados.

     Solução: Crie um novo trabalho de restauração. Ao restaurar a partir de um backup especificado, clique duas vezes no caminho de restauração para modificá-lo.

     Na aba Restore Configuration, você pode configurar parâmetros como reconnection time e rate limit. Você também pode clicar duas vezes em um caminho alvo na árvore de caminhos de arquivo abaixo para modificá-lo.

   • Erro: The target SQL Server database does not exist. Make sure you have entered the name correctly.

     Causa: O banco de dados SQL Server alvo não existe.

     Solução: Verifique se o banco de dados alvo existe. Se o banco de dados não existir mais, edite o plano de backup e remova o banco de dados correspondente.

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

     Causa: O SQL Server AlwaysOn está ativado para o banco de dados SQL Server.

     Solução: Para restaurar o banco de dados, use o comando ALTER DATABASE para removê-lo da sessão de espelhamento de banco de dados ou do grupo de disponibilidade.

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

     Causa: O SQL Server AlwaysOn está ativado para o banco de dados SQL Server.

     Solução: Para restaurar o banco de dados, use o comando ALTER DATABASE para removê-lo da sessão de espelhamento de banco de dados ou do grupo de disponibilidade.

   • Erro:

     O trabalho de backup falha no console, exibindo a mensagem "Job failed, error: -1 Backup or restore of database ""xxx"" failed, VDI error "0x80770004"".

     Etapas de solução de problemas:

     1. Acesse o diretório C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log e abra o arquivo de log. Com base no intervalo de tempo (horas de início e término) do registro de erro no console, localize os logs próximos ao horário em que a tarefa falhou.

     2. Se o log contiver "Failed to receive WebSocket data from x.x.x.x:60305, errno=10054, connection reset" ou "Failed to open socket x.x.x.x:60305, errno=10060, connection timed out", a conexão entre o cliente e o servidor de backup foi interrompida. Verifique sua conectividade de rede.

     3. Se "Channel xxxxxxxxxxxxxx is registered" aparecer nos logs subsequentes, o cliente reconectou-se ao servidor após nova tentativa. Você pode acionar um novo trabalho de backup ou aguardar a execução do próximo trabalho agendado e verificar se o backup prossegue normalmente.

     4. Se o backup ainda falhar, entre em contato com o suporte técnico para obter assistência. Você pode entrar no nosso grupo de suporte DingTalk ou contatar diretamente um especialista de serviço.

        • Cloud Backup Technical Support Group

          Obtenha respostas rápidas para suas perguntas sobre preços, recursos e uso. Clique para entrar no Suporte Online do Cloud Backup (Chrome recomendado). Pesquise e entre no grupo público usando o ID do DingTalk 88650005148.

        • Cloud Backup Expert Support

          Especialistas técnicos fornecem análise ao vivo para resolver rapidamente problemas do produto. Clique para contatar o suporte do Cloud Backup (Chrome recomendado). Adicione o contato no DingTalk usando o ID: d37_g935gslgo.

MySQL

Cancelar um backup de banco de dados interrompe todas as taxas associadas e libera seus recursos.

1. Exclua o plano de backup.

2. Cancele o registro da instância. Ao cancelar o registro de um banco de dados de instância ECS, o cliente de backup instalado é desinstalado automaticamente.

3. Se o banco de dados MySQL estiver instalado em um servidor local, acesse o servidor local e desinstale o cliente de backup.

   • 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. Exclua os seguintes diretórios:

   • Linux:

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

5. Exclua o cofre de backup.

   No painel de navegação, clique em Vault Management. Em seguida, localize e exclua o cofre de backup correspondente.

Oracle

Cancelar um backup de banco de dados interrompe todas as taxas associadas e libera seus recursos.

1. Exclua o plano de backup.

2. Cancele o registro da instância. Ao cancelar o registro de um banco de dados de instância ECS, o cliente de backup instalado é desinstalado automaticamente.

3. Se o banco de dados Oracle estiver instalado em um servidor local, acesse o servidor local e desinstale o cliente de backup.

   • Windows:

     1. No PowerShell, navegue até o diretório de instalação do cliente de backup. Por exemplo, C:\Program Files\aliyun\unibackup>.

     2. Execute o seguinte comando:

         .\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. Exclua os arquivos de configuração.

   • Windows:

     Exclua todos os arquivos de configuração em c:\programdata\scutech.

   • Linux:

     Exclua os seguintes diretórios:

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

5. Exclua o cofre de backup.

   No painel de navegação, clique em Vault Management. Em seguida, localize e exclua o cofre de backup correspondente.

SQL Server

Cancelar um backup de banco de dados interrompe todas as taxas associadas e libera seus recursos.

1. Exclua o plano de backup.

2. Cancele o registro da instância. Ao cancelar o registro de um banco de dados de instância ECS, o cliente de backup instalado é desinstalado automaticamente.

3. Se o banco de dados SQL Server estiver instalado em um servidor local, acesse o servidor local e desinstale o cliente de backup.

   • Windows:

     1. No PowerShell, navegue até o diretório de instalação do cliente de backup. Por exemplo, C:\Program Files\aliyun\unibackup>.

     2. Execute o comando uninstall-unibackup.exe e siga as instruções no assistente de desinstalação.

5. Exclua todos os arquivos de configuração em c:\programdata\scutech.

6. Exclua o cofre de backup.

   No painel de navegação, clique em Vault Management. Em seguida, localize e exclua o cofre de backup correspondente.

Registros de backup duplicados ou inesperados

Isso ocorre quando você clona um servidor (local ou instância ECS) que possui o cliente de backup de banco de dados instalado, ou quando cria uma nova instância ECS ou servidor local a partir de uma imagem que inclui o mesmo cliente. O servidor clonado retém algumas informações do cliente do servidor original, o que causa registros de backup duplicados. Para resolver esse problema, acesse o servidor clonado e desinstale o cliente. Para desinstalar o cliente de backup de banco de dados, siga as instruções relevantes abaixo.

MySQL

Cancelar o registro de uma instância ECS desinstala automaticamente o cliente de backup de banco de dados. Se o banco de dados MySQL estiver em um servidor local, siga estas etapas para desinstalar o cliente:

1. Desinstale o cliente.

   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. Exclua os seguintes diretórios:

   Linux:

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

Oracle

Cancelar o registro de uma instância ECS desinstala automaticamente o cliente de backup de banco de dados. Se o banco de dados Oracle estiver em um servidor local, siga estas etapas para desinstalar o cliente:

1. Desinstale o cliente.

   • Windows:

     1. No PowerShell, navegue até o diretório de instalação do cliente de backup. Por exemplo, C:\Program Files\aliyun\unibackup>.

     2. Execute o seguinte comando:

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

3. Exclua os arquivos de configuração.

   • Windows:

     Exclua todos os arquivos de configuração do diretório c:\programdata\scutech.

   • Linux:

     Exclua os seguintes diretórios:

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

SQL Server

Cancelar o registro de uma instância ECS desinstala automaticamente o cliente de backup de banco de dados. Se o banco de dados SQL Server estiver em um servidor local, siga estas etapas para desinstalar o cliente:

1. Desinstale o cliente.

   • Windows:

     1. No PowerShell, navegue até o diretório de instalação do cliente de backup. Por exemplo, C:\Program Files\aliyun\unibackup>.

     2. Execute o comando uninstall-unibackup.exe e siga o assistente para concluir a desinstalação.

3. Exclua os arquivos de configuração.

   • Windows:

     Exclua todos os arquivos de configuração do diretório c:\programdata\scutech.

Erro no plano de backup

Se um backup falhar e o status do plano de backup for "Error", verifique primeiro se o servidor (local ou instância ECS) onde o cliente está instalado foi clonado, teve seu sistema operacional reinstalado ou teve seu disco de sistema redefinido. Essas operações podem quebrar a associação entre o plano de backup e o cliente. Para resolver esse problema, siga estas etapas:

1. Desinstale o cliente e remova seu arquivo de configuração do servidor clonado. Para mais informações, consulte Desinstalar o cliente.

2. Verifique se o status do cliente no servidor atual é "Installed".

3. Exclua o plano de backup original no console e crie um novo plano de backup.

Inconsistência no horário do alerta

Com a supressão noturna, alertas por mensagem de texto acionados entre 20h e 8h só são enviados após as 8h. Em contraste, alertas por e-mail são enviados imediatamente.

Registros de backup de sucesso e falha duplicados

Isso ocorre quando você clona um servidor (local ou instância ECS) que possui o cliente de backup de banco de dados instalado, ou quando cria uma nova instância ECS ou servidor local a partir de uma imagem que inclui o mesmo cliente. O servidor clonado retém algumas informações do cliente do servidor original, o que causa registros de backup duplicados. Para resolver esse problema, acesse o servidor clonado e desinstale o cliente. Para desinstalar o cliente de backup de banco de dados, siga as instruções relevantes abaixo.

MySQL

Para bancos de dados em uma instância ECS, o cliente de backup é desinstalado automaticamente quando a instância é liberada. Se o banco de dados MySQL estiver instalado em um servidor local, desinstale o cliente da seguinte forma:

1. Desinstale o cliente.

   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. Exclua os seguintes diretórios:

   Linux:

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

Oracle

Para bancos de dados em uma instância ECS, o cliente de backup é desinstalado automaticamente quando a instância é liberada. Se o banco de dados Oracle estiver instalado em um servidor local, desinstale o cliente da seguinte forma:

1. Desinstale o cliente.

   • Windows:

     1. Navegue até o diretório de instalação do cliente de backup no PowerShell. Por exemplo, C:\Program Files\aliyun\unibackup>.

     2. Execute o comando.

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

3. Limpe os arquivos de configuração.

   • Windows:

     Exclua todos os arquivos de configuração no diretório c:\programdata\scutech.

   • Linux:

     Exclua os seguintes diretórios:

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

SQL Server

Para bancos de dados em uma instância ECS, o cliente de backup é desinstalado automaticamente quando a instância é liberada. Se o banco de dados SQL Server estiver instalado em um servidor local, desinstale o cliente da seguinte forma:

1. Desinstale o cliente.

   • Windows:

     1. Navegue até o diretório de instalação do cliente de backup no PowerShell. Por exemplo, C:\Program Files\aliyun\unibackup>.

     2. Execute o comando uninstall-unibackup.exe e siga o assistente.

3. Limpe os arquivos de configuração.

   • Windows:

     Exclua todos os arquivos de configuração no diretório c:\programdata\scutech.

Problemas de restauração

Recurso View Offline Instances Only

O recurso View Offline Instances Only aplica-se a cenários onde um cliente não consegue mais se conectar à sua instância original, tornando necessário restaurar dados de um backup. Isso pode acontecer se o sistema operacional no cliente for reinstalado ou se o processo e a configuração do cliente forem excluídos, por exemplo, por um programa malicioso. Nesses casos, se você instalar um novo cliente, o sistema atribuirá a ele um ID de instância diferente para distingui-lo da instância offline e evitar confusão. Você pode então restaurar dados da instância offline para a nova. Para instruções detalhadas, consulte Restaurar MySQL, Restaurar Oracle e Restaurar SQL Server.

Resolução de falhas de restauração do SQL Server

1. Acesse o servidor e visualize o log de backup.

   Caminho do log do cliente Windows: C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log

2. No log, verifique as entradas próximas ao horário em que a tarefa falhou.

   Se o log de backup contiver a palavra-chave RestoreContainer::ValidateTargetForCreation, isso indica que a operação de restauração falhou porque você alterou o caminho do banco de dados, mas não o nome do banco de dados, causando um conflito de nomes. Para restaurar o banco de dados com êxito, altere tanto o nome do banco de dados quanto o caminho.

Falha na restauração do SQL Server: Erro de inicialização de arquivo

• Sintoma

  Quando uma restauração do SQL Server falha, o log do agente mostra que um arquivo não conseguiu inicializar corretamente. O log exibe o seguinte:

  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.

  Além disso, o ErrorLog do SQL Server relata a mensagem the file "xxx_log" failed to initialize correctly.

• Causa

  Esse erro pode ocorrer ao restaurar um backup de um banco de dados SQL Server 2008 R2 que foi previamente criptografado. Mesmo após desativar a criptografia, informações residuais podem permanecer no conjunto de backup, causando o erro de inicialização de arquivo ao restaurá-lo. O processo de análise é o seguinte.

  Nota

  Se o banco de dados de origem for SQL Server 2008 R2 e tiver transparent data encryption (TDE) ativado, a operação de restauração falhará mesmo se a instância de destino for uma versão posterior, como SQL Server 2014. A restauração falha com um erro "Certificate not found". Para concluir a restauração, você deve restaurar manualmente o certificado e a chave privada.

  1. Confirme a versão do banco de dados no ErrorLog do SQL Server.

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

  2. Esse problema geralmente está relacionado à transparent data encryption (TDE). Confirme se o TDE foi ativado alguma vez no banco de dados de origem, mesmo que esteja desativado atualmente.

     Execute a seguinte instrução SQL no banco de dados. Se as colunas key_algorithm e key_length para o seu banco de dados no resultado da consulta não forem NULL, o banco de dados provavelmente foi criptografado no passado.

     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;

     Um exemplo de resultado da consulta é o seguinte.

     Nos resultados da consulta, se os valores dos campos key_algorithm e key_length para um banco de dados não forem NULL, isso indica que a criptografia TDE foi ativada para esse banco de dados.

• Solução

  • Atualize o banco de dados de origem para uma versão posterior e crie um novo backup. Use o novo conjunto de backup para realizar a operação de restauração. Conjuntos de backup anteriores são inválidos.

  • Restaure a chave privada e o certificado da instância de origem para a instância de destino e, em seguida, realize a operação de restauração.

    Após a conclusão da restauração, exclua o certificado TDE e a chave de criptografia do banco de dados da instância de destino. Em seguida, faça backup da instância de destino. As operações subsequentes de backup e restauração na instância de destino funcionarão corretamente.

    Nota

    Mesmo que o backup de dados tenha sido criado após a desativação do TDE, o processo de restauração ainda requer a chave privada e o certificado. Eles são necessários para lidar com metadados criptografados residuais no backup. No entanto, o banco de dados restaurado em si não é criptografado e pode funcionar normalmente sem o certificado posteriormente.

    # 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;

Restauração entre bancos de dados: Local e ECS

A restauração direta entre esses dois ambientes não tem suporte. Você deve primeiro registrar o banco de dados na instância ECS como uma instância de banco de dados local. Após o registro, você pode restaurar dados entre diferentes instâncias de banco de dados locais.

Perguntas sobre cofres de backup

O que é um cofre de backup de banco de dados?

Você deve criar um cofre de backup de banco de dados antes de poder criar um plano de backup de banco de dados.

Um cofre de backup de banco de dados é um repositório que armazena seus backups de banco de dados. A taxa de aluguel do cofre e a capacidade do cofre determinam o custo de um backup de banco de dados. Para mais informações, consulte Métodos de faturamento e itens faturáveis.

Remoção de backups expirados

Backups incrementais, backups incrementais cumulativos e backups de log dependem de uma cadeia de backup completa. Essa cadeia inclui o backup completo inicial e todos os backups incrementais, incrementais cumulativos e de log subsequentes. Em uma cadeia de backup, todos os backups dependentes são retidos e consomem espaço de armazenamento até que o último backup da cadeia expire. Você deve configurar seu ciclo de backup e tempo de expiração cuidadosamente para gerenciar os custos de armazenamento.

Por exemplo, se você realizar um backup completo em 1º de setembro e um backup incremental todos os dias de 2 a 7 de setembro com um período de retenção de sete dias, os sete backups criados de 1º a 7 de setembro serão excluídos automaticamente somente após toda a cadeia expirar em 14 de setembro.

Tamanho dos dados, uso e faturamento

O Source Data Size representa a quantidade total de dados que você fez backup. Por exemplo, se você fizer backup de um arquivo de 1 TB duas vezes, o Cloud Backup armazenará duas cópias independentes, e o Source Data Size será calculado como 2 TB. O Cloud Backup usa deduplicação e compactação para reduzir o armazenamento consumido pelos seus backups, o que ajuda a economizar custos. O faturamento é baseado no Storage Vault Data Size real. Você pode visualizar o Source Data Size e o Storage Vault Data Size de um cofre de backup de banco de dados na página Vault Management.