Perguntas gerais sobre o Azure Site Recovery

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

Não, o Azure Site Recovery não suporta 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 nelas.

Existem várias medidas tomadas 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 entidades externas não possam adulterar os dados. Outra medida tomada é o uso de cheques. A transferência de dados entre a origem e o destino é executada através do cálculo de somas de verificação de dados entre eles. Isso garante que os dados transferidos sejam consistentes.

O Azure não suporta endereços MAC persistentes e, portanto, o software com modelos de licença baseados em MAC não pode ser usado para migração local para o Azure ou recuperação de desastres.

Não, o Azure Site Recovery atualmente não oferece suporte a Discos Efémeros.

O agente dos Serviços de Recuperação do Microsoft Azure é usado para configurar/registrar com serviços de Recuperação de Site e para monitorar a integridade de todos os componentes. Este 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 a partir de um site local e fazer failover para o Azure em um desastre.

Sim, a Recuperação de Sites suporta os modelos de infraestrutura partilhados e dedicados.

N.º A identidade do inquilino permanece anónima. Os seus inquilinos não precisam de acesso ao portal de recuperação de Recuperação de Sites. Apenas o administrador do fornecedor 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 de Recuperação de Site. Os dados são criptografados em trânsito (HTTPS) e permanecem criptografados no Azure.

N.º A relação de faturação do Azure é diretamente com o fornecedor de serviços. Os fornecedores de serviços são responsáveis por gerar faturas específicas para os seus inquilinos.

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

Sim.

Suportamos implementações baseadas no Azure Pack, Cloud Platform System e System Center (2012 e superior). Saiba mais sobre a integração do Azure Pack e do Site Recovery.

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

Analise os detalhes de preços do Site Recovery.

Pode utilizar a calculadora de preços para fazer uma estimativa dos custos durante a utilização do Site Recovery.

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

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

Sim. As instâncias protegidas não incorrem em custos do Azure Site Recovery nos primeiros 31 dias. Por exemplo, se você estiver 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 nos primeiros 31 dias. As primeiras 10 instâncias continuam a incorrer em custos do Azure Site Recovery, uma vez que estão protegidas há mais de 31 dias.

Sim, embora o Site Recovery seja gratuito durante os primeiros 31 dias de uma instância protegida, poderá incorrer em custos para o Armazenamento do Microsoft Azure, transações de armazenamento e transferência de dados. Uma máquina virtual recuperada também pode incorrer em custos de computação do Azure.

Não há nenhum custo separado para o drill de recuperação de desastres. Há cobranças de computação depois que a máquina virtual é criada após o failover de teste.

Não, o Site Recovery não interceta dados replicados e não tem informações sobre o que está sendo executado em suas máquinas virtuais ou servidores físicos. Os dados de replicação são trocados entre os anfitriões Hyper-V no local, os hipervisores VMware ou os servidores físicos, e o armazenamento do Azure ou o seu site secundário. A Recuperação de Sites não tem capacidade para intercetar esses dados. Apenas os metadados necessários para orquestrar a replicação e a ativação pós-falha são enviados para o serviço de Recuperação de Sites.

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

Sim. Quando você cria um cofre de Recuperação de Site em uma região, garantimos que todos os metadados necessários para habilitar e orquestrar a replicação e o failover permaneçam dentro dos limites geográficos dessa região.

Para máquinas virtuais e servidores físicos replicando para o Azure, há suporte para criptografia em trânsito e criptografia em repouso (no Azure).

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

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

Toda a comunicação entre os microsserviços do Azure Site Recovery acontece 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 o TLS 1.2 para comunicação com serviços.

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

• Contas de armazenamento baseadas no Resource Manager (Tipo padrão):
  • Contribuinte
  • Contribuidor de Dados de Blobs de Armazenamento
• Contas de armazenamento baseadas no Resource Manager (Tipo Premium):
  • Contribuinte
  • Proprietário dos Dados do Armazenamento de Blobs
• Contas de armazenamento clássicas:
  • Colaborador da Conta de Armazenamento Clássica
  • Função de Serviço de Operador de Chave da Conta de Armazenamento Clássica

A conta de armazenamento em cache não é suportada para identidade gerenciada.

O Azure Site Recovery não controla as alterações da máquina virtual de origem fora do SO de origem. Por exemplo, se você estiver usando o Azure para replicação do Azure e alterar o tamanho da máquina virtual de origem, a alteração no tamanho da máquina virtual de origem 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 Hyper-V: a Recuperação de Site pode proteger qualquer carga de trabalho em execução em uma máquina virtual 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 a Recuperação de Site para proteger a maioria das cargas de trabalho em execução em uma máquina virtual ou servidor físico suportado. O Site Recovery fornece suporte para replicação com reconhecimento de aplicativos, para que os aplicativos possam ser recuperados para um estado inteligente. Ele se integra a aplicativos da Microsoft, como SharePoint, Exchange, Dynamics, SQL Server e Ative Directory, e trabalha em estreita colaboração com os principais fornecedores, incluindo Oracle, SAP, IBM e Red Hat. Saiba mais sobre proteção de carga de trabalho.

