Solucionar problemas de backup do banco de dados do SQL Server usando o Backup do Azure

Este artigo fornece informações sobre a solução de problemas dos bancos de dados do SQL Server em execução nas máquinas virtuais do Azure.

Para obter mais informações sobre o processo e as limitações de backup, consulte Sobre o Backup do SQL Server nas VMs do Azure.

Permissões do SQL Server

Para configurar a proteção de um banco de dados do SQL Server em uma máquina virtual, você deve instalar a extensão AzureBackupWindowsWorkload nessa máquina virtual. Se você receber a mensagem de erro, UserErrorSQLNoSysadminMembership, isso significa que a Instância do SQL Server não possui as permissões de backup necessárias. Para corrigir esse erro, siga as etapas em Definir permissões da VM.

Solucionar problemas de descoberta e configuração

Quando a criação e a configuração de um cofre dos Serviços de Recuperação são concluídas, a descoberta de bancos de dados e a configuração do backup é um processo de duas etapas.

Durante a configuração de backup, se a VM do SQL e suas instâncias não estiverem visíveis na Descoberta de Bancos de Dados nas VMs e Configurar o backup (consulte a imagem acima), verifique se:

Etapa 1: Descoberta de Banco de Dados nas VMs

• Se a VM não estiver listada na lista de VMs descobertas e também não estiver registrada para backup do SQL em outro cofre, siga as etapas de Descoberta de backup do SQL Server.

Etapa 2: Configurar Backup

• Se o cofre no qual a VM do SQL está registrada for o mesmo cofre usado para proteger os bancos de dados, siga as etapas em Configurar Backup.

Se a VM do SQL precisar ser registrada no novo cofre, ela deverá ter o registro cancelado do cofre antigo. O cancelamento do registro de uma VM do SQL do cofre requer que todas as fontes de dados protegidas tenham a proteção interrompida e, em seguida, você pode excluir os dados de backup. A exclusão de dados de backup é uma operação destrutiva. Depois de examinar e tomar todas as precauções para cancelar o registro da VM do SQL, registre essa mesma VM com um novo cofre e repita a operação de backup.

Solução de problemas de Backup e Recuperação

Às vezes, qualquer falha aleatória pode ocorrer em operações de backup e restauração ou essas operações podem ficar paradas. Isso pode ocorrer devido a programas antivírus em sua VM. Sugerimos as seguintes etapas como melhor prática:

1. Exclua estas pastas da verificação do antivírus:

   C:\Program Files\Azure Workload Backup C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.RecoveryServices.WorkloadBackup.AzureBackupWindowsWorkload

   Substitua C:\ pela letra do SystemDrive.

2. Exclua os três processos a seguir em execução em uma VM da verificação antivírus:

   • IaasWLPluginSvc.exe
   • IaaSWorkloadCoordinatorService.exe
   • TriggerExtensionJob.exe

3. O SQL também oferece algumas diretrizes para trabalhar com programas antivírus. Confira este artigo para obter detalhes.

Instância com falha em uma VM com várias instâncias do SQL Server

Você poderá restaurar para uma VM do SQL somente se todas as instâncias do SQL em execução na VM forem relatadas como íntegras. Se uma ou mais instâncias forem "defeituosas", a VM não aparecerá como um destino de restauração. Portanto, isso pode ser um possível motivo pelo qual uma VM de várias instâncias pode não aparecer na lista suspensa "servidor" durante a operação de restauração.

Você pode validar a "Prontidão de Backup" de todas as instâncias do SQL na VM, em Configurar backup:

Se você quiser disparar uma restauração nas instâncias íntegras do SQL, execute as seguintes etapas:

1. Entre na VM do SQL e vá para C:\Program Files\Azure Workload Backup\bin.

2. Crie um arquivo JSON chamado ExtensionSettingsOverrides.json (se ainda não estiver presente). Se esse arquivo já estiver presente na VM, continue usando o mesmo.

3. Adicione o seguinte conteúdo ao arquivo JSON e salve-o:

   {
                 "<ExistingKey1>":"<ExistingValue1>",
                   …………………………………………………… ,
             "whitelistedInstancesForInquiry": "FaultyInstance_1,FaultyInstance_2"
           }
   
           Sample content:        
           { 
             "whitelistedInstancesForInquiry": "CRPPA,CRPPB "
           }
   
   

4. Dispare a operação Redescobrir Bancos de Dados nos servidores afetados do portal do Azure (o mesmo local em que a prontidão de backup pode ser vista). A VM começará a aparecer como destino para operações de restauração.

   

5. Remova a entrada whitelistedInstancesForInquiry do arquivo ExtensionSettingsOverrides.json depois que a operação de restauração for concluída.

Mensagens de erro

Tipo de backup sem suporte

UserErrorSQLPODoesNotSupportBackupType

OperationCancelledBecauseConflictingOperationRunningUserError

UserErrorFileManipulationIsNotAllowedDuringBackup

UserErrorSQLPODoesNotExist

UserErrorSQLLSNValidationFailure

UserErrorOpeningSQLConnection

UserErrorParentFullBackupMissing

UserErrorBackupFailedAsTransactionLogIsFull

UserErrorCannotRestoreExistingDBWithoutForceOverwrite

UserErrorRestoreFailedDatabaseCannotBeOfflined

