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. O backup pode dimensionar sua proteção em várias cargas de trabalho e fornece integração nativa com cargas de trabalho do Azure, incluindo máquinas virtuais (VMs), SAP HANA em VMs do Azure, SQL em VMs do Azure, Arquivos do Azure, Armazenamento de Blobs do Azure, Azure Data Lake Storage, discos gerenciados do Azure, volumes do Azure Elastic SAN e AKS (Serviço de Kubernetes do Azure). Você não precisa gerenciar automação ou infraestrutura, gravar scripts ou provisionar armazenamento.

Quando você usa o Azure, reliability é uma responsabilidade compartilhada. 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 o Backup pode ser resiliente 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) de Backup.

Observação

Este artigo descreve como o próprio serviço de Backup é resiliente a vários problemas e como você pode torná-lo mais resiliente. Ele não explica como usar o Backup para proteger suas VMs, dados ou outros ativos. Para saber mais sobre como usar o Backup, consulte Visão geral do Backup.

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

Para fazer backup de suas cargas de trabalho de produção, recomendamos que você configure seu cofre das seguintes maneiras:

  • Use o ZRS (armazenamento com redundância de zona) como a camada de redundância mínima para seus backups. O ZRS replica seus backups em várias zonas de disponibilidade para que você possa restaurar seus backups durante uma interrupção da zona de disponibilidade.

  • Se você usar GRS (armazenamento com redundância geográfica) para replicar seus backups para uma região de Azure emparelhada, habilite a CRR (restauração entre regiões) para fontes de dados com suporte. O CRR permite restaurar os backups na região emparelhada a qualquer momento.

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

Observação

Essas recomendações de redundância de armazenamento se aplicam a locais em que as cópias de backup são replicadas, não ao serviço de Backup ou aos recursos que você faz backup. A proteção de backup e a redundância de armazenamento se complementam. Os backups protegem contra perda de dados e a redundância protege contra falhas de infraestrutura.

Para obter uma lista de outras recomendações para Backup, incluindo recomendações focadas em confiabilidade, consulte a nuvem de backup 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

A ferramenta de backup pode fazer backup e restaurar uma variedade de fontes de dados. Você configura backups de forma diferente dependendo da fonte de dados com a qual trabalha. As seguintes fontes de dados são comuns:

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

O backup armazena seus dados de backup em volumes. Os cofres são entidades de armazenamento online em Azure que contêm dados, como cópias de backup, pontos de recuperação e políticas de backup. Cofres dos Serviços de Recuperação e cofres de Backup são dois tipos de cofres. Você pode usar um ou ambos os tipos dependendo do que precisa proteger. Para obter uma lista das fontes de dados compatíveis com cada tipo de cofre, consulte perguntas frequentes sobre os 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 acompanhamento de status para que você possa monitorar o progresso e solucionar problemas que ocorrem 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 a configuração juntamente com metadados sobre trabalhos, o que permite acompanhar trabalhos e solucionar problemas.

Arquitetura física

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

Os backups são guardados no cofre. Os cofres são construídos com base no 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.

  • Armazenamento com Redundância Local (LRS) replica dados no seu ambiente para uma ou mais zonas de disponibilidade Azure localizadas na região primária de sua escolha. Você não pode escolher sua zona de disponibilidade preferencial, mas Azure pode mover ou expandir contas LRS entre zonas para melhorar o balanceamento de carga. Seus dados não têm garantia de serem distribuídos entre as zonas. Para obter mais informações, consulte Visão geral das zonas de disponibilidade.

  • ZRS e GRS fornecem proteções extras. Este artigo descreve essas opções em detalhes.

Observação

Algumas fontes de dados oferecem suporte a backups de camada operacional, que armazenam dados em outro local ao invés do repositório. Por exemplo, o backup de discos gerenciados do Azure e os backups AKS dão suporte a backups de camada operacional, que são armazenados em instantâneos de disco. Este artigo não discute o armazenamento de backup da camada operacional, mas você pode aplicar as diretrizes de resiliência neste artigo a operações de backup e fluxos de trabalho para esses tipos de backup.

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, 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ê estiver enfrentando falhas repetidas, consulte Como solucionar problemas nas operações de gerenciamento do cofre de backup.

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.

