Confiabilidade no Azure Backup

Azure Backup é um serviço Azure incorporado que protege de forma segura cargas de trabalho na cloud e on-premises. O backup pode escalar a sua proteção em múltiplas cargas de trabalho e oferece 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, Ficheiros do Azure, Armazenamento de Blobs do Azure, Azure Data Lake Storage, discos geridos do Azure, volumes do Azure Elastic SAN e o Azure Kubernetes Service (AKS). Não precisas de gerir automação ou infraestrutura, escrever scripts ou provisionar armazenamento.

Quando se usa Azure, fiabilidade é uma responsabilidade partilhada. A Microsoft disponibiliza uma variedade de capacidades para apoiar a resiliência e a 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 potenciais falhas e problemas, incluindo falhas transitórias, interrupções em zonas de disponibilidade e interrupções regionais. Destaca também algumas informações-chave sobre o acordo de nível de serviço de backup (SLA).

Observação

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

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

Para fazer backup das suas cargas de trabalho em produção, recomendamos que configure o seu vault das seguintes formas:

  • Use armazenamento redundante por zona (ZRS) como o nível mínimo de redundância para os seus backups. O ZRS replica os seus backups em várias zonas de disponibilidade para que possa restaurar os seus backups durante uma interrupção na zona de disponibilidade.

  • Se usar armazenamento geo-redundante (GRS) para replicar as suas cópias de segurança para uma região Azure emparelhada, ative a restauração entre regiões (CRR) para fontes de dados suportadas. O CRR permite restaurar os backups na região emparelhada a qualquer momento.

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

Observação

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

Para uma lista de outras recomendações para Backup, incluindo recomendações focadas na fiabilidade, consulte Backup de cargas de trabalho em cloud e em instalações locais 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

O backup pode realizar cópias de segurança e restaurar várias fontes de dados. Configuras backups de forma diferente consoante a fonte de dados com que trabalhas. As seguintes fontes de dados são comuns:

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

O backup armazena os dados copiados em cofres. Os cofres são entidades de armazenamento online no Azure que armazenam dados, como cópias de backup, pontos de recuperação e políticas de backup. Os cofres de Serviços de Recuperação e os cofres de backup são dois tipos de cofres. Podes usar um ou ambos os tipos, dependendo do que precisas de proteger. Para uma lista das fontes de dados que cada tipo de cofre suporta, consulte as FAQ sobre os 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 para que possas monitorizar o progresso e resolver problemas que ocorrem durante as operações de backup e restauração. Também crias políticas de backup associadas aos trabalhos. As políticas especificam a configuração, como o cronograma de backup, e quanto tempo se pretende reter os dados.

Os cofres armazenam as suas políticas de backup e configuração juntamente com metadados sobre jobs, o que lhe permite acompanhar jobs e resolver problemas.

Arquitetura física

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

A cópia de segurança armazena os backups no repositório. Os Vaults 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 dados dentro do seu cofre para uma ou mais zonas de disponibilidade da Azure localizadas na região principal que escolher. Não podes escolher a tua zona de disponibilidade preferida, mas o Azure pode mover ou expandir contas LRS entre zonas para melhorar o balanceamento de carga. Os seus dados não têm garantia de serem distribuídos por zonas. Para mais informações, consulte Visão Geral das zonas de disponibilidade.

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

Observação

Algumas fontes de dados suportam backups em nível operacional , que armazenam os dados noutro local em vez de no vault. Por exemplo, backups de discos geridos Azure e cópias de segurança AKS suportam backups em tier operacional, que são armazenados em instantâneos de disco. Este artigo não aborda o armazenamento de backup em nível operacional, mas pode aplicar as orientações de resiliência deste artigo às operações e fluxos de trabalho de backup para estes tipos de backup.

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 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 verificar falhas repetidas, consulte Resolver Problemas das Operações de Gestão de Cofres de Backup.

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 backup gere, separadamente, a configuração da zona de disponibilidade do serviço e dos seus dados.

  • Serviço: O serviço de Backup é automaticamente resiliente em zonas nas regiões suportadas. 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 ZRS, cópias dos seus dados de backup são armazenadas automaticamente em múltiplas zonas de disponibilidade na região do Azure que utiliza.

    Se não usares o ZRS, os teus dados de backup são considerados não zonais e podem ser 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.

