Perguntas gerais sobre o Azure Site Recovery

O Site Recovery contribui para sua estratégia de BCDR (continuidade de negócios e recuperação de desastre) administrando e automatizando a replicação de VMs do Azure entre regiões, máquinas virtuais locais e servidores físicos no Azure e máquinas locais em um datacenter secundário. Saiba mais.

Não, o Azure Site Recovery não dá suporte a cargas de trabalho do Docker em execução em máquinas virtuais. Para proteger essas máquinas virtuais com o Site Recovery, exclua os discos que têm o Docker instalado.

Há várias medidas adotadas pelo Site Recovery para garantir a integridade dos dados. Uma conexão segura é estabelecida entre todos os serviços usando o protocolo HTTPS. Isso garante que qualquer malware ou entidade externa não possa adulterar os dados. Outra medida tomada é usar somas de verificação. A transferência de dados entre a origem e o destino é executada por meio da computação de somas de verificação de dados entre eles. Isso garante que os dados transferidos sejam consistentes.

O Azure não dá suporte a endereços MAC persistentes e, portanto, softwares com modelos de licença baseados em MAC não podem ser usados para a migração do local para o Azure ou para a recuperação de desastres.

Não, o Azure Site Recovery atualmente não tem suporte a discos efêmeros.

O agente dos Serviços de Recuperação do Microsoft Azure é usado para configurar/registrar com os serviços do Site Recovery e para monitorar a integridade de todos os componentes. Esse componente é um dos blocos de construção básicos de toda a infraestrutura local do Azure Site Recovery. Ele ajuda a replicar suas cargas de trabalho para outra região do Azure de um site local e fazer failover para o Azure em um desastre.

Sim, o Site Recovery dá suporte aos modelos de infraestrutura dedicados e compartilhados.

Não. A identidade do locatário permanece anônima. Seus locatários não precisam acessar o Portal da Recuperação de Site. Somente o administrador do provedor de serviços interage com o portal.

Quando você está replicando para o Azure, os dados do aplicativo são enviados para o armazenamento do Azure, mas não para o serviço do Site Recovery. Os dados são criptografados em trânsito (HTTPS) e permanecem criptografados no Azure.

Não. A relação de cobrança do Azure é direta com o provedor de serviços. Os provedores de serviços são responsáveis por gerar faturas específicas para seus locatários.

Não, os dados são replicados para o armazenamento do Azure em sua assinatura. Quando você executa um failover de teste (análise de recuperação de desastre) ou um failover real, o Site Recovery cria automaticamente máquinas virtuais em sua assinatura.

Sim.

Damos suporte ao Azure Pack, ao Sistema de Plataforma de Nuvem e a implantações baseadas no System Center (2012 e posterior). Saiba mais sobre a integração do Azure Pack e da Recuperação de Site.

Não, você pode replicar máquinas virtuais do Hyper-V apenas para o Azure.

Veja os detalhes de Preços do Site Recovery.

Você pode usar a calculadora de preços para estimar os custos ao usar o Azure Site Recovery.

Para obter uma estimativa detalhada dos custos, execute a ferramenta planejadora de implantação para VMware ou Hyper-V e use o relatório de estimativa de custo.

Sim, há encargos extras para o uso da conta de armazenamento em cache ao replicar as máquinas virtuais usando o Site Recovery. Os custos da conta de armazenamento em cache permanecem os mesmos quando o armazenamento de réplica for do tipo de discos gerenciados ou discos não gerenciados.

Sim. Nenhuma instância protegida gera cobranças do Azure Site Recovery durante os primeiros 31 dias. Por exemplo, se você esteve protegendo 10 instâncias nos últimos seis meses e conectar uma 11ª instância ao Azure Site Recovery, não haverá cobranças para a 11ª instância durante os primeiros 31 dias. As primeiras 10 instâncias continuam gerando encargos do Azure Site Recovery, uma vez que elas foram protegidas por mais de 31 dias.

Sim. Entretanto, embora o Azure Site Recovery seja gratuito durante os primeiros 31 dias de uma instância protegida, você poderá ser cobrado pelo Armazenamento do Microsoft Azure, por transações de armazenamento e por transferência de dados. Uma máquina virtual recuperada também poderá gerar encargos de computação do Azure.

Não há qualquer custo separado para a análise de recuperação de desastre. Há encargos de computação após a máquina virtual ser criada após o failover de teste.