O backup gerencia separadamente a configuração da zona de disponibilidade do serviço e dos seus dados.

  • Serviço: O serviço de Backup é automaticamente resiliente a zonas em regiões com suporte. 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 o ZRS, 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.

Diagrama que mostra o serviço de backup principal, que é automaticamente resiliente a zonas e armazenamento de backup com redundância de zona.

Requirements

Custo

Quando você habilita o ZRS para seus backups, é cobrado a uma taxa diferente do LRS devido à replicação extra e à sobrecarga de armazenamento. Para obter mais informações, consulte Preços de backup.

Configurar o suporte à zona de disponibilidade

  • Crie um novo cofre que use o ZRS: Configure a redundância de armazenamento ao criar um cofre. Você segue diferentes etapas dependendo do tipo de cofre. Para obter mais informações, consulte os seguintes artigos:

  • Configurar o ZRS em cofres existentes: Para cofres de backup, configure a redundância de armazenamento ao criar o cofre. Depois de criar um cofre de Backup, a configuração será bloqueada e você não poderá alterá-la.

    Para cofres do Serviço de Recuperação, você deve configurar a redundância de armazenamento antes de proteger cargas de trabalho. Depois de proteger uma carga de trabalho, a configuração será bloqueada e você não poderá alterá-la.

    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 Modificar as configurações padrão. Você também é responsável por excluir manualmente os pontos de recuperação já existentes e outros dados porque as políticas de retenção do cofre antigo não são mais aplicáveis. Para obter mais informações, 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

Esta seção descreve o que esperar quando você configura cofres para ZRS e todas as zonas estão operacionais.

  • 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

Esta seção descreve o que esperar ao configurar cofres de armazenamento para ZRS, no caso de interrupção em uma das zonas.

  • Detection and response: Para o serviço de Backup, a Microsoft é responsável por detectar e responder a falhas nas zonas de disponibilidade. 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 ações de recuperação, incluindo a restauração de backups para uma zona íntegra.

  • Notification: Microsoft não notifica automaticamente quando uma zona está inoperante. 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 tarefas ativas depende de qual zona falha.

    • Para quaisquer fontes de dados na zona de disponibilidade com falha, a falha na zona torna as fontes de dados indisponíveis. Trabalhos ativos podem pausar ou falhar.

    • Para qualquer fonte de dados em zonas de disponibilidade saudáveis que executam trabalhos ativos, pode ocorrer um pequeno tempo de inatividade, normalmente de alguns segundos, enquanto a plataforma alterna para zonas de disponibilidade saudáveis para o serviço de Backup.

  • Perda de dados esperada: A quantidade esperada de perda de dados também é conhecida como 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 esperada de tempo de inatividade também é conhecida como 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 saudáveis, uma pequena quantidade de tempo de inatividade, normalmente alguns segundos, pode ocorrer enquanto a plataforma alterna para zonas de disponibilidade saudáveis para o serviço de Backup.

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

    Você é responsável por restaurar o backup para a infraestrutura em uma zona íntegra e reconfigurar 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 é recuperada, o Backup 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 de Backup 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

O backup oferece suporte à georredundância e ao failover por meio de GRS e CRR.

Importante

GRS para Backup funciona apenas em regiões emparelhadas do Azure.

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

Para obter redundância regional para seus dados de backup, use o Backup para replicar seus backups para uma região emparelhada Azure usando GRS. O GRS protege seus backups contra interrupções regionais.

A região na qual você implanta o cofre é chamada 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 outra região.

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 e ocorrer uma interrupção na região do cofre, talvez ainda consiga acessar o cofre e visualizar os 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, Microsoft disponibiliza backups na região emparelhada após uma interrupção na região primária. Se a sua fonte de dados suportar CRR, você poderá restaurar a partir de pontos de recuperação da região secundária, mesmo que não haja interrupção na região primária. O CRR também permite executar drills para avaliar a resiliência em relação a interrupções regionais. Quando você ativa o CRR, Microsoft atualiza o armazenamento de backup do GRS para o armazenamento com redundância geográfica de acesso de leitura (RA-GRS).