Sim. Ao usar a Recuperação de Site para orquestrar a replicação e o failover em suas filiais, você terá uma orquestração unificada e uma visão de todas as cargas de trabalho da filial em um local central. Pode facilmente executar as ativações pós-falha e administrar a recuperação após desastre de todas as sucursais a partir da sede, sem visitar as sucursais.

Sim, o Site Recovery dá suporte a desastres para máquinas virtuais do Azure entre regiões do Azure. Analise as perguntas comuns sobre a recuperação de desastres da 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 desastres do Azure to Azure. Não há necessidade de configurar o servidor de configuração/servidor de processo e conexões ExpressRoute.

Sim, o Site Recovery oferece suporte à recuperação de desastres de máquinas virtuais VMware locais. Analise as perguntas comuns sobre recuperação de desastres de máquinas virtuais VMware.

Sim, a Recuperação de Site oferece suporte à recuperação de desastres de máquinas virtuais Hyper-V locais. Analise as perguntas comuns sobre recuperação de desastres de máquinas virtuais Hyper-V.

Sim, o Site Recovery dá suporte à recuperação de desastres de servidores físicos locais que executam Windows e Linux no Azure. Saiba mais sobre os requisitos de recuperação de desastres para o 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. Você só pode fazer failover para uma máquina virtual VMware.

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

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

• Conectividade privada através da Internet pública para o Microsoft Edge
• Cofres de Serviço de Recuperação configurados para segurança com Pontos de Extremidade Privados
• Replicação através da ligação de Rede Virtual privada do cliente
• Transição fácil para o "Estado do Futuro"
• Sem SLA e latência potencialmente maior
• Requer disponibilidade de um dispositivo VPN local

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

Sim, a Rota Expressa pode ser usada para replicar máquinas virtuais locais para o Azure.

• O Azure Site Recovery replica dados para um Armazenamento do Azure através de um ponto de extremidade público. Você precisa configurar o emparelhamento da Microsoft ou usar um emparelhamento público existente (preterido para novos circuitos) para usar a replicação do ExpressRoute for Site Recovery.
• O emparelhamento da Microsoft é o domínio de roteamento recomendado para replicação.
• A replicação é suportada no emparelhamento privado somente quando os pontos de extremidade privados estão habilitados para o cofre.
• Se você estiver protegendo máquinas VMware ou máquinas físicas, certifique-se de que os requisitos de rede para o Configuration Server também sejam atendidos. A conectividade com URLs específicas é exigida pelo Servidor de Configuração para orquestração da replicação do Site Recovery. A Rota Expressa não pode ser usada para essa conectividade.
• Depois que as máquinas virtuais tiverem sido submetidas a failover para uma rede virtual do Azure, você poderá acessá-las usando a configuração de emparelhamento privado com a rede virtual do Azure.

O uso de contas de armazenamento como armazenamento de destino não é suportado pelo Azure Site Recovery. Recomenda-se usar discos gerenciados como o armazenamento de destino para suas máquinas. Os discos gerenciados suportam apenas o tipo LRS para resiliência de dados.

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

Não é suportada a replicação expandida ou em cadeia. Solicite este recurso no fórum de comentários.

Isto não é suportado. Solicite esse recurso no fórum de comentários.

Isso é suportado quando você está replicando máquinas virtuais VMware e máquinas virtuais Hyper-V para o Azure, usando o portal do Azure.

Há suporte para discos dinâmicos 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 como limitar a largura de banda nestes artigos:

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

Sim. O Azure Site Recovery for Linux Operation System dá suporte a scripts personalizados de aplicativos para consistência de aplicativos. O script personalizado com pré e pós-opções é usado pelo Agente de Mobilidade do Azure Site Recovery durante a consistência do aplicativo. A seguir estão as etapas para habilitá-lo.

1. Inicie sessão como root na máquina.

2. Altere o diretório para o local de instalação do Azure Site Recovery Mobility Agent. 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 shell bash chamado "customscript.sh" com permissões de execução para o usuário root.
   a. O script deve suportar as opções de linha de comando "--pre" e "--post" (observe os traços duplos)
   b. Quando o script é chamado com pré-opção, ele deve congelar a entrada/saída do aplicativo e, quando chamado com pós-opção, 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 em pré e pós-etapas para os aplicativos que exigem consistência de aplicativo. Você pode optar por adicionar outro script especificando-os e invocá-lo a partir de "customscript.sh" com pré e pós-opções.

Uma política de replicação define as configurações para o histórico de retenção de pontos de recuperação. A política também define a frequência de instantâneos consistentes com o 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.
• Sem instantâneos consistentes com o aplicativo.

Um ponto de recuperação consistente com falhas tem os dados no disco como se você puxasse o cabo de alimentação do servidor durante o snapshot. O ponto de recuperação consistente com falhas não inclui nada que estava na memória quando o instantâneo foi tirado.

Atualmente, a maioria dos aplicativos pode se recuperar bem de snapshots consistentes com falhas. Um ponto de recuperação consistente com falhas é suficiente para sistemas operacionais sem banco de dados e aplicativos como servidores de arquivos, servidores DHCP e servidores de impressão.

