Confiabilidade no Backup do Azure

Backup do Azure é um serviço de Azure interno que protege com segurança cargas de trabalho locais e de nuvem. Backup do Azure pode dimensionar perfeitamente sua proteção em várias cargas de trabalho e fornece integração nativa com as cargas de trabalho em Azure, incluindo máquinas virtuais (VMs), SAP HANA em VMs Azure, SQL em VMs Azure, Arquivos do Azure, Azure Blob, Azure Data Lake, discos, Volumes Elásticos SAN, AKS e muito mais. Você não precisa gerenciar a automação ou a infraestrutura. Não é necessário gravar scripts ou provisionar armazenamento.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar suporte à resiliência e recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como Backup do Azure podem ser resilientes a uma variedade de possíveis interrupções e problemas, incluindo falhas transitórias, interrupções de zona de disponibilidade e interrupções de região. Ele também destaca algumas informações importantes sobre o SLA (contrato de nível de serviço) Backup do Azure.

Recomendações de implantação de produção para confiabilidade

Para o backup de seus workloads de produção, recomendamos que você configure seu repositório da seguinte maneira:

As seções restantes deste artigo fornecem mais detalhes sobre essas configurações.

Para obter uma lista de outras recomendações para Backup do Azure, incluindo recomendações focadas em confiabilidade, consulte Backup cloud e cargas de trabalho locais para a nuvem.

Visão geral da arquitetura de confiabilidade

Esta seção descreve alguns dos aspectos importantes de como o serviço funciona que são mais relevantes do ponto de vista da confiabilidade. A seção apresenta a arquitetura lógica, que inclui alguns dos recursos e recursos que você implanta e usa. Também discute a arquitetura física, que fornece detalhes sobre como o serviço funciona nos bastidores.

Arquitetura lógica

Backup do Azure pode fazer backup e restaurar uma variedade de datasources. Você configura backups de forma diferente dependendo da fonte de dados com a qual você está trabalhando. As fontes de dados comuns incluem:

• Azure máquinas virtuais (VMs)
• Vários bancos de dados
• contas de Azure Blob
• Clusters do AKS
• Servidores locais por meio do agente dos Serviços de Recuperação de Microsoft Azure (MARS)

Backup do Azure armazena seus dados de backup em vaults. Um cofre é uma entidade de armazenamento online em Azure usada para armazenar dados, como cópias de backup, pontos de recuperação e políticas de backup. Há dois tipos de cofres: cofres dos Serviços de Recuperação e cofres de Backup. Você pode usar um ou ambos os tipos de cofre dependendo do que precisa proteger. Para ver uma lista das fontes de dados compatíveis com cada tipo de cofre, confira Quais são os vários cofres com suporte para backup e restauração?.

Os trabalhos representam a atividade de fazer backup ou restaurar seus dados. Os trabalhos de backup incluem operações agendadas ou sob demanda que copiam seus dados da origem para o repositório. Os trabalhos de restauração incluem operações que recuperam seus dados do armazenamento de backup para um local de destino. Cada trabalho tem um identificador exclusivo e um controle de status, permitindo que você monitore o progresso e solucione problemas que surgem durante operações de backup e restauração. Você também cria políticas de backup associadas a trabalhos. As políticas especificam a configuração, como o agendamento de backup e por quanto tempo você deseja reter dados.

Os cofres armazenam suas políticas de backup e configuração e também armazenam metadados sobre trabalhos, o que permite acompanhar e solucionar problemas.

Arquitetura física

A infraestrutura de serviço de Backup do Azure principal é gerenciada pela Microsoft. Essa infraestrutura é responsável pelo gerenciamento e operação do serviço, incluindo trabalhos de gatilho e monitoramento.

O serviço Backup do Azure armazena backups no cofre. Os cofres são construídos sobre o Armazenamento do Azure. Os cofres replicam automaticamente os dados de backup e a durabilidade e a resiliência do backup dependem da redundância de armazenamento do cofre:

• LRS (armazenamento com redundância local) replica os dados em seu cofre para uma ou mais zonas de disponibilidade Azure localizadas na região primária de sua escolha. Embora não haja nenhuma opção para escolher sua zona de disponibilidade preferencial, Azure pode mover ou expandir contas LRS entre zonas para melhorar o balanceamento de carga. Não há garantia de que seus dados serão distribuídos entre zonas. Para obter mais informações sobre availability zones, consulte O que são Zonas de Disponibilidade?.

