Confiabilidade no Azure Backup

Azure Backup é um serviço Azure incorporado que protege de forma segura cargas de trabalho na cloud e on-premises. Azure Backup pode escalar a sua proteção de forma fluida em múltiplas cargas de trabalho e proporciona integração nativa com cargas de trabalho Azure, incluindo máquinas virtuais (VMs), SAP HANA em Azure VM, SQL em Azure VMs, Ficheiros do Azure, Azure Blob, Azure Data Lake, Discos, volumes SAN elásticos, AKS e mais. Não precisas de gerir automação ou infraestruturas. Não há necessidade de escrever scripts ou provisionar armazenamento.

Quando se usa Azure, fiabilidade é uma responsabilidade partilhada. A Microsoft fornece uma variedade de recursos para oferecer 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 Azure Backup pode ser resiliente a uma variedade de potenciais falhas e problemas, incluindo falhas transitórias, falhas em zonas de disponibilidade e interrupções regionais. Também destaca algumas informações chave sobre o acordo de nível de serviço (SLA) do Azure Backup.

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

Para o backup das suas cargas de trabalho de produção, recomendamos que configure o seu vault da seguinte forma:

As secções restantes deste artigo fornecem mais detalhes sobre estas configurações.

Para uma lista de outras recomendações para Azure Backup, incluindo recomendações focadas na fiabilidade, veja Backup de cargas de trabalho na cloud e no local para a cloud.

Visão geral da arquitetura de confiabilidade

Esta secção descreve alguns dos aspetos importantes do funcionamento do serviço que são mais relevantes do ponto de vista da fiabilidade. A secção apresenta a arquitetura lógica, que inclui alguns dos recursos e funcionalidades que implementa e utiliza. Também discute a arquitetura física, detalhando como o serviço funciona nos bastidores.

Arquitetura lógica

Azure Backup pode fazer backup e restaurar uma variedade de fontes de dados . Configuras backups de forma diferente consoante a fonte de dados com que estás a trabalhar. Fontes de dados comuns incluem:

• Azure virtual machines (VMs)
• Várias bases de dados
• Contas de Blob do Azure
• Clusters do AKS
• Servidores on-premises através do agente Microsoft Azure Recovery Services (MARS)

Azure Backup armazena os teus dados de backup em vaults. Um cofre é uma entidade de armazenamento online no Azure que é usada para armazenar dados, como cópias de segurança, pontos de recuperação e políticas de backup. Existem dois tipos de cofres: cofres de Serviços de Recuperação e cofres de backup. Podes usar um ou ambos os tipos de cofre, dependendo do que precisas de proteger. Para ver uma lista das fontes de dados que cada tipo de cofre suporta, veja Quais são os vários cofres suportados para backup e restauro?

Os trabalhos representam a atividade de fazer backup ou restaurar os seus dados. Os trabalhos de backup incluem operações agendadas ou sob demanda que copiam os seus dados da fonte para o cofre. Os trabalhos de restauro incluem operações que recuperam os seus dados do armazenamento de backup para um local alvo. Cada trabalho tem um identificador único e um rastreio de estado, permitindo-lhe monitorizar o progresso e resolver quaisquer problemas que surjam durante as operações de backup e restauro. Também crias políticas de backup associadas a empregos. As políticas especificam a configuração, como o cronograma de backup, e quanto tempo quer reter os dados.

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

Arquitetura física

A infraestrutura central do serviço Azure Backup é gerida pela Microsoft. Esta infraestrutura é responsável pela gestão e operação do serviço, incluindo o desencadeamento e monitorização de tarefas.

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

• Armazenamento localmente redundante (LRS) replica os dados dentro do seu cofre para uma ou mais zonas de disponibilidade da Azure localizadas na região principal da sua escolha. Embora não haja opção para escolher a sua zona de disponibilidade preferida, o 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 espalhados por zonas. Para mais informações sobre zonas de disponibilidade, consulte O que são Zonas de Disponibilidade?.

• O armazenamento redundante por zonas (ZRS) e o armazenamento geo-redundante (GRS) oferecem proteções adicionais. Este artigo descreve essas opções em detalhes.

Resiliência a falhas transitórias

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

Todas as aplicações alojadas na cloud devem seguir as orientações de tratamento de falhas transitórias do Azure quando comunicarem com quaisquer APIs, bases de dados e outros componentes alojados na cloud. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.

Quando usa o Azure Backup, tanto os fluxos de trabalho de backup como de restauro são resilientes a falhas intermitentes. O serviço tenta automaticamente novamente quando encontra falhas transitórias na rede ou interrupções temporárias de serviço. Você não configura nenhuma lógica de novas tentativas. Se tiver falhas repetidas, consulte a documentação de resolução de problemas.