O Site Recovery cria um ponto de recuperação consistente com falhas a cada 5 minutos.

Os pontos de recuperação consistentes com o aplicativo são criados a partir de snapshots consistentes com o aplicativo. Os pontos de recuperação consistentes com aplicativos capturam os mesmos dados que instantâneos consistentes com falhas e, ao mesmo tempo, capturam dados na memória e todas as transações em processo.

Devido ao seu conteúdo extra, os snapshots consistentes com aplicativos são os mais envolvidos e levam mais tempo. Recomendamos pontos de recuperação consistentes com aplicativos para sistemas operacionais de banco de dados e aplicativos como o SQL Server.

Os pontos de recuperação consistentes com o aplicativo capturam todos os dados na memória e no processo. Como os pontos de recuperação capturam esses dados, eles exigem uma estrutura como o Serviço de Cópias de Sombra de Volume no Windows para desativar o aplicativo. Se o processo de captura for frequente, pode afetar o desempenho quando a carga de trabalho já estiver ocupada. Não recomendamos que você use baixa frequência para pontos de recuperação consistentes com aplicativos para cargas de trabalho que não sejam 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 uma frequência mínima de 1 hora.

Para entender como a Recuperação de Site gera pontos de recuperação, vejamos um exemplo de uma política de replicação. Essa 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 o aplicativo de 1 hora.

O Site Recovery cria um ponto de recuperação consistente com falhas a cada 5 minutos. Não é possível 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 elimina todos os pontos de recuperação além das últimas 2 horas e salva apenas um 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, existem pontos de recuperação com uma frequência de 5 minutos.

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

  

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

Não, o Site Recovery mantém todos os seus pontos de recuperação anteriores. Dependendo da janela de retenção dos pontos de recuperação, a Recuperação de Site substitui 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 de atingir a janela de retenção.

Vá para Políticas de replicação de infraestrutura de recuperação de site do Site Recovery Vault>>. Selecione a política que deseja editar e salve as alterações. Qualquer alteração também se aplica a todas as replicações existentes.

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

Sim, se você aumentar o período de retenção de um dia para três dias, o Site Recovery salvará os pontos de recuperação por mais dois dias. O tempo adicional incorrerá em encargos de armazenamento, uma vez que haverá 12 pontos de recuperação adicionais que precisam ser salvos com aumento no período de retenção de um dia para três dias. Por exemplo, um único 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 US $ 1,60 × 12 por mês.

Pode aceder às máquinas virtuais do Azure através de uma ligação segura à Internet, através de uma VPN site a site ou através da Rota Expressa do Azure. Você precisa preparar uma série de coisas para se conectar. Mais informações.

O Azure foi concebido para ser resiliente. O Site Recovery já foi projetado para failover para um datacenter secundário do Azure, de acordo com o SLA do Azure. Se isso acontecer, certificamo-nos de que os seus metadados e cofres permanecem na mesma região geográfica que escolheu para o seu cofre.

Pode acionar uma ativação pós-falha não planeada do site secundário. A Recuperação de Sites não necessita de conectividade do site primário para efetuar a ativação pós-falha.

A ativação pós-falha não é automática. Você inicia failovers com um único clique no portal ou pode usar o PowerShell de Recuperação de Site para disparar um failover. Fazer failback é uma ação simples no portal de Recuperação de Site.

Para automatizar, você pode usar o Orchestrator ou o Operations Manager local para detetar uma falha de máquina virtual e, em seguida, disparar o failover usando o SDK.

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

Sim, você pode usar a recuperação de local alternativo para failback para um host diferente do Azure.

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

Depois que uma máquina do local de origem tiver sido transferida para o local de destino, há três opções disponíveis para você escolher. Todos os três servem propósitos diferentes -

1. A Migração Completa significa que você não voltará mais ao local de origem. Você migrou para a região de destino e agora terminou. Clicar em Concluir migração aciona Confirmar e, em seguida, Desativar replicação, internamente.
2. Confirmar significa que este não é o fim do seu processo de replicação. O item de replicação, juntamente com toda a configuração, permanecerá, e você poderá pressionar Reproteger em um momento posterior para habilitar a replicação de suas máquinas de volta para a região de origem.
3. Desabilitar replicação desabilitará a replicação e removerá toda a configuração relacionada. Isso não afetará a máquina já existente na região de destino.

Sim. Você pode automatizar fluxos de trabalho do Site Recovery usando a API REST, o PowerShell ou o SDK do Azure. Cenários atualmente suportados para implementação do Site Recovery com o PowerShell:

• Replicar máquinas virtuais Hyper-V em nuvens VMMs para o Azure PowerShell Resource Manager
• Replicar máquinas virtuais Hyper-V sem VMM para o Azure PowerShell Resource Manager
• Replicar o VMware para o Azure com o PowerShell Resource Manager

Não, a desativação do módulo AzureRM não afeta o funcionamento das atualizações automáticas do Site Recovery. Nenhuma alteração é necessária para o runbook interno, e a API REST usada no local continua a funcionar como pretendido com a conta de automação.

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

Próximos passos

• Leia a Descrição geral da Recuperação de Sites