WlExtGenericIOFaultUserError

UserErrorCannotFindServerCertificateWithThumbprint

UserErrorRestoreNotPossibleBecauseLogBackupContainsBulkLoggedChanges

FabricSvcBackupPreferenceCheckFailedUserError

VMNotInRunningStateUserError

GuestAgentStatusUnavailableUserError

AutoProtectionCancelledOrNotValid

CloudDosAbsoluteLimitReached

CloudDosAbsoluteLimitReachedWithRetry

WorkloadExtensionNotReachable

UserErrorVMInternetConnectivityIssue

UserErrorOperationNotAllowedDatabaseMirroringEnabled

UserErrorWindowsWLExtFailedToStartPluginService

Falhas no novo registro

Verifique se um ou mais dos seguintes sintomas existem, antes de acionar a operação de novo registro:

• Todas as operações (como backup, restauração e configuração de backup) falham na VM com um dos seguintes códigos de erro: WorkloadExtensionNotReachable , UserErrorWorkloadExtensionNotInstalled, WorkloadExtensionNotPresent, WorkloadExtensionDidntDequeueMsg.

• Se a área de Status de backup para o item de backup estiver mostrando Não acessível, descarte todas as outras causas que possam resultar no mesmo status:

  • Falta de permissão para realizar as operações relacionadas ao backup na VM.
  • Desligamento da VM, para que os backups não ocorram.
  • Problemas de rede

  

• No caso de um grupo de disponibilidade Always On, os backups começaram a falhar após a alteração da preferência de backup ou após um failover.

Esses sintomas podem surgir devido a uma ou mais das seguintes razões:

• Uma extensão foi excluída ou desinstalada no portal.
• Uma extensão foi desinstalada do Painel de Controle na VM em Desinstalar ou Alterar um Programa.
• A VM foi restaurada retroativamente por meio da restauração de disco in-loco.
• A VM foi desligada por um período prolongado, portanto, a configuração de extensão expirou.
• A VM foi excluída e outra VM foi criada com o mesmo nome e no mesmo grupo de recursos que a VM excluída.
• Um dos nós do grupo de disponibilidade não recebeu a configuração de backup completa. Isso pode acontecer quando o grupo de disponibilidade é registrado no cofre ou quando um novo nó é adicionado.

Nos cenários anteriores, recomendamos que você acione uma operação de novo registro na VM. Veja aqui as instruções sobre como executar essa tarefa no PowerShell.

Limite de tamanho para arquivos

O tamanho total da cadeia de caracteres dos arquivos depende não apenas do número de arquivos, mas também de seus nomes e caminhos. Para cada arquivo do banco de dados, obtenha o nome do arquivo lógico e o caminho físico. Você pode usar esta consulta de SQL:

SELECT mf.name AS LogicalName, Physical_Name AS Location FROM sys.master_files mf
               INNER JOIN sys.databases db ON db.database_id = mf.database_id
               WHERE db.name = N'<Database Name>'"

Agora, organize-os no seguinte formato:

[{"path":"<Location>","logicalName":"<LogicalName>","isDir":false},{"path":"<Location>","logicalName":"<LogicalName>","isDir":false}]}

Veja um exemplo:

[{"path":"F:\\Data\\TestDB12.mdf","logicalName":"TestDB12","isDir":false},{"path":"F:\\Log\\TestDB12_log.ldf","logicalName":"TestDB12_log","isDir":false}]}

Se o tamanho da cadeia de caracteres do conteúdo exceder 20.000 bytes, os arquivos do banco de dados serão armazenados de maneira diferente. Durante a recuperação, você não poderá definir o caminho do arquivo de destino para restauração. Os arquivos serão restaurados para o caminho SQL padrão fornecido pelo SQL Server.

Substituir o caminho do arquivo de restauração de destino padrão

Você pode substituir o caminho do arquivo de restauração de destino durante a operação de restauração, colocando um arquivo JSON que contém o mapeamento do arquivo de banco de dados para o caminho de restauração de destino. Crie um arquivo database_name.json e coloque-o no local C:\Program Files\Azure Workload Backup\bin\plugins\SQL*.

O conteúdo do arquivo deve estar neste formato:

[
  {
    "Path": "<Restore_Path>",
    "LogicalName": "<LogicalName>",
    "IsDir": "false"
  },
  {
    "Path": "<Restore_Path>",
    "LogicalName": "LogicalName",
    "IsDir": "false"
  },  
]

Veja um exemplo:

[
  {
   "Path": "F:\\Data\\testdb2_1546408741449456.mdf",
   "LogicalName": "testdb7",
   "IsDir": "false"
  },
  {
    "Path": "F:\\Log\\testdb2_log_1546408741449456.ldf",
    "LogicalName": "testdb7_log",
    "IsDir": "false"
  },  
]

No conteúdo anterior, você pode obter o nome lógico do arquivo de banco de dados usando a seguinte consulta SQL:

SELECT mf.name AS LogicalName FROM sys.master_files mf
                INNER JOIN sys.databases db ON db.database_id = mf.database_id
                WHERE db.name = N'<Database Name>'"

Esse arquivo deve ser colocado antes de você disparar a operação de restauração.

Próximas etapas

Para obter mais informações sobreo Backup do Azure para VMs SQL.