Solucionar problemas de recuperação com o Microsoft Azure
Depois de criar um backup, talvez seja necessário recuperar os dados como parte de uma migração planejada ou em caso de perda de dados. Nesta unidade, você aprenderá como solucionar problemas de recuperação de dados para diferentes cenários.
Solucionar problemas de recuperação de arquivos para um backup de VM do Azure
Ao recuperar dados de um backup de VM do Azure, você tem três opções para restaurar os dados:
Recuperação de Ficheiros
Restaurar VMs
Restauração de disco. Somente os discos são restaurados, que podem ser usados para criar uma nova VM ou substituir um disco em uma VM existente.
Para recuperar arquivos, selecione a opção Recuperação de arquivos. É então um processo de três passos para recuperar os ficheiros:
Selecione um ponto de recuperação. Esta é a data em que os seus ficheiros estavam disponíveis.
Faça o download de um script. O script montará as unidades que armazenam seus arquivos. As unidades permanecerão montadas por 12 horas para que você restaure os arquivos necessários.
Desmonte as unidades e feche a conexão.
As seções a seguir fornecem informações de solução de problemas quando mensagens de erro comuns aparecem:
Mensagem de erro: Exceção detetada ao conectar-se ao destino
Isso pode aparecer se o script não conseguir acessar o ponto de recuperação. Para resolver este problema:
Verifique se a máquina que executa o script tem acesso ao cofre de recuperação.
Verifique a conexão com os endereços IP de destino do Azure. Para verificar, execute o seguinte a partir de um prompt de comando elevado: nslookup download.microsoft.com ou ping download.microsoft.com
Garanta o acesso à porta de saída iSCSI 3260.
Verifique se há um firewall ou NSG bloqueando o tráfego para IPs de destino do Azure ou URLs de serviço de recuperação.
Verifique se o software antivírus não está impedindo a execução do script.
Verifique também as seguintes mensagens de erro comuns:
Mensagem de erro: O destino já foi conectado por meio de uma sessão iSCSI
Isso pode ser causado pelo script já em execução na mesma máquina e as unidades já estão conectadas. Navegue pelos volumes disponíveis usando o Explorador de Arquivos para localizar as unidades montadas.
Mensagem de erro: Este script é inválido porque os discos foram desmontados via portal/excedeu o limite de 12 horas. Transferir um novo script a partir do portal
Esta mensagem aparece se tentar executar o script mais de 12 horas depois de o ter transferido. Você precisa baixar outro script do portal.
Mensagem de erro: ExtensionSnapshotFailedCOM
A operação de backup falhou devido a um problema com o aplicativo de sistema COM+ do serviço Windows. Para resolver este problema, siga estes passos:
Tente iniciar/reiniciar o serviço Windows COM+ System Application (a partir de um prompt de comando elevado – net start COMSysApp).
Verifique se o serviço Coordenador de Transações Distribuídas está sendo executado como uma conta do Serviço de Rede. Caso contrário, altere-o para ser executado como conta do Serviço de Rede e reinicie o Aplicativo do Sistema COM+.
Se não for possível reiniciar o serviço, reinstale o serviço Coordenador de Transações Distribuídas seguindo as etapas abaixo:
Pare o serviço MS DTC
Abra uma linha de comandos (cmd)
Execute o comando msdtc -uninstall
Execute o comando msdtc -install
Inicie o serviço MS DTC
Inicie o aplicativo de sistema COM+ do serviço Windows. Depois que o Aplicativo do Sistema COM+ for iniciado, acione um trabalho de backup do portal do Azure.
Para obter uma lista atualizada de mensagens de erro comuns e ações recomendadas, consulte Solucionar problemas de recuperação de arquivos de VM do Azure - Backup do Azure | Documentos Microsoft.
Solucionar problemas de restauração usando o agente de backup dos Serviços de Recuperação do Microsoft Azure (MARS)
Para restaurar os dados cujo backup foi feito usando os Serviços de Recuperação do Microsoft Azure (MARS):
Na tela inicial do agente MARS, selecione Recover Data. O Assistente para Recuperação de Dados é exibido.
Especifique onde deseja restaurar os dados.
Selecione os dados a serem restaurados e a data e hora do backup. Essas seleções determinam o ponto de recuperação de dados.
Selecione Montar para montar o disco que contém o ponto de recuperação e, em seguida, selecione o local onde deseja recuperar os dados.
Confirme suas seleções antes de iniciar a recuperação de dados.
Quando você instalou o agente MARS, uma senha de criptografia foi gerada. Isso é armazenado em um arquivo de texto e deve ser mantido em algum lugar seguro. Se a senha for perdida, não será possível recuperar nenhum dado cujo backup seja feito pelo agente de backup MARS.
Quando o agente MARS é configurado, você especifica por quanto tempo os dados de backup devem ser mantidos. Os dados não serão conservados após este período de tempo.
Solucionar problemas de restauração ao usar o agente de backup do Azure
Quando você recupera uma Máquina Virtual do Azure de um backup, um servidor de processo é usado para manipular os dados. Se você tiver problemas com a restauração de dados, use uma metodologia passo a passo:
Etapa 1: Monitorar a integridade do servidor de processo
É uma boa prática monitorar proativamente o servidor de processo ao restaurar dados. Isso permite que você monitore alertas e lide com problemas à medida que eles ocorrem.
O gráfico a seguir resume as etapas para solucionar problemas de recuperação de backup:
Todos os serviços estão em execução?
O estado da CPU está OK?
O estado da memória está OK?
O espaço livre de cache é OK?
O servidor de processo tem um batimento cardíaco?
Solucione problemas de conexão/replicação.
Solucionar problemas de restauração do Microsoft Azure Backup Server (MABS)
O Servidor de Backup do Azure foi projetado para fazer backup e restaurar cargas de trabalho, como VMs Hyper-V, Microsoft SQL Server, SharePoint Server, Microsoft Exchange e clientes Windows.
Se você tiver problemas para restaurar a partir de MABS, tente a seguinte lista de verificação de solução de problemas:
Verifique a pasta de instalação
As pastas de instalação padrão do DPM são as seguintes:
C:\Arquivos de Programas\Servidor de Backup do Microsoft Azure\DPM\DPM
Você também pode executar o seguinte comando para localizar o caminho da pasta de instalação:
Reg query "HKLM\SOFTWARE\Microsoft\Microsoft Data Protection Manager\Setup"
Credenciais de cofre inválidas
Quando você se registra em um cofre, se receber uma mensagem de erro informando que credenciais inválidas do cofre foram fornecidas, você tem um arquivo corrompido ou forneceu credenciais incorretas. Experimente o seguinte:
Transfira o ficheiro de credenciais mais recente a partir do cofre e tente novamente.
Tente baixar as credenciais para um diretório local diferente ou crie um novo cofre.
Tente atualizar as configurações de data e hora conforme descrito neste artigo.
Verifique se c:\windows\temp tem mais de 65000 ficheiros. Mova arquivos obsoletos para outro local ou exclua os itens na pasta Temp.
Verifique o estado dos certificados.
No Painel de Controlo, abra Gerir Certificados de Computador.
Expanda o nó Pessoal e seu nó filho Certificados.
Remova o certificado Ferramentas do Windows Azure.
Repita o registro no cliente de Backup do Azure.
Verifique se uma política de grupo está em vigor.
A réplica é inconsistente
No Assistente de Grupo de Proteção, verifique se a opção de verificação automática de consistência está ativada.
No caso do backup do Estado do Sistema/BMR, verifique se o Backup do Windows Server está instalado no servidor protegido.
Verifique se há problemas relacionados ao espaço no pool de armazenamento do DPM no Servidor de Backup do DPM/Microsoft Azure e aloque o armazenamento conforme necessário.
Verifique o estado do Serviço de Cópias de Sombra de Volume no servidor protegido. Se estiver em um estado desativado, configure-o para iniciar manualmente. Inicie o serviço no servidor, volte para o console do Servidor de Backup do DPM/Microsoft Azure e inicie a sincronização com o trabalho de verificação de consistência.
Falha na criação de ponto de recuperação online
Se você receber uma mensagem de erro dizendo "o Windows Azure Backup Agent não pôde criar um instantâneo do volume selecionado", tente aumentar o espaço disponível no volume do ponto de recuperação.
Se você receber uma mensagem de erro dizendo "o Windows Azure Backup Agent não pode se conectar ao serviço OBEngine", tente verificar se o OBEngine existe na lista de serviços em execução no computador. Se o serviço OBEngine não estiver em execução, use o comando "net start OBEngine" para iniciá-lo.
Se você receber uma mensagem de erro dizendo que "a senha de criptografia para este servidor não está definida. Configure uma senha de criptografia", tente configurar uma senha de criptografia. Se isso falhar, siga as seguintes etapas:
Verifique se o local do arranhão existe. Este é o local mencionado no registro HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Azure Backup\Config, onde o nome ScratchLocation deve existir.
Se o local de rascunho existir, tente registrar novamente usando a senha antiga.
Nota
Ao configurar uma senha de criptografia, salve-a sempre em um local seguro.
Solucionar problemas de cenários híbridos
Solucionar problemas de recuperação de site com o Hyper-V
Ao recuperar uma VM Hyper-V local para o Azure, use o Azure Site Recovery. Se você tiver problemas, use a seguinte lista de verificação para solucionar o problema:
Todos os seus hosts e VMs Hyper-V atendem aos requisitos e pré-requisitos para recuperação?
Verifique o link "Suporte para recuperação de desastres de VMs Hyper-V locais para o Azure" no final deste módulo.
Se os hosts Hyper-V forem gerenciados pelo Virtual Machine Manager (VMM), o servidor VMM deverá ter pelo menos uma nuvem e um ou mais grupos de hosts. Os hosts Hyper-V que executam as VMs devem estar na nuvem com mapeamento de rede entre redes VM do VMM locais e redes virtuais do Azure. Veja os links no Resumo deste módulo.
Verifique o log localizado em Logs de Aplicativos>e Serviços do Microsoft>Windows.
Na VM convidada, verifique se o WMI está habilitado e acessível.
Solucione problemas com scripts e serviços WMI.
Na VM convidada, verifique se você tem a versão mais recente do Integration Services e se ela está em execução. A Microsoft recomenda manter os serviços de integração atualizados.
Além disso, verifique as mensagens de erro comuns:
Não é possível ativar a proteção, pois a máquina virtual não está altamente disponível
Tente reiniciar o serviço do VMM na máquina do VMM. Se isso não funcionar, tente remover a máquina virtual do cluster e adicioná-la novamente.
O NTDS do gravador VSS falhou com o status 11 e o código de falha específico do gravador 0x800423F4
Para resolver esse problema, atualize para o Windows Server R2 com 4072650 aplicado. Além disso, verifique se o host Hyper-V tem o Windows 2016 ou posterior instalado.
Solucionar problemas de recuperação de sites com o VMware
Antes de restaurar uma VM VMware, verifique se ela atende aos requisitos do Azure.
Verifique as propriedades da seguinte maneira:
Em Itens Protegidos, selecione Itens Replicados e, em seguida, selecione a VM que pretende verificar.
No painel Item replicado, existe um resumo das informações, do estado de funcionamento e dos pontos de recuperação mais recentes disponíveis da VM. Selecione Propriedades.
Em Computação e Rede, você pode modificar essas propriedades conforme necessário:
Nome do Azure
Grupo de recursos
Tamanho de destino
Configurações de disco gerenciado
Você pode visualizar e modificar as configurações de rede, incluindo:
A rede e a sub-rede na qual a VM do Azure estará localizada após o failover.
O endereço IP que lhe será atribuído.
Em Discos, revise as informações do sistema operacional e os discos de dados na VM.
Para executar um failover para o Azure, em Configurações, selecione Itens replicados, selecione a VM a ser submetida a failover e selecione Failover.
Em Ativação pós-falha, selecione um Ponto de Recuperação para o qual irá realizar a ativação pós-falha. Pode utilizar uma das opções seguintes:
Mais recente: esta opção processa primeiro todos os dados enviados para o Site Recovery. Ele fornece o RPO (Recovery Point Objetive, objetivo de ponto de recuperação) mais baixo porque a VM do Azure criada após o failover tem todos os dados que foram replicados para a Recuperação de Site quando o failover foi acionado.
Último processado: esta opção faz o failover da VM para o ponto de recuperação mais recente processado pelo Site Recovery. Esta opção fornece um RTO (Recovery Time Objetive) baixo porque não é gasto tempo no processamento de dados não processados.
Aplicativo consistente mais recente: essa opção faz o failover da VM para o ponto de recuperação consistente com o aplicativo mais recente processado pelo Site Recovery.
Personalizado: esta opção permite especificar um ponto de recuperação.
Em seguida, selecione Desligar máquina antes de iniciar o failover para tentar desligar as VMs de origem antes de acionar o failover. O failover continua mesmo se o desligamento falhar. Pode acompanhar o progresso da ativação pós-falha na página Tarefas.
Em alguns cenários, o failover requer processamento adicional que leva cerca de 8 a 10 minutos para ser concluído. Você pode notar tempos de failover de teste mais longos para:
VMs VMware executando uma versão do serviço Mobility anterior à 9.8.
Servidores físicos.
VMs VMware Linux.
VMs Hyper-V protegidas como servidores físicos.
VMs VMware que não têm o serviço DHCP habilitado.
VMs VMware que não têm os seguintes drivers de inicialização: storvsc, vmbus, storflt, intelide, atapi.
Nota
Não cancele um failover em andamento. Se você cancelar um failover em andamento, a VM não será replicada novamente.
Se você tiver problemas, tente as seguintes etapas de solução de problemas:
Monitore a integridade do servidor de processo. No portal do Azure, monitore os servidores de processo para verificar se eles estão conectados e funcionando.
Verifique a conectividade entre o servidor de origem e o servidor de processo e entre o servidor de processo e o Azure.
Verifique se a máquina de origem está disponível para replicação, especificamente:
- Verifique se duas VMs não têm o mesmo UUID. Consulte Azure Site Recovery VMware-to-Azure: Como limpar entradas duplicadas ou obsoletas.
Verifique se as credenciais do vCenter estão corretas ao configurar o servidor de configuração, usando o modelo OVF ou a configuração unificada. Para verificar as credenciais, consulte Modificar credenciais para descoberta automática.
Se forem fornecidas permissões insuficientes para aceder ao vCenter, poderá ocorrer uma falha na deteção de máquinas virtuais. Certifique-se de que as permissões descritas em Preparar uma conta para descoberta automática sejam adicionadas à conta de usuário do vCenter.
Os servidores de gerenciamento não podem ser replicados. Se a VM for usada como uma ou mais das seguintes funções — servidor de configuração / servidor de processo de expansão / servidor de destino mestre —, você não poderá escolher a máquina virtual no portal.
Se a máquina virtual já estiver protegida ou tiver feito failover por meio da Recuperação de Site, ela não estará disponível para seleção para proteção no portal. Verifique se a máquina virtual ainda não está protegida por nenhum outro usuário ou sob uma assinatura diferente.
Verifique se o vCenter está no estado conectado. Para verificar, vá para Recovery Services vault Site Recovery>Infrastructure>Configuration Servers>Clique no respetivo servidor de configuração. Um painel é aberto à direita com detalhes de associ/rvers. Verifique se o vCenter está conectado. Se estiver em um estado "Não conectado", resolva o problema e atualize o servidor de configuração no portal. Depois disso, a máquina virtual será listada no portal.
Se o host ESXi sob o qual a VM reside estiver no estado desligado, a máquina virtual não será listada ou não poderá ser selecionada no portal do Azure. Ligue o host ESXi e atualize o servidor de configuração no portal. Depois disso, a máquina virtual será listada no portal.
Se houver uma reinicialização pendente, você não poderá selecionar a VM no portal do Azure. Conclua a reinicialização pendente e atualize o servidor de configuração. Em seguida, devem ser listados no portal.
Se a máquina virtual não tiver um endereço IP válido associado a ela, você não poderá selecionar a máquina no portal do Azure. Atribua um endereço IP válido à máquina virtual e atualize o servidor de configuração. Isso também pode ser causado pelo fato de a máquina não ter um endereço IP válido associado a uma de suas NICs. Atribua um endereço IP válido a todas as NICs ou remova a NIC que está faltando o IP.
Solucionar problemas de recuperação de site com o SCCM
Uma recuperação de site do System Center Configuration Manager (SCCM) é necessária se um site falhar ou se você perder dados no banco de dados do site. A recuperação do local inclui a reparação e a ressincronização dos dados.
Se você tiver problemas, tente os seguintes problemas de solução de problemas:
Verifique se as configurações anteriores não estão no servidor do site, pois isso pode causar conflitos. Remova as configurações anteriores antes de restaurar o Configuration Manager usando um dos seguintes métodos:
Restaurando para um novo servidor.
Formatar os discos e reinstalar o sistema operacional.
Limpeza de um servidor existente, incluindo a exclusão de entradas do Registro começando com SMS de HKLM\System\CurrentControlSet\Services.
Para recuperação do banco de dados do site somente antes de restaurar o Configuration Manager:
Faça backup do banco de dados do site, incluindo bancos de dados de suporte, como o WSUS.
Observe o nome do SQL Server e o nome da instância.
Exclua o banco de dados do site do SQL Server.
Reinicie o SQL Server.
Limpe um servidor existente para recuperação total antes de restaurar o Configuration Manager:
Faça backup do banco de dados do site, incluindo bancos de dados de suporte, como o WSUS.
Faça uma cópia da biblioteca de conteúdo.
Desinstale o site do Configuration Manager.
Exclua manualmente o banco de dados do site do SQL Server.
Elimine manualmente a pasta de instalação do Gestor de configuração e quaisquer outras pastas do Gestor de configuração.
Reinicie o servidor.
Restaure a biblioteca de conteúdo e outros bancos de dados, como o WSUS.
Use uma versão com suporte e a mesma edição do SQL Server:
Verifique se a versão do SQL Server tem suporte e a mesma edição do original. Há suporte para a restauração para uma versão mais recente do SQL Server, desde que você não altere a edição — você pode restaurar Standard para Standard e Enterprise para Enterprise.
Verifique se o SQL Server não está definido para o modo de usuário único.
Verifique se os arquivos MDF e LDF são válidos. Quando você recupera um site, não há verificação do estado dos arquivos.
Grupos de disponibilidade Always On do SQL Server:/
- Se você usar grupos de disponibilidade Always On do SQL Server para hospedar o banco de dados do site, modifique seus planos de recuperação conforme descrito em Preparar para usar o SQL Server Always On.
Réplicas de banco de dados:
- Depois de restaurar um banco de dados do site configurado para réplicas de banco de dados, reconfigure cada réplica. Antes de usar as réplicas do banco de dados, recrie as publicações e as assinaturas.
Solucionar problemas de recuperação site a site
O Azure to Azure Site Recovery permite replicar máquinas virtuais (VMs) do Azure de uma região para outra. Em caso de problemas, verifique o seguinte:
Taxa elevada de alteração de dados na máquina virtual de origem
O Azure Site Recovery cria um evento se a taxa de alteração de dados na máquina virtual de origem for superior aos limites suportados. Vá para Itens>replicados Eventos - de VM>duram 72 horas. Você deve ver o evento Taxa de alteração de dados além dos limites suportados:
Selecione o evento para exibir as informações do disco:
Limites do Azure Site Recovery
Os limites do Azure Site Recovery são a rotatividade de dados por disco e a rotatividade de dados por máquina virtual. Os limites reais variam de acordo com configurações específicas. Por exemplo, uma única VM Site Recovery pode lidar com 5 MB/s de rotatividade por disco e um máximo de cinco discos. A Recuperação de Site tem um limite de 54 MB/s de rotatividade total por VM.
Para descobrir se esse é um problema recorrente, verifique a taxa de alteração de dados da máquina virtual relevante em Monitoramento. Você precisará adicionar as métricas mostradas na captura de tela a seguir:
Problemas de conectividade de rede
O Site Recovery envia dados replicados para a conta de armazenamento em cache. Você pode enfrentar erros de rede se o carregamento dos dados de uma máquina virtual para a conta de armazenamento em cache for mais lento do que 4MB em três segundos.
Para verificar se há problemas de latência, use o utilitário de linha de comando AzCopy. Isso carrega dados da máquina virtual para a conta de armazenamento em cache. Se a latência for alta, verifique se você está usando um dispositivo virtual de rede (NVA) para controlar o tráfego de rede de saída de VMs. O dispositivo pode ficar limitado se todo o tráfego de replicação passar pelo NVA.
A Microsoft recomenda a criação de um ponto de extremidade de serviço de rede em sua rede virtual para "Armazenamento" para que o tráfego de replicação não vá para o NVA.
Conectividade de rede
A Recuperação de Site precisa que a VM forneça conectividade de saída para URLs ou intervalos de IP específicos. Você pode ter sua VM atrás de um firewall ou usar regras de grupo de segurança de rede (NSG) para/l conectividade de saída. Em caso afirmativo, poderá ter problemas. Verifique se todos os URLs estão conectados. Para obter mais informações, consulte Conectividade de saída para URLs.
Para obter uma lista atualizada de problemas comuns, consulte: Solucionar problemas de replicação de VMs do Azure com o Azure Site Recovery - Azure Site Recovery | Documentos Microsoft.