Resolver problemas de cópia de segurança de bases de dados do SQL Server com o Azure Backup

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

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

Permissões do SQL Server

Para configurar a proteção para 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 o erro UserErrorSQLNoSysadminMembership, isso significa que sua instância do SQL Server não tem as permissões de backup necessárias. Para corrigir esse erro, siga as etapas em Definir permissões de VM.

Resolver problemas de descoberta e configuração

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

Durante a configuração de backup, se a SQL VM e suas instâncias não estiverem visíveis nos DBs de Descoberta em VMs e Configurar Backup (consulte a imagem acima), certifique-se de que:

Etapa 1: DBs de descoberta em VMs

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

Etapa 2: Configurar o backup

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

Se a VM SQL precisar ser registrada no novo cofre, ela deverá ser cancelada do cofre antigo. O cancelamento do registro de uma VM SQL do cofre exige que todas as fontes de dados protegidas sejam interrompidas e, em seguida, você pode excluir os dados de backup. A exclusão de dados de backup é uma operação destrutiva. Depois de revisar e tomar todas as precauções para cancelar o registro da VM SQL, registre essa mesma VM em um novo cofre e tente novamente a operação de backup.

Solucionar problemas de backup e recuperação

Às vezes, falhas aleatórias podem acontecer em operações de backup e restauração ou essas operações podem ficar presas. Isso pode ser devido a programas antivírus em sua VM. Como prática recomendada, sugerimos as seguintes etapas:

1. Exclua as seguintes pastas da verificação antivírus:

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

   Substitua C:\ pela letra do seu 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. SQL também oferece algumas diretrizes sobre como trabalhar com programas antivírus. Para obter mais detalhes, veja este artigo.

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

Você pode restaurar para uma VM SQL somente se todas as instâncias SQL em execução na VM forem relatadas como íntegras. Se uma ou mais instâncias estiverem "defeituosas", a VM não aparecerá como um destino de restauração. Portanto, essa pode ser uma possível razão pela qual uma VM de várias instâncias pode não aparecer no menu suspenso "servidor" durante a operação de restauração.

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

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

1. Entre na VM 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.

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

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

4. Acione a operação Rediscover DBs no servidor afetado a partir do portal do Azure (o mesmo local onde a prontidão do 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 assim que a operação de restauração for concluída.

Mensagens de erro

Tipo de backup não suportado

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 registo

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

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

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

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

  

• No caso de um grupo de disponibilidade Always On, os backups começaram a falhar depois que você alterou a preferência de backup ou após um failover.

Estes sintomas podem surgir por uma ou mais das seguintes razões:

• Uma extensão foi excluída ou desinstalada do portal.
• Uma extensão foi desinstalada do Painel de Controle na VM em Desinstalar ou Alterar um Programa.
• A VM foi restaurada no tempo por meio da restauração de disco in-loco.
• A VM foi desligada por um longo período, portanto, a configuração de extensão nela 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. Consulte aqui para obter instruções sobre como executar essa tarefa no PowerShell.

Limite de tamanho para ficheiros

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 de banco de dados, obtenha o nome do arquivo lógico e o caminho físico. Você pode usar esta consulta 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}]

Eis 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 de banco de dados serão armazenados de forma 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 database_name.json arquivo e coloque-o no local C:\Program Files\Azure Workload Backup\bin\plugins\SQL*.

O conteúdo do ficheiro deve estar neste formato:

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

Eis 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 acionar a operação de restauração.

Próximos passos

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