Resiliência a falhas na zona de disponibilidade

Zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.

O Azure Backup gere, separadamente, a configuração da zona de disponibilidade do serviço e dos seus dados.

• Service: O serviço Azure Backup em si é automaticamente resiliente em zonas nas regiões suportadas, sem necessidade de qualquer ação da sua parte. No entanto, esta resiliência de zona incorporada não se aplica aos seus dados de backup.

• Redundância de armazenamento de backup: Selecione o nível de redundância que pretende para os seus dados de backup configurando o seu cofre de Serviços de Recuperação ou Cofre de Backup. Se selecionar armazenamento redundante por zonas (ZRS), cópias dos seus dados de backup são automaticamente armazenadas em múltiplas zonas de disponibilidade na região do Azure que utiliza.

  Se não usar ZRS, os seus dados de backup são considerados não zonais e podem estar armazenados em qualquer zona. Se alguma zona da região tiver um problema, os dados de backup não zonais podem não estar disponíveis.

Requerimentos

• Apoio regional: O serviço é automaticamente resiliente em zonas em todas as regiões com zonas de disponibilidade. Os vaults ZRS são suportados nas mesmas regiões.

• Apenas novos cofres: Configura o ZRS no teu cofre antes do primeiro backup.

Custo

Quando ativas o armazenamento redundante por zona (ZRS) para os teus backups, és cobrado a uma taxa diferente do armazenamento redundante local (LRS) devido à duplicação extra e sobrecarga de armazenamento. Para mais informações, consulte Azure Backup preços.

Configurar o suporte à zona de disponibilidade

• Crie um novo cofre que use ZRS: Quando crias um cofre, também deves configurar a redundância de armazenamento. Os passos que deves seguir diferem conforme o tipo de cofre. Para obter mais informações, consulte:

  • Criar e eliminar cofres de backup
  • Crie e configure um cofre de Serviços de Recuperação