Requirements

  • Region support: GRS para Backup funciona apenas em regiões pares do Azure.

  • Somente novos cofres: Você deve configurar o GRS em seu cofre antes que o primeiro backup ocorra.

Considerações

  • CRR: Depois de ativar o CRR, os itens de backup podem levar até 48 horas para estarem 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 padrão de largura de banda entre regiões. O CRR é cobrado a uma taxa diferente porque Microsoft atualiza o armazenamento do cofre do GRS para o RA-GRS. Para obter mais informações, consulte Preços de backup.

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. Depois de selecionar GRS, você tem a opção de habilitar o CRR no cofre. As etapas a seguir dependem do tipo de cofre. Para obter mais informações, consulte os seguintes artigos:

  • Configurar GRS e CRR em cofres existentes: Para cofres de backup, você deve configurar a redundância de armazenamento ao criar o cofre.

    Para cofres dos Serviços de Recuperação, você deve configurar a redundância de armazenamento antes de proteger quaisquer cargas de trabalho. Depois que uma carga de trabalho é protegida, a configuração é bloqueada e você não pode alterá-la.

    Você pode habilitar o CRR em cofres de Resiliência Geográfica (GRS) existentes. Depois de habilitar o CRR, você não poderá desabilitá-lo.

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

Esta seção descreve o que esperar quando você configura cofres para usar GRS 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 você configura o cofre para usar GRS, os backups são confirmados pela primeira vez na região primária usando 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. A região secundária usa LRS para armazenar dados. Os dados de backup podem levar até 12 horas para serem replicados da região primária para a região secundária.

Comportamento durante uma falha de região

Esta seção descreve o que esperar quando você configura cofres para usar GRS e ocorre uma interrupção na região primária.

  • Detecção e resposta: Para fontes de dados que oferecem suporte a CRR e onde o CRR está ativado no cofre, você pode iniciar sua própria CRR para a região pareada a qualquer momento, inclusive durante uma interrupção ou desastre regional. Você é responsável por detectar a interrupção e executar ações 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. Microsoft é responsável por declarar um desastre. O tempo necessário para declarar um desastre depende da gravidade do incidente e do tempo necessário para avaliar a situação. Microsoft normalmente declara um desastre somente após um longo período de tempo.

  • Notification: Microsoft não notifica automaticamente quando uma região está inoperante. No entanto:

  • 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, espere até 36 horas de perda de dados porque 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.

    • O backup pode não conseguir realizar operações de backup ou restauração na região afetada até que esta se recupere, portanto, o RTO é indefinido.

    • Se você usar CRR, o RTO para iniciar a restauração de backups que já foram replicados para a região emparelhada é zero. Se você não usar CRR, o RTO dependerá de quanto tempo leva para a Microsoft declarar um desastre na região com falha.

  • 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 pode adicionar novos dados.

    Você é responsável por restaurar o backup para a infraestrutura na região emparelhada e reconfigurar 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, o Backup 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 CRR para executar uma operação de restauração para a região emparelhada. Você pode usar essa abordagem para verificar a restauração e outros processos de recuperação.

Resiliência à perda de dados de backup

O backup fornece dois recursos de recuperação importantes para evitar a exclusão acidental ou mal-intencionada dos dados de backup:

  • A exclusão reversível permite recuperar 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 editá-lo. Pense na exclusão suave como uma lixeira para seus backups e cofres. Para obter mais informações, consulte Seguro por padrão com exclusão lógica para Backup.

  • Cofres imutáveis podem ajudá-lo a proteger seus dados de backup bloqueando operações que podem 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 (Write Once, Read Many) para backups, a fim de impedir que agentes mal-intencionados desabilitem a imutabilidade e excluam as cópias de segurança. Para obter mais informações, consulte Cofre Imutável de Backup.

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 de Backup aborda 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 pelo menos uma vez a cada 30 minutos.

Conteúdo relacionado

  • Last updated on