Cloud Backup:Perguntas frequentes sobre backup de banco de dados

MySQL

1. O problema pode ser causado por um Database Account ou Password incorretos, 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 Create a MySQL backup account and configure permissions.

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

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

   O path do log do client é /var/log/dbackup3/agent.log.

Oracle

1. O problema pode ser causado por um Database Account ou Password incorretos, 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 Create an Oracle backup account and configure permissions.

2. Reinicie o client de backup.

   • Linux: Execute systemctl restart dbackup3-agent para reiniciar o client 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 client de backup, colete os arquivos de log para análise.

   • O path do log do client no Linux é /var/log/dbackup3/agent.log.

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

SQL Server

1. O problema pode ser causado por um Database Account ou Password incorretos, 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 Create an SQL Server backup account and configure permissions.

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 path do log do client é Local Disk (C) > ProgramData > scutech > dbackup3 > agent > log > dbackup3-agent.log.

MySQL

1. Verifique o status do banco de dados MySQL.

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

2. Reinicie o service MySQL.

   Execute o comando systemctl start mysqld para reiniciar o service MySQL. O database status no console muda para Online.

Oracle

1. Verifique o status do listener do Oracle.

   Faça login na instância ECS e execute os seguintes comandos:

   su - oracle
   lsnrctl status

   Se o service estiver em execução, o status será running. Caso contrário, a 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 exibe o status da instância. O status OPEN indica que o banco de dados está aberto e pronto para receber conexões.

3. Reinicie o listener do Oracle.

   Inicie o service de listener do Oracle para que ele ouça as requisições de conexão dos clients.

   su - oracle
   lsnrctl start

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

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

   sqlplus / as sysdba;
   STARTUP;

   Após a instância do banco de dados iniciar, o database status no console muda 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 service do SQL Server, como "SQL Server (MSSQLSERVER)".

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

2. Reinicie o service do SQL Server.

   Se o status do banco de dados SQL Server for Stopped ou Paused, clique com o botão direito no service do SQL Server e selecione Start. Se a opção Start estiver desabilitada, reabra o console de gerenciamento de serviços como administrador e tente novamente. Após o service iniciar, o database status no console muda para Online.

MySQL

Em Job History, o status do job é Error.

Siga estas etapas:

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

   Execute o comando systemctl status mysqld. Um status ativo indica que o service está funcionando normalmente. Se o status for inativo, o service não está em execução corretamente. Reinicie o service 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 o Database Account ou a Password inseridos durante o registro do banco de dados estiverem incorretos, 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, o horário local do servidor está incorreto. Corrija-o.

   • Se o log contiver a palavra-chave ib_logfile0, uma operação de restauração foi iniciada enquanto outro job de restauração já estava em andamento. Isso causou a exclusão do arquivo ib_logfile0 sem que ele fosse recriado, resultando em falhas nos backups subsequentes.

   • 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 executar um job de backup, a conta precisa pelo menos das 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 job de restauração falhou no cliente de backup MySQL versão 29292 por falta de espaço em cache para restaurar arquivos de backup incremental. Crie um link simbólico que aponte o path de armazenamento para outro disco para 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ó slave. 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 mensagens de erro a seguir, utilize 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á ausente ou configurada incorretamente, o que pode impedir a conexão com o Oracle. Tente acessar usando o comando sqlplus com permissões sysdba. Se o acesso for bem-sucedido após configurar corretamente a variável ORACLE_SID, o problema estará resolvido.

   • Se o log contiver a palavra-chave sbtclose2 returned error-failed to close file, o horário local do servidor está incorreto ou o fuso horário do sistema não está configurado corretamente. Corrija o horário no servidor de banco de dados e reinicie o service dbackup3-agent. Para instruções, consulte How do I check the client process status, find the log path, and restart the client?.

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

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

       Reinicie o service dbackup3-agent. Para instruções, consulte How do I check the client process status, find the log path, and restart the client?.

     • 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 path real do $ORACLE_HOME.

       2. Reinicie o service dbackup3-agent. Para instruções, consulte How do I check the client process status, find the log path, and restart the client?.

   • 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 consequentemente 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, em seguida, realize o backup novamente.

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

     Solução:

     1. Verifique e sincronize o horário: recomendamos usar o Network Time Protocol (NTP) para sincronizar o horário do servidor com o Coordinated Universal Time (UTC). Em sistemas Linux, use o comando ntpdate ou chrony para sincronizar o horário. Execute o comando sudo ntpdate pool.ntp.org para sincronização manual.

     2. Verifique as configurações de fuso horário: use o comando timedatectl para visualizar e definir o fuso horário corretamente.

     3. Reinicie o cliente de backup e execute o job de backup novamente no console do Cloud Backup. Para instruções, consulte How do I check the client process status, find the log path, and restart the client?.

SQL Server

Se um backup falhar ao usar 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 path do log do cliente Windows é: C:\ProgramData\scutech\dbackup3\agent\log\dbackup3-agent.log

