Partilhar via


Solucionar problemas de backup lento de arquivos e pastas no Backup do Azure

Este artigo fornece orientações de solução de problemas para ajudá-lo a diagnosticar a causa do desempenho lento do backup de arquivos e pastas quando você estiver usando o Backup do Azure. Quando você usa o agente de Backup do Azure para fazer backup de arquivos, o processo de backup pode levar mais tempo do que o esperado. Esse atraso pode ser causado por um ou mais dos seguintes fatores:

Antes de começar a solucionar problemas, recomendamos que você baixe e instale o agente de Backup do Azure mais recente. Fazemos atualizações frequentes no agente de backup para corrigir vários problemas, adicionar recursos e melhorar o desempenho.

Também recomendamos vivamente que reveja as Perguntas frequentes sobre o serviço de Backup do Azure para se certificar de que não está a ter nenhum dos problemas de configuração comuns.

Se o seu problema do Azure não for resolvido neste artigo, visite os fóruns do Azure em Microsoft Q & A e Stack Overflow. Você pode postar seu problema nesses fóruns ou postar para @AzureSupport no Twitter. Você também pode enviar uma solicitação de suporte do Azure. Para enviar uma solicitação de suporte, na página de suporte do Azure, selecione Obter suporte.

Causa: trabalho de backup em execução no modo não otimizado

  • O agente MARS pode executar o trabalho de backup no modo otimizado usando USN (número de sequência de atualização), diário de alterações ou modo não otimizado, verificando alterações em diretórios ou arquivos verificando todo o volume.

  • O modo não otimizado é lento porque o agente tem que verificar cada arquivo no volume e comparar com os metadados para determinar os arquivos alterados.

  • Para verificar isso, abra Detalhes do trabalho no console do agente MARS e verifique o status para ver se ele diz Transferência de dados (não otimizada, pode levar mais tempo), conforme mostrado abaixo:

    A captura de tela mostra trabalhos de backup em execução no modo não otimizado.

  • As seguintes condições podem fazer com que a tarefa de backup seja executada no modo não otimizado:

    • O primeiro backup (também conhecido como Replicação Inicial) sempre será executado no modo não otimizado
    • Se o trabalho de backup anterior falhar, o próximo trabalho de backup agendado será executado como não otimizado.

Causa: afunilamentos de desempenho no computador

Os gargalos no computador do qual está sendo feito backup podem causar atrasos. Por exemplo, a capacidade do computador de ler ou gravar em disco, ou a largura de banda disponível para enviar dados pela rede, pode causar gargalos.

O Windows fornece uma ferramenta interna chamada Monitor de Desempenho (Perfmon) para detetar esses gargalos.

Aqui estão alguns contadores de desempenho e intervalos que podem ser úteis no diagnóstico de gargalos para backups otimizados.