Não, o Site Recovery não intercepta dados replicados e não tem informações sobre o que está em execução nas máquinas virtuais ou nos servidores físicos. Os dados de replicação são trocados entre hosts locais do Hyper-V, hipervisores VMware ou servidores físicos e o armazenamento do Azure ou seu site secundário. O Site Recovery não tem a capacidade de interceptar os dados. Somente os metadados necessários para administrar a replicação e o failover é que são enviados para o serviço de Recuperação de Site.

O Site Recovery é certificado pela ISO 27001:2013, 27018, HIPAA, DPA e está em processo de conclusão de avaliação dos padrões SOC2 e FedRAMP JAB.

Sim. Quando você cria um cofre do Site Recovery em uma região de sua escolha, garantimos que todos os metadados de que precisamos para habilitar e administrar a replicação e o failover permaneçam dentro dos limites geográficos da região.

Para máquinas virtuais e servidores físicos que estão sendo replicados no Azure, há suporte tanto para a criptografia em trânsito quanto para a criptografia em repouso (no Azure).

Sim, o protocolo TLS 1.2 é imposto por padrão para o cenário de Azure para Azure Site Recovery.

Os agentes de mobilidade instalados nos itens replicados se comunicam com o Servidor de Processo somente no TLS 1.2. No entanto, a comunicação do Servidor de Configuração para o Azure e do Servidor de Processo para o Azure pode estar em TLS 1.1 ou 1.0. Siga as diretrizes para impor o TLS 1.2 em todos os Servidores de Configuração e Servidores de Processo configurados por você.

Toda a comunicação entre os microsserviços do Azure Site Recovery ocorre no protocolo TLS 1.2. O Site Recovery usa provedores de segurança configurados no sistema (SO) e usa o protocolo TLS mais recente disponível. É necessário habilitar explicitamente o TLS 1.2 no Registro e, em seguida, o Site Recovery começará a usar TLS 1.2 para comunicação com serviços.

Você pode alternar a identidade gerenciada do cofre dos serviços de recuperação acessando a configuração Identidade. Depois que o cofre é registrado com o Microsoft Entra ID, você pode acessar suas contas de armazenamento e fornecer as seguintes atribuições de função ao cofre:

• Contas de armazenamento baseadas no Resource Manager (tipo Standard):
  • Colaborador
  • Colaborador de dados de blob de armazenamento
• Contas de armazenamento baseadas no Resource Manager (tipo Premium):
  • Colaborador
  • Proprietário de Dados do Blob de Armazenamento
• Contas de armazenamento Clássicas:
  • Colaborador da conta de armazenamento clássica
  • Função do Serviço de Operador da Chave da Conta de Armazenamento Clássica

Não há suporte na conta de armazenamento em cache para a identidade gerenciada.

O Azure Site Recovery não controla as alterações de máquina virtual de origem fora do sistema operacional de origem. Por exemplo, se você estiver usando a replicação de Azure para Azure e alterar o tamanho da máquina virtual de origem, essa alteração não será replicada para a máquina virtual de destino.

• Máquinas virtuais do Azure: o Site Recovery pode replicar qualquer carga de trabalho em execução em uma máquina virtual do Azure com suporte.
• Máquinas virtuais do Hyper-V: o Site Recovery pode proteger qualquer carga de trabalho em execução em uma máquina virtual do Hyper-V.
• Servidores físicos: O Site Recovery pode proteger servidores físicos que executam Windows ou Linux.
• Máquinas virtuais VMware: o Site Recovery pode proteger qualquer carga de trabalho em execução em uma máquina virtual VMware.

Você pode usar o Site Recovery para proteger a maioria das cargas de trabalho em execução em uma máquina virtual ou em um servidor físico com suporte. O Site Recovery também dá suporte para a replicação com reconhecimento de aplicativo, para que os aplicativos possam ser recuperados para um estado inteligente. Ele se integra a aplicativos Microsoft, como SharePoint, Exchange, Dynamics, SQL Server e Active Directory e funciona em estreita colaboração com grandes fornecedores, como Oracle, SAP, IBM e Red Hat. Saiba mais sobre a proteção de carga de trabalho.

Sim. Ao usar o Site Recovery para administrar a replicação e o failover em suas filiais, você poderá visualizar e administrar unificadamente todas as suas cargas de trabalho corporativas em um local centralizado. Você pode executar failovers e administrar a recuperação de desastre de todas as ramificações do escritório principal facilmente, sem precisar fazer visitas locais.

Sim, o Site Recovery é compatível com desastres para máquinas virtuais do Azure entre regiões do Azure. Examine as perguntas comuns sobre a recuperação de desastre de máquina virtual do Azure. Se você quiser replicar entre duas regiões do Azure no mesmo continente, use nossa oferta de recuperação de desastre do Azure para o Azure. Não é necessário configurar o servidor de configuração/servidor de processo e as conexões de ExpressRoute.