Diagrama que mostra o serviço central de Backup, que é automaticamente resiliente a zonas, e armazenamento de backup redundante por zona.

Requerimentos

Custo

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

Configurar o suporte à zona de disponibilidade

  • Crie um novo cofre que use ZRS: Configura a redundância de armazenamento quando criares um cofre. Siga etapas diferentes conforme o tipo de cofre. Para obter mais informações, consulte os seguintes artigos:

  • Configure o ZRS nos cofres existentes: Para cofres de backup, configura redundância de armazenamento quando criares o cofre. Depois de criares um cofre de backup, a definição fica bloqueada e não podes alterá-la.

    Para os cofres de Serviços de Recuperação, deve configurar a redundância de armazenamento antes de proteger todas as cargas de trabalho. Depois de protegeres uma carga de trabalho, a definição fica bloqueada e não podes alterá-la.

    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 Modificar definições predefinidas. É também responsável por apagar manualmente os pontos de recuperação existentes e outros dados, uma vez que as políticas de retenção do antigo cofre já não se aplicam. Para mais informações, consulte Eliminar um cofre de Backup ou Eliminar um cofre de Serviços de Recuperação.

Comportamento quando todas as zonas estão íntegras

Esta secção descreve o que esperar ao configurar cofres para ZRS, e todas as zonas estão operacionais.

  • Operação entre zonas: Os trabalhos de backup correm em infraestruturas replicadas entre zonas. O Azure gere trabalhos a partir de infraestruturas em qualquer zona.

  • Replicação de dados entre zonas: O ZRS replica dados copiados 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

Esta secção descreve o que esperar quando configurar cofres para Zona de Redundância de Armazenamento (ZRS), e há uma falha numa das zonas.

  • Deteção e resposta: Para o próprio serviço de Backup, Microsoft é responsável por detetar falhas nas zonas de disponibilidade e responder. Você não precisa fazer nada para iniciar um failover de zona.

    Importante

    Para quaisquer dados ou recursos que estejam indisponíveis devido à interrupção da zona, é responsável por detetar a interrupção e tomar as ações de recuperação, incluindo restaurar backups numa zona saudável.

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

    • Para quaisquer fontes de dados na zona de disponibilidade falhada, a falha da zona torna as fontes de dados indisponíveis. Os empregos ativos podem parar ou falhar.

    • Para quaisquer fontes de dados em zonas de disponibilidade saudável que executem trabalhos ativos, pode ocorrer um pequeno período de inatividade, normalmente alguns segundos, enquanto a plataforma muda 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 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 esperada de tempo de inatividade é também conhecida 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, estas podem não estar disponíveis até que a zona recupere. Os 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, pode ocorrer um pequeno período de inatividade, normalmente alguns segundos, enquanto a plataforma muda para zonas de disponibilidade saudáveis para o serviço de Backup.

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

    És responsável por restaurar o teu backup para a infraestrutura numa zona saudável e por reconfigurar 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 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 de backup gere o encaminhamento de tráfego, a replicação de dados, o "failover" e o "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 backup suporta geo-redundância e failover através de GRS e CRR.

Importante

GRS para Backup, só funciona dentro de regiões emparelhadas da Azure.

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

Para conseguir redundância regional para os seus dados de backup, use o Backup para replicar os seus backups para uma região emparelhada Azure usando GRS. O GRS protege os seus backups contra falhas regionais.

A região onde colocas o teu vault chama-se região principal. As suas fontes de dados devem estar localizadas na região principal. Não é possível configurar backups para um repositório noutra região.

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

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

Se não configurar o GRS e ocorrer uma falha na região do cofre, ainda podes 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 ocorrer uma falha na região principal. Se a sua fonte de dados suportar CRR, pode restaurar a partir de pontos de recuperação de regiões secundárias mesmo quando não ocorra falha na região primária. O CRR também permite realizar exercícios para avaliar a resiliência face a falhas regionais. Quando ligas o CRR, Microsoft atualiza o teu armazenamento de backup do GRS para armazenamento geo-redundante de acesso de leitura (RA-GRS).