Contador Situação
Disco lógico(disco físico)--%idle
  • 100% inativo a 50% inativo = Saudável
  • 49% ocioso a 20% ocioso = Aviso ou Monitor
  • 19% inativo a 0% inativo = Crítico ou Fora das especificações
  • Disco lógico(disco físico)--%Avg. Disco Sec Leitura ou Gravação
  • 0,001 ms a 0,015 ms = Saudável
  • 0,015 ms a 0,025 ms = Aviso ou Monitor
  • 0,026 ms ou mais = Crítico ou Fora das especificações
  • Disco Lógico (Disco Físico) -- Comprimento Atual da Fila de Disco (para todas as instâncias) 80 pedidos durante mais de 6 minutos
    Pool de memória--bytes não paginados
  • Menos de 60% de piscina consumida = Saudável
  • 61% a 80% de piscina consumida = Aviso ou Monitor
  • Maior que 80% pool consumido = Crítico ou Fora da Especificação
  • Memória--Pool Paged Bytes
  • Menos de 60% de piscina consumida = Saudável
  • 61% a 80% de piscina consumida = Aviso ou Monitor
  • Quando maior que 80% do pool é consumido, a situação é Crítica ou Fora das Especificações.
  • Memória--Megabytes disponíveis
  • 50% de memória livre disponível ou mais = Saudável
  • 25% de memória livre = Monitor
  • 10% de memória livre disponível = Aviso
  • Menos de 100 MB ou 5% de memória livre disponível = Crítica ou Fora das especificações
  • Processador-- Tempo de%Processor (todas as instâncias)
  • Menos de 60% consumidos = Saudável
  • 61% a 90% consumidos = Monitor ou Precaução
  • 91% a 100% consumidos = Crítico
  • Observação

    Se você determinar que a infraestrutura é a culpada, recomendamos que desfragmente os discos regularmente para obter um melhor desempenho.

    Causa: outro processo ou software antivírus que interfere com o Backup do Azure

    Vimos vários casos em que outros processos no sistema Windows afetaram negativamente o desempenho do processo do agente de Backup do Azure. Por exemplo, se você usar o agente do Backup do Azure e outro programa para fazer backup de dados, ou se o software antivírus estiver em execução e tiver um bloqueio nos arquivos para backup, os vários bloqueios nos arquivos poderão causar contenção. Nessa situação, o backup pode falhar ou o trabalho pode levar mais tempo do que o esperado.

    A melhor recomendação neste cenário é desativar o outro programa de backup para ver se o tempo de backup para o agente de Backup do Azure muda. Normalmente, certificar-se de que vários trabalhos de backup não estão sendo executados ao mesmo tempo é suficiente para evitar que eles afetem uns aos outros.

    Se tiver software antivírus instalado no servidor, adicione as regras de exclusão à verificação antivírus para:

    • Todos os arquivos e pastas nas localizações das pastas scratch e bin - <InstallPath>\Scratch\* e <InstallPath>\Bin\*.
    • cbengine.exe

    Causa: agente de backup em execução em uma máquina virtual do Azure

    Se você estiver executando o agente de backup em uma VM, o desempenho será mais lento do que quando você executá-lo em uma máquina física. Isto é esperado devido a limitações de IOPS. No entanto, você pode otimizar o desempenho alternando as unidades de dados cujo backup está sendo feito para o Armazenamento Premium do Azure. Estamos trabalhando para corrigir esse problema, e a correção estará disponível em uma versão futura.

    Causa: Fazer backup de um grande número (milhões) de arquivos

    Mover um grande volume de dados levará mais tempo do que mover um volume menor de dados. Em alguns casos, o tempo de backup está relacionado não apenas ao tamanho dos dados, mas também ao número de arquivos ou pastas. Isso é especialmente verdadeiro quando milhões de arquivos pequenos (alguns bytes a alguns kilobytes) estão a ser copiados em cópias de segurança.

    Esse comportamento ocorre porque enquanto você está fazendo backup dos dados e movendo-os para o Azure, o Azure está catalogando simultaneamente seus arquivos. Em alguns cenários raros, a operação de catálogo pode levar mais tempo do que o esperado.

    Os indicadores a seguir podem ajudá-lo a entender o gargalo e, consequentemente, trabalhar nas próximas etapas:

    • A interface do usuário está mostrando o progresso para a transferência de dados. Os dados ainda estão a ser transferidos. A largura de banda da rede ou o tamanho dos dados podem estar causando atrasos.
    • A interface do usuário não está mostrando o progresso da transferência de dados. Abra os logs localizados em C:\Arquivos de Programas\Microsoft Azure Recovery Services Agent\Temp e verifique a entrada FileProvider::EndData nos logs. Esta entrada significa que a transferência de dados terminou e a operação de catálogo está acontecendo. Não cancele os trabalhos de backup. Em vez disso, aguarde um pouco mais até que a operação de catálogo seja concluída. Se o problema persistir, entre em contato com o suporte do Azure.

    Se você estiver tentando fazer backup de discos grandes, é recomendável usar o Azure Data Box para o primeiro backup (Replicação Inicial). Se você não puder usar o Data Box, quaisquer problemas de rede transitórios que aconteçam em seu ambiente durante longas transferências de dados pela rede podem causar falhas de backup. Para se proteger contra essas falhas, você pode adicionar algumas pastas ao seu backup inicial e continuar adicionando incrementalmente mais pastas até que todas as pastas sejam copiadas com êxito no Azure. Os backups incrementais subsequentes serão relativamente mais rápidos.

    Próximos passos