• O ZRS (armazenamento com redundância de zona) e o GRS (armazenamento com redundância geográfica) fornecem proteções extras. Este artigo descreve essas opções em detalhes.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes nos componentes. Elas ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. Falhas transitórias se corrigem após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente repetindo solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes transitórias de tratamento de falhas Azure quando se comunicam com apis, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, confira Recomendações para tratamento de falhas transitórias.

Quando você usa Backup do Azure, os fluxos de trabalho de backup e restauração são resilientes a falhas intermitentes. O serviço tenta novamente automaticamente quando encontra falhas transitórias de rede ou interrupções temporárias de serviço. Você não configura nenhuma lógica de repetição. Se você tiver falhas repetidas, consulte a documentação de solução de problemas.

Resiliência a falhas de zona de disponibilidade

as zonas Availability são grupos fisicamente separados de datacenters em uma região Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

Backup do Azure gerencia separadamente a configuração da zona de disponibilidade do serviço e de seus dados.

• Service: O próprio serviço Backup do Azure é automaticamente resiliente a zonas em regiões com suporte, sem nenhuma ação necessária de você. No entanto, essa resiliência de zona interna não se aplica aos seus dados de backup.

• Redundância de armazenamento de backup: Selecione o nível de redundância desejado para seus dados de backup configurando o cofre dos Serviços de Recuperação ou o cofre de Backup. Se você selecionar ZRS (armazenamento com redundância de zona), as cópias dos dados de backup serão armazenadas automaticamente em várias zonas de disponibilidade na região Azure que você usa.

  Se você não usar o ZRS, seus dados de backup serão considerados nonzoais e poderão ser armazenados em qualquer zona. Se qualquer zona na região tiver um problema, os dados de backup nonzonal poderão ficar indisponíveis.

Requirements

• Suporte à região: O serviço é automaticamente resiliente em todas as regiões com zonas de disponibilidade. Há suporte para cofres ZRS nas mesmas regiões.

• Somente novos cofres: Configure o ZRS no seu cofre antes do primeiro backup.

Custo

Quando você habilita o ZRS (armazenamento com redundância de zona) para seus backups, você é cobrado a uma taxa diferente do LRS (armazenamento com redundância local) devido à sobrecarga de armazenamento e replicação extra. Para obter mais informações, consulte Backup do Azure preços.

Configurar o suporte à zona de disponibilidade

• Crie um novo cofre que use o ZRS: Ao criar um cofre, você também deve configurar a redundância de armazenamento. As etapas que você segue variam dependendo do tipo de cofre. Para obter mais informações, consulte:

  • Criar e excluir cofres de backup
  • Criar e configurar um cofre dos Serviços de Recuperação