Sim, o Site Recovery dá suporte à recuperação de desastre de máquinas virtuais VMware locais. Examine as perguntas comuns para recuperação de desastre de máquinas virtuais VMware.

Sim, o Site Recovery dá suporte à recuperação de desastre de máquinas virtuais Hyper-V locais. Examine as perguntas comuns para recuperação de desastre de máquinas virtuais Hyper-V.

Sim, o Site Recovery permite a recuperação de desastre de servidores físicos locais que executam o Windows e o Linux no Azure. Saiba mais sobre os requisitos de recuperação de desastre para Azure. Os servidores físicos são executados como máquinas virtuais no Azure após o failover. Atualmente, não há suporte para Failback do Azure para um servidor físico local. Só é possível fazer failback para uma máquina virtual VMware.

Não, o Azure Site Recovery não dá suporte à movimentação do cofre dos Serviços de Recuperação que tenha máquinas virtuais protegidas hospedadas nele.

O Azure Site Recovery replica os dados para uma Conta de Armazenamento do Azure ou em discos gerenciados em um ponto de extremidade público. No entanto, a replicação também pode ser executada via VPN de site a site. A conectividade da VPN de site a site permite que as organizações conectem redes existentes ao Azure ou a redes do Azure entre si. A VPN de site a site ocorre via túnel IPSec pela Internet, usando equipamentos de rede de borda e dispositivos de rede locais existentes no Azure, além de recursos nativos como o Gateway de VPN (Rede Virtual Privada) do Azure ou opções de terceiros, como Check Point CloudGaurd, Firewall do Palo Alto NextGen.

• Conectividade privada via Internet pública ao Microsoft Edge
• Cofres do Serviço de Recuperação configurados para segurança com pontos de extremidade privados
• Replicação via conexão de rede virtual privada do cliente
• Transição fácil para o "Estado Futuro"
• Sem SLA e latência potencialmente maior
• Requer uma disponibilidade de dispositivo VPN local

Nosso parceiro, Riverbed, mostra orientações detalhadas sobre como trabalhar com Azure Site Recovery. Examine o guia de solução.

Sim, o ExpressRoute pode ser usado para replicar máquinas virtuais locais no Azure.

• O Azure Site Recovery replica os dados para um Armazenamento do Microsoft Azure em um ponto de extremidade público. Você precisa configurar o emparelhamento da Microsoft para que ele use o ExpressRoute para a replicação do Site Recovery.
• Só há suporte para a replicação no emparelhamento privado quando os pontos de extremidade privados são habilitados para o cofre.
• Se você estiver protegendo computadores VMware ou máquinas físicas, verifique se os Requisitos de Rede para o Servidor de Configuração também são atendidos. A conectividade com URLs específicas é exigida pelo Servidor de Configuração para orquestração da replicação do Site Recovery. O ExpressRoute não pode ser usado para essa conectividade.
• Após o failover das máquinas virtuais para uma rede virtual do Azure, é possível acessá-las usando a configuração de emparelhamento privado com a rede virtual do Azure.

Não há suporte para o uso de contas de armazenamento como armazenamento de destino pelo Azure Site Recovery. Em vez disso, é recomendável usar discos gerenciados como o armazenamento de destino para seus computadores. Os discos gerenciados dão suporte apenas ao tipo LRS para resiliência de dados.

• Hyper-V: as máquinas virtuais do Hyper-V podem ser replicadas a cada 30 segundos (exceto no armazenamento premium) ou 5 minutos.
• Máquinas virtuais do Azure, máquinas virtuais VMware e servidores físicos: não é relevante estabelecer uma frequência de replicação aqui. A replicação é contínua.

Esse tipo de replicação estendida ou encadeada não tem suporte. Solicite esse recurso no fórum de comentários.

Não há suporte para isso. Solicite esse recurso no fórum de comentários.

Haverá suporte para isso quando você estiver replicando as máquinas virtuais VMware e as máquinas virtuais do Hyper-V no Azure usando o portal do Azure.

Discos dinâmicos são compatíveis ao replicar máquinas virtuais Hyper-V e ao replicar máquinas virtuais VMware e máquinas físicas para o Azure. O disco do sistema operacional deve ser um disco básico.

Sim. Você pode ler mais sobre a limitação de largura de banda nos artigos:

• Planejamento de capacidade para a replicação de máquinas virtuais VMware e servidores físicos
• Planejamento de capacidade para a replicação de Hyper-V para o Azure