Requerimentos

  • Suporte de região: GRS para Backup só funciona nas regiões emparelhadas do Azure.

  • Apenas novos cofres: Tens de configurar o GRS no teu cofre antes de fazer o primeiro backup.

Considerações

  • CRR: Depois de ativares o CRR, os itens de reserva podem demorar até 48 horas a estar 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. O CRR é cobrado a uma tarifa diferente porque a Microsoft atualiza o armazenamento do seu cofre de GRS para RA-GRS. Para mais informações, consulte Preços de backup.

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 ativar opcionalmente o CRR no vault. As etapas que segue dependem do tipo de cofre. Para obter mais informações, consulte os seguintes artigos:

  • Configure GRS e CRR em cofres existentes: Para cofres de backup, tens de configurar redundância de armazenamento ao criar o cofre.

    Para os cofres de Serviços de Recuperação, deve configurar a redundância de armazenamento antes de proteger todas as cargas de trabalho. Depois de uma carga de trabalho ser protegida, a definição fica bloqueada e não podes alterá-la.

    Podes ativar o CRR nos cofres GRS existentes. Depois de ativares o CRR, não podes desativá-lo.

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

Esta secção descreve o que esperar quando configuras os vaults para usarem GRS e todas as regiões estão operacionais.

  • Operação entre regiões: As cópias de segurança são sempre concluídas 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 configurares o vault para usar GRS, os backups são primeiro efetuados na região principal usando LRS. Após a conclusão bem-sucedida na região primária, os dados são replicados assíncronamente para a região secundária. A região secundária utiliza LRS para armazenar dados. Os dados de backup podem demorar até 12 horas a replicar da região primária para a secundária.

Comportamento durante uma interrupção regional

Esta secção descreve o que esperar quando configura os vaults para usar GRS e ocorre uma falha na região primária.

  • Deteção e resposta: Para fontes de dados que suportam CRR e onde o CRR está ativado no vault, pode iniciar o seu próprio CRR na região emparelhada a qualquer momento, incluindo durante uma falha ou desastre da região. És responsável por detetar a falha e tomar medidas 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 um desastre. O tempo que demora a declarar um desastre depende da gravidade do incidente e do tempo necessário para avaliar a situação. A Microsoft normalmente só declara um desastre após um período prolongado.

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

  • 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, espere 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é que a região recupere, pelo que o RTO é indefinido.

    • O backup pode não conseguir realizar operações de backup ou restauro na região falhada até que a região recupere, pelo que o RTO é indefinido.

    • Se usar CRR, o RTO para iniciar a restauração de backups já replicados na região emparelhada é zero. Se não usares CRR, o RTO depende de quanto tempo demora a Microsoft a declarar um desastre na região falhada.

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

    És responsável por restaurar o teu backup para a infraestrutura na região emparelhada e por reconfigurar 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 Backup restaura automaticamente as operações na região. O currículo e os dados de emprego continuam disponíveis.

Teste para falhas regionais

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

Resiliência à perda de dados de backup

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

  • A eliminação suave permite-lhe recuperar objetos e cofres apagados durante um período de retenção configurável. Por padrão, este período é de 14 dias, mas pode ser editado. Pensa na eliminação suave como um contentor de reciclagem para os teus backups e cofres. Para mais informações, consulte Configuração segura por defeito com eliminação suave para Backup.

  • Os cofres imutáveis podem ajudá-lo a proteger os seus dados de backup bloqueando 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 utilizar armazenamento WORM (write once, read many) para backups, a fim de evitar que atores maliciosos desativem a imutabilidade e eliminem os backups. Para mais informações, consulte Cofre Imutável para Cópia de Segurança.

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 SLA de Backup cobre a disponibilidade do serviço tanto para operações de backup como de restauro. Para estar coberto pelo SLA, tens de tentar novamente trabalhos de backup ou restauro falhados pelo menos uma vez a cada 30 minutos.

Conteúdo relacionado

  • Last updated on