• Configurar o ZRS em cofres existentes: Para cofres de backup, configure a redundância de armazenamento ao criar o cofre. Depois que um cofre de Backup é criado, a configuração é bloqueada e não pode ser alterada.

  Para os cofres dos Serviços de Recuperação, a redundância de armazenamento deve ser configurada antes de proteger as cargas de trabalho. Depois que uma carga de trabalho é protegida, a configuração é bloqueada e não pode ser alterada.

  Você pode criar um novo cofre configurado para usar o ZRS e reatribuir suas cargas de trabalho para o novo cofre. No entanto, essa abordagem requer tempo de inatividade. Para obter mais informações, consulte Criar e configurar um cofre dos Serviços de Recuperação – Modificar configurações padrão](/azure/backup/backup-create-recovery-services-vault#modify-default-settings). Você também é responsável por excluir manualmente todos os pontos de recuperação existentes e outros dados manualmente, pois as políticas de retenção do cofre antigo não se aplicam mais a eles. Para obter mais informações sobre como excluir um cofre, consulte Excluir um cofre de Backup ou excluir um cofre dos Serviços de Recuperação.

Comportamento quando todas as zonas estão saudáveis

Quando os cofres usam armazenamento com redundância de zona e todas as zonas de disponibilidade estão operacionais, espere o seguinte:

• Operação entre zonas: Trabalhos de backup são executados na infraestrutura replicada entre zonas. Azure gerencia trabalhos de infraestrutura em qualquer zona.

• Replicação de dados entre zonas: O ZRS replica dados de backup entre zonas. A replicação ocorre de forma síncrona, o que significa que várias zonas reconhecem cada operação de gravação antes de ser concluída.

Comportamento durante uma falha de zona

Quando os cofres são configurados para usar armazenamento com redundância de zona e ocorre uma interrupção de zona de disponibilidade, espere o seguinte:

• Detecção e resposta: Para o próprio serviço Backup do Azure, a Microsoft é responsável por detectar uma falha em uma zona de disponibilidade e responder. Você não precisa fazer nada para iniciar um failover de zona.

  Importante

  Para quaisquer dados ou recursos que não estejam disponíveis devido à interrupção da zona, você é responsável por detectar a interrupção e executar quaisquer ações de recuperação, incluindo a restauração de backups para uma zona íntegra.

• Notificação: a Microsoft não notifica você automaticamente quando uma zona está inativa. No entanto, você pode usar Azure Resource Health para monitorar a integridade de um recurso individual e pode configurar alertas Resource Health para notificar você sobre problemas. Você também pode usar Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e você pode configurar alertas Service Health para notificar você sobre problemas.

• Solicitações ativas: O comportamento de qualquer tarefa ativa depende da zona que falhou.

  • Para quaisquer fontes de dados na zona de disponibilidade com falha, as fontes de dados provavelmente não estarão disponíveis devido à falha da zona. Qualquer trabalho ativo pode pausar ou falhar.
  • Para quaisquer fontes de dados em zonas de disponibilidade íntegras que estejam executando trabalhos ativos, uma pequena quantidade de tempo de inatividade, normalmente alguns segundos, pode ocorrer enquanto a plataforma alterna para usar zonas de disponibilidade íntegras para o serviço Backup do Azure.

• Perda de dados esperada: A quantidade de perda de dados que você pode esperar também é conhecida como o RPO (objetivo de ponto de recuperação). O RPO para seus dados de backup depende de vários fatores, incluindo sua programação de backup. Em geral, para uma interrupção de zona, nenhuma perda de dados de backup é esperada porque todos os dados são replicados de forma síncrona entre zonas.

• Tempo de inatividade esperado: A quantidade de tempo de inatividade que você pode esperar também é conhecida como o RTO (objetivo de tempo de recuperação). O RTO é diferente para cada um dos seguintes cenários:

  • Para quaisquer fontes de dados na zona de disponibilidade com falha, as fontes de dados podem não estar disponíveis até que a zona se recupere. Trabalhos de backup podem não ser executados até que a fonte de dados esteja disponível novamente. O RTO é indefinido.
  • Para quaisquer fontes de dados em zonas de disponibilidade íntegras, uma pequena quantidade de tempo de inatividade, normalmente alguns segundos, pode ocorrer enquanto a plataforma alterna para usar zonas de disponibilidade íntegras para o serviço Backup do Azure.

• Redistribuição: Todas as execuções de trabalho subsequentes usam automaticamente a infraestrutura em zonas íntegras, desde que as fontes de dados estejam disponíveis.

  Você é responsável por restaurar o backup para a infraestrutura em uma zona saudável e reconfigurar todos os balanceadores de carga, clientes e outros sistemas para redirecionar o tráfego para uma infraestrutura íntegra na nova zona.

Recuperação de zona

Quando a zona de disponibilidade se recupera, Backup do Azure restaura automaticamente as operações na zona de disponibilidade e redireciona o tráfego entre as zonas normalmente. Os trabalhos continuam em execução e os dados permanecem disponíveis.

Testar falhas em zonas

A plataforma Backup do Azure gerencia o roteamento de tráfego, a replicação de dados, o failover e o failback. Esse recurso é totalmente gerenciado, então você não precisa iniciar ou validar processos de falha de zona de disponibilidade.

Resiliência a falhas em toda a região

Backup do Azure dá suporte à redundância geográfica e failover por meio do GRS (armazenamento com redundância geográfica) e restauração entre regiões.

Armazenamento com redundância geográfica e restauração entre regiões

Para obter redundância regional para seus dados de backup, o Backup do Azure permite replicar seus backups para uma região emparelhada do Azure usando GRS (armazenamento com redundância geográfica). O GRS protege seus backups contra interrupções regionais.

A região na qual você implanta seu cofre é chamada de região primária. Suas fontes de dados devem estar localizadas na região primária. Você não pode configurar backups para um cofre em uma região diferente.

A região emparelhada também é conhecida como a região secundária.

Diagrama que mostra como os dados são replicados usando GRS.

Se você não configurar o GRS, uma interrupção na região do cofre ainda poderá permitir que você acesse o cofre e exiba itens de backup. No entanto, sem redundância regional, os dados de backup subjacentes permanecem indisponíveis para operações de restauração.

Restauração entre regiões

Quando você configura o GRS em um cofre, a Microsoft disponibiliza backups na região emparelhada após declarar uma interrupção na região primária. Se a fonte de dados der suporte à habilitação da restauração entre regiões, você poderá restaurar dos pontos de recuperação de região secundária mesmo quando nenhuma interrupção ocorrer na região primária. A restauração entre regiões também permite executar simulações para avaliar sua resiliência contra interrupções regionais. Habilitar a restauração entre regiões atualiza o armazenamento de backup do GRS para o armazenamento com redundância geográfica de acesso de leitura (RA-GRS).

Requirements

• Suporte de região: O GRS para o Backup do Azure funciona apenas em regiões emparelhadas do Azure.

• Somente novos cofres: O GRS deve estar configurado em seu cofre antes que o primeiro backup ocorra.

Considerações

• Restauração entre regiões: Depois de ativar a restauração entre linhas, pode levar até 48 horas para que os itens de backup estejam disponíveis na região secundária.

Custo

Os cofres GRS incorrem em custos extras para replicação entre regiões e armazenamento na região secundária. A transferência de dados entre regiões do Azure é cobrada com base nas taxas de largura de banda padrão entre regiões. A restauração entre regiões é cobrada a uma taxa diferente porque a Microsoft atualiza o armazenamento do cofre do GRS para o RA-GRS. Para obter mais informações, consulte Backup do Azure preços.

Configurar o suporte a várias regiões

• Crie um novo cofre que use GRS e CRR: Ao criar um cofre, você também deve configurar a redundância de armazenamento. Opcionalmente, depois de selecionar GRS, você pode habilitar CRR no cofre. As etapas que você segue variam dependendo do tipo de cofre. Para obter mais informações, consulte:

  • Criar e excluir cofres de backup
  • Criar e configurar um cofre dos Serviços de Recuperação

• Configurar GRS e CRR em cofres existentes: Para cofres de backup, a redundância de armazenamento deve ser configurada quando você cria o cofre.

  Para os cofres dos Serviços de Recuperação, a redundância de armazenamento deve ser configurada antes de proteger as cargas de trabalho. Depois que uma carga de trabalho é protegida, a configuração é bloqueada e não pode ser alterada.

  Você pode habilitar o CRR em cofres de Resiliência Geográfica (GRS) existentes. Não é possível desabilitar o CRR depois que ele estiver habilitado.

Comportamento quando todas as regiões estão saudáveis

Esta seção descreve o que esperar quando os cofres são configurados para usar armazenamento geograficamente redundante e todas as regiões estão operacionais.

• Operação entre regiões: Os backups são sempre concluídos na região primária, que é a região em que o cofre e a fonte de dados são implantados.

• Replicação de dados entre regiões: Quando o cofre é configurado para usar GRS, os backups são primeiro confirmados na região primária usando armazenamento com redundância local (LRS). Após a conclusão bem-sucedida na região primária, os dados são replicados de forma assíncrona para a região secundária em que são armazenados usando LRS. Pode levar até 12 horas para replicar os dados de backup da região primária para a região secundária.

Comportamento durante uma falha de região

Esta seção descreve o que pode ocorrer quando os cofres são configurados para usar o armazenamento com redundância geográfica e ocorre uma interrupção na região primária.

• Detecção e resposta: Para fontes de dados que dão suporte à restauração entre regiões e onde a restauração entre regiões está habilitada no cofre, você pode iniciar sua própria restauração entre regiões para a região emparelhada a qualquer momento, inclusive durante uma interrupção ou desastre de região. Você é responsável por detectar a interrupção e executar qualquer ação de recuperação, incluindo a restauração de backups para uma região íntegra.

  Para todos os outros cenários, os dados replicados para a região secundária só estão disponíveis para restauração na região secundária se Azure declarar um desastre na região primária. A Microsoft é responsável por declarar tal desastre. O tempo necessário para declarar um desastre depende da gravidade do incidente e do tempo necessário para avaliar a situação. Provavelmente, ela só seria executada após um longo período de tempo.

• Notificação: a Microsoft não notifica você automaticamente quando uma região está inoperante. No entanto:

  • Você pode usar Azure Resource Health para monitorar a integridade de um recurso individual e configurar alertas Resource Health para notificá-lo de problemas.

  • Você pode usar Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo eventuais falhas de região, e pode configurar alertas Service Health para notificá-lo de problemas.

• Perda de dados esperada: O RPO para seus dados de backup depende de vários fatores, incluindo seu agendamento de backup. Em geral, para uma interrupção de região, você deve esperar até 36 horas de perda de dados, pois o RPO na região primária é de 24 horas e pode levar até 12 horas para replicar os dados de backup da região primária para a secundária.

• Tempo de inatividade esperado: O RTO é diferente para cada um dos seguintes cenários:

  • Fontes de dados e outros recursos na região com falha podem não estar disponíveis até que a região se recupere, portanto, o RTO é indefinido.
  • Backup do Azure pode não ser capaz de executar operações de backup ou restauração na região com falha até que a região se recupere, portanto, o RTO é indefinido.
  • Se você usar a restauração entre regiões, o RTO para iniciar a restauração de backups que já foram replicados para a região emparelhada será zero. Se você não usar a restauração entre regiões, o RTO dependerá de quanto tempo a Microsoft levará para declarar um desastre na região com falha.

  Nenhum trabalho de backup pode ser executado enquanto a região primária estiver offline. Você pode restaurar dados no cofre, mas não adicionar dados novos.

• Redistribuição: Nenhum trabalho de backup pode ser executado enquanto a região primária estiver offline. Você pode restaurar dados no cofre, mas não adicionar dados novos.

  Você é responsável por restaurar o backup para a infraestrutura na região emparelhada e reconfigurar todos os balanceadores de carga, clientes e outros sistemas para redirecionar o tráfego para uma infraestrutura íntegra na região emparelhada.

Recuperação de região

Quando a região primária se recupera, Backup do Azure restaura automaticamente as operações na região. Os trabalhos são retomados e os dados permanecem disponíveis.

Teste de falhas na região

Você pode usar a restauração entre regiões para executar uma operação de restauração para a região emparelhada. Você pode usar essa abordagem para verificar sua restauração e outros processos de recuperação.

Resiliência à perda de dados de backup

Backup do Azure fornece dois recursos principais de recuperação para evitar a exclusão acidental ou mal-intencionada de seus dados de backup:

• Exclusão suave permite que você recupere objetos e cofres excluídos durante um período de retenção configurável. Por padrão, esse período é de 14 dias, mas você pode configurá-lo. Pense em exclusão soft como uma lixeira para seus backups e repositórios. Para obter mais informações, consulte Secure por padrão com exclusão reversível para Backup do Azure.

• Cofres imutáveis podem ajudá-lo a proteger seus dados de backup ao bloquear qualquer operação que possa levar à perda de pontos de recuperação. Você pode bloquear a configuração do cofre imutável para torná-la irreversível. Você também pode usar o armazenamento WORM (gravar uma vez, ler muitos) para backups para impedir que atores mal-intencionados desabilitem a imutabilidade e excluam backups. Para obter mais informações, consulte o cofre Imutável para Backup do Azure.

Contrato de nível de serviço

O SLA (contrato de nível de serviço) para serviços de Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

O SLA do Backup do Azure abrange a disponibilidade do serviço para operações de backup e restauração. Para ser coberto pelo SLA, você precisa repetir trabalhos de backup ou restauração com falha com uma frequência não inferior a uma vez a cada trinta minutos.