• Configure o ZRS nos cofres existentes: Para cofres de backup, configura redundância de armazenamento quando criares o cofre. Uma vez criado um cofre de backup, a definição fica bloqueada e não pode ser alterada.

  Para cofres de Serviços de Recuperação, a redundância de armazenamento deve ser configurada antes de proteger quaisquer cargas de trabalho. Uma vez que a carga de trabalho está protegida, a definição fica bloqueada e não pode ser alterada.

  Podes criar um novo cofre configurado para usar o ZRS e realocar as tuas cargas de trabalho para o novo cofre. No entanto, esta abordagem requer tempo de inatividade. Para mais informações, consulte Criar e configurar um cofre de Serviços de Recuperação - Modificar definições predefinidas](/azure/backup/backup-create-recovery-services-vault#modify-default-settings). Também és responsável por apagar manualmente quaisquer pontos de recuperação existentes e outros dados, porque as políticas de retenção do antigo cofre já não se aplicam. Para mais informações sobre como eliminar um cofre, consulte Eliminar um cofre de Backup ou Eliminar um cofre dos Serviços de Recuperação.

Comportamento quando todas as zonas estão íntegras

Quando os vaults utilizam armazenamento redundante por zonas e todas as zonas de disponibilidade estão operacionais, espere o seguinte:

• Operação entre zonas: Os trabalhos de backup correm numa infraestrutura replicada entre zonas. O Azure gere trabalhos a partir de infraestruturas 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 múltiplas zonas reconhecem cada operação de escrita antes de esta ser concluída.

Comportamento durante uma falha de zona

Quando os vaults são configurados para usar armazenamento redundante por zona e ocorre uma falha na zona de disponibilidade, espere o seguinte:

• Deteção e resposta: Para o próprio serviço Azure Backup, a Microsoft é responsável por detetar uma falha numa 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, és responsável por detetar a falha e tomar quaisquer ações de recuperação, incluindo restaurar backups numa zona saudável.

• Notificação: a Microsoft não o notifica automaticamente quando uma zona está inativa. No entanto, pode usar Azure Resource Health para monitorizar a saúde de um recurso individual, e pode configurar alertas Resource Health para o notificar de problemas. Também pode usar Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas Saúde do Serviço para o notificar de problemas.

• Pedidos ativos: O comportamento de qualquer trabalho ativo depende de qual zona falhou.

  • Para quaisquer fontes de dados na zona de disponibilidade falhada, é provável que as fontes de dados estejam indisponíveis devido à falha da zona. Qualquer trabalho ativo pode parar ou falhar.
  • Para quaisquer fontes de dados em zonas de disponibilidade saudável que estejam a executar trabalhos ativos, pode ocorrer um pequeno período de inatividade, normalmente alguns segundos, enquanto a plataforma muda para usar zonas de disponibilidade saudáveis para o serviço Azure Backup.

• Perda de dados esperada: A quantidade de perda de dados que pode esperar é também designada como objetivo do ponto de recuperação (RPO). O RPO dos seus dados de backup depende de vários fatores, incluindo o seu calendário de backup. Em geral, para uma interrupção de zona, não se espera perda de dados acumulados porque todos os dados são replicados de forma síncrona entre zonas.

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

  • Para quaisquer fontes de dados na zona de disponibilidade falhada, as fontes podem não estar disponíveis até que a zona recupere. Os trabalhos de backup podem falhar até que a fonte de dados esteja disponível novamente. O RTO é indefinido.
  • Para quaisquer fontes de dados em zonas de disponibilidade saudáveis, pode ocorrer um pequeno período de inatividade, normalmente alguns segundos, enquanto a plataforma muda para usar zonas de disponibilidade saudáveis para o serviço Azure Backup.

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

  És responsável por restaurar o teu backup na infraestrutura numa zona saudável e por reconfigurar quaisquer balanceadores de carga, clientes e outros sistemas para redirecionar o tráfego para infraestruturas saudáveis na nova zona.

Recuperação de zona

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

Teste de falhas de zona

A plataforma Azure Backup gere o encaminhamento de tráfego, replicação de dados, failover e failback. Esse recurso é totalmente gerenciado, portanto, você não precisa iniciar ou validar processos de falha na zona de disponibilidade.

Resiliência a falhas em toda a região

O Azure Backup suporta geo-redundância e failover através de armazenamento geo-redundante (GRS) e restauração entre regiões.

Armazenamento geo-redundante e restauração entre regiões

Para alcançar redundância regional para os seus dados de backup, o Azure Backup permite-lhe replicar os seus backups para uma região emparelhada Azure usando armazenamento geo-redundante (GRS). O GRS protege os seus backups contra falhas regionais.

A região onde colocas o teu vault chama-se a região principal. As suas fontes de dados devem estar localizadas na região principal. Não podes configurar backups para um cofre noutra região.

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

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

Se não configurar o GRS, uma falha na região do cofre poderá ainda permitir-lhe aceder ao 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 restauro.

Restauração entre regiões

Quando configura GRS num cofre, a Microsoft disponibiliza backups na região emparelhada após declarar uma falha na região principal. Se a sua fonte de dados suportar a ativação da restauração entre regiões, pode restaurar a partir de pontos de recuperação da região secundária mesmo quando não ocorra falha na região primária. A restauração entre regiões também permite realizar exercícios para avaliar a sua resiliência face a falhas regionais. Ativar a restauração entre regiões atualiza o seu armazenamento de backup do GRS para armazenamento geo-redundante de acesso de leitura (RA-GRS).

Requerimentos

• Region support: GRS para Azure Backup só funciona em regiões emparelhadas do Azure.

• Apenas novos cofres: O GRS tem de ser configurado no cofre antes de ocorrer a primeira cópia de segurança.

Considerações

• Restauro entre regiões: Depois de ativares a restauração cruzada, pode demorar até 48 horas até os itens de backup estarem disponíveis na região secundária.

Custo

Os vaults GRS têm custos adicionais para replicação e armazenamento entre regiões na região secundária. A transferência de dados entre regiões Azure é cobrada com base nas taxas padrão de largura de banda inter-regionais. A restauração entre regiões geográficas é cobrada a uma taxa diferente porque a Microsoft atualiza o armazenamento do seu cofre de GRS para RA-GRS. Para mais informações, consulte Azure Backup preços.

Configurar suporte a várias regiões

• Crie um novo cofre que use GRS e CRR: Quando crias um cofre, também deves configurar a redundância de armazenamento. Depois de selecionares GRS, podes opcionalmente ativar o CRR no vault. Os passos que deves seguir diferem conforme o tipo de cofre. Para obter mais informações, consulte:

  • Criar e eliminar cofres de backup
  • Crie e configure um cofre de Serviços de Recuperação

• Configure GRS e CRR em cofres existentes: Para cofres de backup, a redundância de armazenamento tem de ser configurada ao criar o cofre.

  Para cofres de Serviços de Recuperação, a redundância de armazenamento deve ser configurada antes de proteger quaisquer cargas de trabalho. Uma vez que a carga de trabalho está protegida, a definição fica bloqueada e não pode ser alterada.

  Podes ativar o CRR nos cofres GRS existentes. Não podes desativar o CRR depois de estar ativado.

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

Esta secção descreve o que esperar quando os vaults são configurados para usar armazenamento geo-redundante e todas as regiões estão operacionais.

• Operação entre regiões: Os backups são sempre realizados na região principal, que é a região onde o vault e a fonte de dados são implantados.

• Replicação de dados entre regiões: Quando o vault está configurado para usar GRS, os "backups" são primeiro armazenados na região primária usando armazenamento localmente redundante (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 onde são armazenados usando o LRS. Pode demorar até 12 horas a replicar os dados de backup da região primária para a secundária.

Comportamento durante uma interrupção regional

Esta secção descreve o que esperar quando os vaults são configurados para usar armazenamento geo-redundante e ocorre uma falha na região principal.

• Deteção e resposta: Para fontes de dados que suportam a restauração entre regiões e onde a restauração entre regiões está ativada no vault, pode iniciar a sua própria restauração entre regiões na região emparelhada a qualquer momento, incluindo durante uma interrupção ou desastre da região. És responsável por detetar a falha e tomar quaisquer ações de recuperação, incluindo restaurar backups numa região saudável.

  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 o Azure declarar um desastre na região primária. A Microsoft é responsável por declarar tal desastre. O tempo que demora a declarar um desastre depende da gravidade do incidente e do tempo necessário para avaliar a situação. Provavelmente só seria realizado após um período prolongado.

• Notificação: A Microsoft não o notifica automaticamente quando uma região está fora do ar. No entanto:

  • Pode usar Azure Resource Health para monitorizar a saúde de um recurso individual e configurar alertas Resource Health para o notificar de problemas.

  • Pode usar Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas regionais, e pode configurar alertas Service Health alerts para o notificar de problemas.

• Perda de dados esperada: O RPO dos seus dados de backup depende de vários fatores, incluindo o seu calendário de backup. De um modo geral, para uma falha de região deve esperar até 36 horas de perda de dados, porque o RPO na região primária é de 24 horas, e pode demorar até 12 horas a replicar os dados de backup da região primária para a secundária.

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

  • Fontes de dados e outros recursos na região falhada podem não estar disponíveis até a região recuperar, pelo que o RTO é indefinido.
  • O Azure Backup pode não conseguir realizar operações de backup ou restauração na região falhada até que a região recupere, pelo que o RTO é indefinido.
  • Se usares restauração entre regiões, o RTO para iniciar a restauração de backups já replicados na região emparelhada é zero. Se não usares restauro entre regiões, o RTO depende de quanto tempo demora a Microsoft a declarar um desastre na região falhada.

  Nenhum trabalho de backup pode correr enquanto a região principal está offline. Podes restaurar dados no cofre, mas não adicionar novos dados.

• Redistribuição: Nenhum trabalho de backup pode correr enquanto a região principal está offline. Podes restaurar dados no cofre, mas não adicionar novos dados.

  És responsável por restaurar o teu backup para a infraestrutura na região emparelhada e por reconfigurar quaisquer balanceadores de carga, clientes e outros sistemas para redirecionar o tráfego para infraestruturas saudáveis na região emparelhada.

Recuperação da região

Quando a região principal recupera, o Azure Backup restaura automaticamente as operações na região. O currículo e os dados de emprego continuam disponíveis.

Testes para detetar falhas na região

Pode usar a restauração entre regiões para realizar uma operação de restauro na região emparelhada. Pode usar esta abordagem para verificar a sua restauração e outros processos de recuperação.

Resiliência à perda de dados de backup

O Azure Backup oferece duas funcionalidades principais de recuperação para evitar a eliminação acidental ou maliciosa dos seus dados de backup:

• Soft delete permite-lhe recuperar objetos e repositórios apagados durante um período de retenção configurável. Por defeito, este período é de 14 dias, mas pode configurá-lo. Pensa na eliminação temporária como um contentor de reciclagem para os teus backups e repositórios. Para mais informações, consulte Seguro por padrão com eliminação suave para Azure Backup.

• Os cofres imutáveis podem ajudá-lo a proteger os seus dados de backup bloqueando quaisquer operações que possam levar à perda de pontos de recuperação. Podes bloquear a configuração do cofre imutável para que fique irreversível. Também pode usar armazenamento WORM (write once, read many) para backups, para evitar que agentes maliciosos desativem a imutabilidade e eliminem backups. Para mais informações, consulte Immutable vault para Azure Backup.

Contrato de nível de serviço

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

O Azure Backup SLA cobre a disponibilidade do serviço tanto para operações de backup como de restauro. Para ser coberto pelo SLA, precisa de repetir os trabalhos de backup ou restauro falhados com uma frequência de pelo menos uma vez a cada trinta minutos.