2. Com base no intervalo de tempo (horário de início e fim) do registro de erro no console, localize e analise as entradas do log próximas ao momento em que a tarefa falhou. Se o log de backup contiver alguma das mensagens de erro a seguir, utilize 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 Step 2: Create a backup account and configure permissions.

   • Erro: Login failed for user 'xxx'.

     Causa: A senha do usuário de backup do SQL Server expirou (Error Code: 18487, SQL State: 28000).

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

   • Erro: Cannot overwrite file.

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

     Solução: Crie um novo job de restauração. Ao restaurar a partir de um backup específico, clique duas vezes no path de restauração para modificá-lo.

     Na aba Restore Configuration, configure parâmetros como reconnection time e rate limit. Clique duas vezes em um path de destino na árvore de paths 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 de destino não existe.

     Solução: Confirme que o banco de dados de destino existe. Caso ele não exista 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 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 ou do grupo de disponibilidade.

   • Erro:

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

     Etapas de diagnóstico:

     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 (horários de início e fim) do registro de erro no console, localize os logs próximos ao momento 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 a conectividade de rede.

     3. Se "Channel xxxxxxxxxxxxxx is registered" aparecer nos logs subsequentes, o cliente se reconectou ao servidor após nova tentativa. Dispare um novo job de backup ou aguarde o próximo job agendado e verifique se o backup é executado normalmente.

     4. Se o backup continuar falhando, entre em contato com o suporte técnico. Participe do grupo de suporte no DingTalk ou contate diretamente um especialista.

        • Cloud Backup Technical Support Group

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

        • Cloud Backup Expert Support

          Especialistas técnicos realizam análise em tempo real para resolver problemas rapidamente. Clique para contatar o suporte do Cloud Backup (recomendamos o Chrome). Adicione o contato no DingTalk usando o ID: d37_g935gslgo.

MySQL

Cancelar um backup de banco de dados encerra todas as cobranças 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 encerra todas as cobranças 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, acesse 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 encerra todas as cobranças associadas e libera seus recursos.

1. Exclua o plano de backup.

2. Cancele

   Problemas de restauração

   Recurso View Offline Instances Only

   O recurso Vault Management se aplica a cenários em que o cliente não consegue mais se conectar à instância original, tornando necessário restaurar dados a partir de um backup. Isso pode ocorrer quando o sistema operacional do cliente é reinstalado ou quando o processo e a configuração do cliente são excluídos — por exemplo, por um programa malicioso. Nessas situações, ao instalar um novo cliente, o sistema atribui a ele um ID de instância diferente para distingui-lo da instância offline e evitar confusões. Em seguida, restaure os dados da instância offline para a nova instância. Para instruções detalhadas, consulte Restore MySQL, Restore Oracle e Restore SQL Server.

   Como resolver falhas de restauração no SQL Server

   1. Faça login no server e visualize o log de backup.

      Path do log do client 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 o path do banco de dados foi alterado sem que o nome do banco de dados também fosse alterado, causando um conflito de nomes. Para restaurar o banco de dados com sucesso, altere tanto o nome quanto o path do banco de dados.

   Falha de restauração no SQL Server: erro de inicialização de file

   • Sintoma

     Quando uma restauração do SQL Server falha, o log do agente indica que um file não foi inicializado 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 registra 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 criptografado anteriormente. Mesmo após desativar a criptografia, informações residuais podem permanecer no conjunto de backup, provocando o erro de inicialização do file durante a restauração. O processo de análise é o seguinte.

     Nota

     Se o banco de dados source for SQL Server 2008 R2 e tiver a criptografia de dados transparente (TDE) ativa, a operação de restauração falhará mesmo que a instância de destino seja uma versão mais recente, como o SQL Server 2014. A restauração falha com o erro "Certificate not found". Para concluir a restauração, restaure manualmente o certificado e a chave privada.

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

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

     2. Esse problema geralmente está relacionado à criptografia de dados transparente (TDE). Verifique se o TDE já foi ativado no banco de dados source em algum momento, mesmo que esteja atualmente desativado.

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

        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 é apresentado a seguir.

        Nos resultados da consulta, se os valores dos campos key_algorithm e key_length de 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 source para uma versão mais recente e crie um novo backup. Use o novo conjunto de backup para realizar a operação de restauração. Os conjuntos de backup anteriores são inválidos.

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

       Após concluir a restauração, exclua o certificado TDE e a chave de criptografia do banco de dados da instância de destino. Em seguida, faça o 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 dos 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 os 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 é compatível. Primeiro, register the database on the ECS instance as a local database instance. Após o registro, restaure dados entre diferentes instâncias de banco de dados locais.

   Perguntas sobre vaults de backup

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

   É necessário criar um vault de backup de banco de dados antes de criar um plano de backup de banco de dados.

   Um vault de backup de banco de dados é um repositório que armazena os backups do seu banco de dados. A taxa de aluguel do vault e a capacidade do vault determinam o custo de um backup de banco de dados. Para mais informações, consulte Billing methods and billable items.

   Como limpar 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. Configure o ciclo de backup e o prazo de expiração com cuidado para gerenciar os custos de armazenamento.

   Por exemplo, se você realizar um backup completo em 1º de setembro e um backup incremental diário 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 View Offline Instances Only representa a quantidade total de dados que você fez backup. Por exemplo, se você fizer backup de um file 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 utiliza deduplicação e compressão para reduzir o armazenamento consumido pelos backups, ajudando a economizar custos. O faturamento é baseado no Storage Vault Data Size real. Visualize o Source Data Size e o Source Data Size de um vault de backup de banco de dados na página Vault Management.