Sim. O Azure Site Recovery para o sistema operacional Linux oferece suporte a scripts personalizados de aplicativo para consistência de aplicativo. As opções de scripts prévios e posteriores são usadas pelo Agente de Mobilidade do Azure Site Recovery para consistência do aplicativo. A seguir estão as etapas para habilitá-lo.

1. Entre como raiz no computador.

2. Altere o diretório para o local de instalação do agente de mobilidade do Azure Site Recovery. O padrão é "/usr/local/ASR"
   # cd /usr/local/ASR

3. Altere o diretório para "VX/scripts" no local de instalação
   # cd VX/scripts

4. Crie um script de shell bash chamado "customscript.sh" com permissões de execução para o usuário raiz.
   a. O script deve dar suporte às opções de linha de comando "--pre" e "--post" (observe os traços duplos)
   b. Quando o script é chamado com a opção pre, ele deve congelar a entrada/saída do aplicativo e, quando chamado com a opção post, ele deve descongelar a entrada/saída do aplicativo.
   c. Um modelo de exemplo -
   

   # cat customscript.sh
   

    #!/bin/bash

    if [ $# -ne 1 ]; then
        echo "Usage: $0 [--pre | --post]"
        exit 1
    elif [ "$1" == "--pre" ]; then
        echo "Freezing app IO"
        exit 0
    elif [ "$1" == "--post" ]; then
        echo "Thawed app IO"
        exit 0
    fi

5. Adicione os comandos congelar e descongelar entrada/saída nas etapas anteriores e posteriores para os aplicativos que exigem consistência de aplicativo. Você pode optar por adicionar outro script especificando aqueles e chamá-lo de "customscript.sh" com as opções pre e post.

Uma política de replicação define as configurações para o histórico de retenção dos pontos de recuperação. A política também define a frequência de instantâneos consistentes em termos de aplicativo. Por padrão, o Azure Site Recovery cria uma nova política de replicação com configurações padrão de:

• Um dia para o histórico de retenção de pontos de recuperação.
• Nenhum instantâneo consistente com aplicativos.

Um ponto de recuperação consistente em termos de falhas tem os dados em disco como se você tivesse recebido o cabo de alimentação do servidor durante o instantâneo. Ele não inclui o que estava na memória quando o instantâneo foi tirado.

Atualmente, a maioria dos aplicativos pode recuperar-se bem de instantâneos consistente em termos de falha. Um ponto de recuperação consistente com falhas é suficiente para sistemas operacionais sem banco de dados e aplicativos como servidores de aquivos, servidores DHCP e servidores de impressão.

O Site Recovery cria um ponto de recuperação consistente em termos de falha a cada 5 minutos.

Pontos de recuperação consistentes em termos de aplicativo são criados com base em instantâneos consistentes em termos de aplicativo. Pontos de recuperação consistentes em termos de aplicativo capturam os mesmos dados de instantâneos consistentes em termos de falhas, além de todos os dados na memória e todas as transações em andamento.

Devido a seu conteúdo adicional, instantâneos de aplicativo consistente são os mais envolvidos e levam mais tempo para executar. Recomendamos pontos de recuperação consistentes em termos de aplicativo para sistemas operacionais de banco de dados como o SQL Server.

Os pontos de recuperação consistentes com o aplicativo capturam todos os dados na memória e em processamento. Como os pontos de recuperação capturam esses dados, eles exigem estruturas como o Serviço de Cópias de Sombra de Volume no Windows para desativar o aplicativo. Se o processo de captura for frequente, poderá afetar o desempenho quando a carga de trabalho já estiver ocupada. Não é recomendável usar a frequência baixa para pontos de recuperação consistentes com o aplicativo em cargas de trabalho que não são de banco de dados. Mesmo para a carga de trabalho do banco de dados, 1 hora é suficiente.

O Site Recovery pode criar um ponto de recuperação consistente com o aplicativo com frequência mínima de 1 hora.

Para entender como Site Recovery gera pontos de recuperação, veja um exemplo de uma política de replicação. Esta política de replicação tem um ponto de recuperação com uma janela de retenção de 1 dia e um instantâneo de frequência consistente com aplicativos de 1 hora.

O Site Recovery cria um ponto de recuperação consistente em termos de falha a cada 5 minutos. Você não pode alterar essa frequência. Nas 2 horas mais recentes, você pode escolher entre 24 pontos consistentes com falhas e 2 pontos consistentes com aplicativos. À medida que o tempo avança, o Site Recovery remove todos os pontos de recuperação além das últimas 2 horas e salva apenas 24 ponto de recuperação por hora por até 24 horas do dia.

A captura de tela a seguir ilustra o exemplo. Na captura de tela:

• Nas últimas 2 horas, há pontos de recuperação com uma frequência de 5 minutos.

• Além das últimas 2 horas, o Site Recovery mantém apenas 1 ponto de recuperação por hora.

  

O ponto de recuperação mais antigo que você pode usar é 15 dias com disco gerenciado e três dias com disco não gerenciado.

Não, o Site Recovery manterá todos os pontos de recuperação anteriores. Dependendo da janela de retenção dos pontos de recuperação, o Site Recovery substituirá o ponto mais antigo somente se ele gerar novos pontos. Devido ao problema, o Site Recovery não pode gerar novos pontos de recuperação. Até que haja novos pontos de recuperação, todos os pontos antigos permanecem depois que você chegar à janela de retenção.

Vá para Cofre do Site Recovery>Infraestrutura do Site Recovery>Políticas de replicação. Selecione a política que você deseja editar e salve as alterações. Qualquer alteração também será aplicada a todas as replicações existentes.

O primeiro ponto de recuperação gerado tem a cópia completa. Os pontos de recuperação sucessivos têm alterações delta.

Sim, se você aumentar o período de retenção de 1 dia para 3 dias, o Site Recovery salva os pontos de recuperação por mais 2 dias. O tempo adicionado gera encargos de armazenamento, pois haverá 12 pontos de recuperação adicionais que precisarão ser salvos com aumento no período de retenção de 1 dia a 3 dias. Por exemplo, um ponto de recuperação pode ter alterações delta de 10 GB com um custo por GB de US$ 0,16 por mês. Os encargos adicionais seriam de USD 1,60 × 12 por mês.

Você pode acessar as máquinas virtuais do Azure em uma conexão segura da Internet, em uma VPN site a site ou na Azure ExpressRoute. Você precisa preparar uma série de coisas para se conectar. Saiba mais.

O Azure foi desenvolvido para resiliência. O Site Recovery já foi projetado para failover em um datacenter do Azure secundário, de acordo com o SLA do Azure. Se isso acontecer, faremos com que seus metadados e cofres permaneçam na mesma região geográfica que você escolheu para o cofre.

Você pode disparar um failover não planejado do site secundário. O Site Recovery não precisa de conectividade do local primário para fazer o failover.

O failover não é automático. Você pode iniciar failovers com um único clique no portal ou pode usar o PowerShell do Site Recovery para disparar um failover. O failback é uma ação simples no portal do Site Recovery.

Para automatizar, você pode usar o Orchestrator ou o Operations Manager local para detectar a falha da máquina virtual e disparar o failover usando o SDK.

• Leia mais sobre planos de recuperação.
• Saiba mais sobre failover.
• Saiba mais como realizar failback das máquinas virtuais VMware e servidores físicos

Sim, você pode usar a recuperação em uma localização alternativa para fazer failback para um host diferente do Azure.

• Para máquinas virtuais VMware
• Para máquinas virtuais Hyper-V

Após o failover de um computador do local de origem para o local de destino, há três opções disponíveis para sua escolha. Todos os três servem para diferentes finalidades -

1. Migração completa significa que você não voltará mais para o local de origem. Você migrou para a região de destino e agora está feito. Clicar em Concluir Migração dispara a confirmação e, em seguida, desabilita a replicação internamente.
2. Confirmar não significa que esse é o fim do processo de replicação. O item de replicação junto com todas as configurações permanecerá, e você poderá clicar em Proteger Novamente em um momento posterior para habilitar a replicação de seus computadores de volta para a região de origem.
3. Desabilitar Replicação desabilitará a replicação e removerá todas as configurações relacionadas. A máquina já existente na região de destino não será afetada.

Sim. Você pode automatizar fluxos de trabalho do Site Recovery usando a API REST, o PowerShell ou o SDK do Azure. Cenários com suporte no momento para implantar a Recuperação de Site usando o PowerShell:

• Replicar máquinas virtuais Hyper-V em nuvens VMM para o Azure PowerShell do Resource Manager
• Replicar máquinas virtuais Hyper-V sem VMM para o Azure PowerShell do Resource Manager
• Replicar o VMware no Azure com o Gerenciador de Recursos do PowerShell

Não, a desativação do módulo AzureRM não afeta como as atualizações automáticas do Site Recovery funcionam. Nenhuma alteração é necessária para o runbook interno e a API REST usada em vigor continua funcionando conforme o esperado com a conta de automação.

Saiba mais sobre novas atualizações e informações de rollup.

Próximas etapas

• Leia a visão geral do Site Recovery