Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
A Microsoft se esforça para garantir que os serviços do Azure estejam sempre disponíveis. No entanto, interrupções de serviço não planejadas podem ocorrer ocasionalmente. Os principais componentes de um bom plano de recuperação de desastres incluem estratégias para:
- Proteção de dados
- Cópia de segurança e restauro
- Redundância de dados
- Failover
- Projetando aplicativos para alta disponibilidade
Este artigo descreve as opções disponíveis para contas de armazenamento com redundância geográfica e fornece recomendações para desenvolver aplicativos altamente disponíveis e testar seu plano de recuperação de desastres.
Escolha a opção de redundância certa
O Armazenamento do Azure mantém várias cópias da sua conta de armazenamento para garantir que as metas de disponibilidade e durabilidade sejam atingidas, mesmo em caso de falhas. A forma como os dados são replicados proporciona diferentes níveis de proteção. Cada opção oferece os seus próprios benefícios, pelo que a opção escolhida depende do grau de resiliência que as suas aplicações exigem.
O LRS (Locally Redundant Storage, armazenamento com redundância local), a opção de redundância de menor custo, armazena e replica automaticamente três cópias da sua conta de armazenamento em um único datacenter. Embora o LRS proteja seus dados contra falhas de rack e drive do servidor, ele não leva em conta desastres como incêndio ou inundação dentro de um datacenter. Diante desses desastres, todas as réplicas de uma conta de armazenamento configurada para usar o LRS podem ser perdidas ou irrecuperáveis.
Em comparação, o ZRS (armazenamento com redundância de zona) retém uma cópia de uma conta de armazenamento e a replica em cada uma das três zonas de disponibilidade separadas dentro da mesma região. Para obter mais informações sobre zonas de disponibilidade, consulte Zonas de disponibilidade do Azure.
Geo-redundant storage and failover
O armazenamento com redundância geográfica (GRS), o armazenamento com redundância de zona geográfica (GZRS) e o armazenamento com redundância de zona geográfica de acesso de leitura (RA-GZRS) são exemplos de opções de armazenamento com redundância geográfica. Quando configurado para usar armazenamento com redundância geográfica (GRS, GZRS e RA-GZRS), o Azure copia seus dados de forma assíncrona para uma região geográfica secundária. Essas regiões estão localizadas a centenas, ou mesmo milhares de quilômetros de distância. Esse nível de redundância permite que você recupere seus dados se houver uma interrupção em toda a região principal.
Ao contrário do LRS e do ZRS, o armazenamento com redundância geográfica também fornece suporte para um failover não planejado para uma região secundária se houver uma interrupção na região primária. Durante o processo de failover, as entradas DNS (Sistema de Nomes de Domínio) para seus pontos de extremidade de serviço de conta de armazenamento são atualizadas automaticamente para que os pontos de extremidade da região secundária se tornem os novos pontos de extremidade primários. Once the unplanned failover is complete, clients can begin writing to the new primary endpoints.
Read-access geo-redundant storage (RA-GRS) and read-access geo-zone-redundant storage (RA-GZRS) also provide geo-redundant storage, but offer the added benefit of read access to the secondary endpoint. Essas opções são ideais para soluções projetadas para aplicações críticas de negócios com alta disponibilidade. Se o ponto de extremidade primário sofrer uma interrupção, os aplicativos configurados para acesso de leitura à região secundária poderão continuar a operar. A Microsoft recomenda o RA-GZRS para máxima disponibilidade e durabilidade de suas contas de armazenamento.
Para obter mais informações sobre redundância para o Armazenamento do Azure, consulte Redundância do Armazenamento do Azure.
Plan for failover
As contas de Armazenamento do Azure dão suporte a três tipos de failover:
- Customer-managed planned failover (preview) - Customers can manage storage account failover to test their disaster recovery plan.
- Customer-managed (unplanned) failover - Customers can manage storage account failover if there's an unexpected service outage.
- Failover gerido pela Microsoft - Potencialmente iniciado pela Microsoft devido a um desastre grave na região principal. 1,2
1 O failover gerenciado pela Microsoft não pode ser iniciado para contas de armazenamento, assinaturas ou locatários individuais. For more information, see Microsoft-managed failover.
2 Use opções de failover gerenciadas pelo cliente para desenvolver, testar e implementar seus planos de recuperação de desastres.
Não confie no failover gerenciado pela Microsoft, que só seria usado em circunstâncias extremas.
Cada tipo de failover tem um conjunto exclusivo de casos de uso, expectativas correspondentes para perda de dados e suporte para contas com um namespace hierárquico habilitado (Armazenamento Azure Data Lake). Esta tabela resume os aspetos de cada tipo de failover:
| Tipo | Failover Scope | Caso de utilização | Perda de dados esperada | Hierarchical Namespace (HNS) supported |
|---|---|---|---|---|
| Customer-managed planned failover (preview) | Conta de armazenamento | The storage service endpoints for the primary and secondary regions are available, and you want to perform disaster recovery testing. The storage service endpoints for the primary region are available, but another service is preventing your workloads from functioning properly. Preparar-se proativamente para desastres de grande escala, como um furacão, que possam afetar uma região. |
Não | Yes (Em pré-visualização) |
| Falha no sistema (não planejada) sob gestão do cliente | Conta de armazenamento | Os pontos de extremidade do serviço de armazenamento para a região primária ficam indisponíveis, mas a região secundária está disponível. Você recebeu um Comunicado do Azure no qual a Microsoft o aconselha a executar uma operação de failover de contas de armazenamento potencialmente afetadas por uma interrupção. |
Sim | Yes |
| Gerenciado pela Microsoft | Toda a região | A região primária torna-se indisponível devido a um desastre significativo, mas a região secundária está disponível. | Sim | Yes |
A tabela a seguir compara o estado de redundância de uma conta de armazenamento após cada tipo de failover:
| Result of failover on... | Customer-managed planned failover (preview) | Falha no sistema (não planejada) sob gestão do cliente |
|---|---|---|
| ... a região secundária | A região secundária torna-se a nova região primária | A região secundária torna-se a nova região primária |
| ... a região primária original | A região primária original torna-se a nova região secundária | A cópia dos dados na região primária original é excluída |
| ...the account redundancy configuration | A conta de armazenamento é convertida em GRS | A conta de armazenamento é convertida em LRS |
| ...the geo-redundancy configuration | A redundância geográfica é mantida | Perde-se a redundância geográfica |
The following table summarizes the resulting redundancy configuration at every stage of the failover and failback process for each type of failover:
| Original configuração |
After failover |
After re-enabling geo redundancy |
After failback |
After re-enabling geo redundancy |
|---|---|---|---|---|
| Customer-managed planned failover | ||||
| GRS | GRS | n/a 1 | GRS | n/a 1 |
| GZRS | GRS | n/a 1 | GZRS | n/a 1 |
| Failover não planeado gerido pelo cliente | ||||
| GRS | LRS | GRS | LRS | GRS |
| GZRS | LRS | GRS | ZRS | GZRS |
1 A redundância geográfica é mantida durante um failover planejado e não precisa ser reconfigurada manualmente.
Customer-managed planned failover (preview)
Planned failover can be utilized in multiple scenarios including planned disaster recovery testing, a proactive approach to large scale disasters, or to recover from nonstorage related outages.
During the planned failover process, the primary and secondary regions are swapped. A região primária original é rebaixada e torna-se a nova região secundária. Ao mesmo tempo, a região secundária original é promovida e torna-se a nova primária. Após a conclusão do failover, os usuários podem continuar a acessar os dados na nova região primária e os administradores podem validar seu plano de recuperação de desastres. A conta de armazenamento deve estar disponível nas regiões primária e secundária antes que um failover planejado possa ser iniciado.
Data loss isn't expected during the planned failover and failback process as long as the primary and secondary regions are available throughout the entire process. Para obter mais detalhes, consulte a seção Antecipando perda de dados e inconsistências .
To understand the effect of this type of failover on your users and applications, it's helpful to know what happens during every step of the planned failover and failback processes. Para obter detalhes sobre como esse processo funciona, consulte Como funciona o failover gerenciado pelo cliente (planejado).
Important
Customer-managed planned failover is currently in PREVIEW and limited to the following regions:
- Ásia Leste
- Sudeste Asiático
- Leste da Austrália
- Austrália Sudeste
- França Central
- Sul de França
- Índia Central
- Oeste da Índia
- Oeste da Suíça
- Norte da Suíça
Para aceitar a visualização, consulte Configurar recursos de visualização na assinatura do Azure e especifique AllowSoftFailover como o nome do recurso. O nome do provedor para esse recurso de visualização é Microsoft.Storage.
Veja Termos de Utilização Complementares da Pré-visualização do Microsoft Azure para obter os termos legais que se aplicam aos recursos do Azure que estão na versão beta, na pré-visualização ou que ainda não foram lançados para disponibilidade geral.
Important
Após um failover planejado, o valor LST (Last Sync Time) de uma conta de armazenamento pode parecer obsoleto ou ser relatado como NULL quando os dados do Azure Files estiverem presentes.
System snapshots are periodically created in a storage account's secondary region to maintain consistent recovery points used during failover and failback. A iniciação de um failover planeado gerido pelo cliente resulta na transformação da região primária original na nova secundária. In some cases, there are no system snapshots available on the new secondary after the planned failover completes, causing the account's overall LST value to appear stale or be displayed as Null.
Como as atividades do usuário, como criar, modificar ou excluir objetos, podem acionar a criação de instantâneos, qualquer conta na qual essas atividades ocorram após o failover planejado não exigirá atenção adicional. However, accounts having no snapshots or user activity may continue to display a Null LST value until system snapshot creation is triggered.
Se necessário, execute uma das seguintes atividades para cada compartilhamento em uma conta de armazenamento para acionar a criação de instantâneos. Após a conclusão, sua conta deve exibir um valor de LST válido dentro de 30 minutos.
- Monte o compartilhamento e abra qualquer arquivo para leitura.
- Carregue um arquivo de teste ou exemplo para o compartilhamento.
Falha no sistema (não planejada) sob gestão do cliente
If the data endpoints for the storage services in your storage account become unavailable in the primary region, you can initiate an unplanned failover to the secondary region. Após a conclusão do failover, a região secundária torna-se a nova primária e os utilizadores podem continuar a aceder aos dados.
To understand the effect of this type of failover on your users and applications, it's helpful to know what happens during every step of the unplanned failover and failback process. Para obter detalhes sobre como o processo funciona, consulte Como funciona o failover gerenciado pelo cliente (não planejado).
Failover gerenciado pela Microsoft
A Microsoft pode iniciar um failover regional em circunstâncias extremas, como um desastre catastrófico que afeta toda uma região geográfica. Durante estes eventos, nenhuma ação da sua parte é necessária. Se sua conta de armazenamento estiver configurada para RA-GRS ou RA-GZRS, seus aplicativos poderão ler a partir da região secundária durante um failover gerenciado pela Microsoft. However, you don't have write access to your storage account until the failover process is complete.
Important
Use opções de failover gerenciadas pelo cliente para desenvolver, testar e implementar seus planos de recuperação de desastres. Não confie no failover gerenciado pela Microsoft, que só pode ser usado em circunstâncias extremas. Um failover gerenciado pela Microsoft seria iniciado para uma unidade física inteira, como uma região ou um datacenter. Não pode ser iniciado para contas de armazenamento individuais, subscrições ou inquilinos. If you need the ability to selectively failover your individual storage accounts, use customer-managed planned failover.
Antecipe a perda de dados e inconsistências
Atenção
O failover imprevisto gerido pelo cliente geralmente implica alguma perda de dados e também pode potencialmente causar inconsistências de arquivos e dados. In your disaster recovery plan, it's important to consider the impact that an account failover would have on your data before initiating one.
Como os dados são gravados de forma assíncrona da região primária para a região secundária, há sempre um atraso antes que uma gravação na região primária seja copiada para a secundária. If the primary region becomes unavailable, it's possible that the most recent writes might not yet be copied to the secondary.
Quando ocorre um failover não planejado, todos os dados na região primária são perdidos à medida que a região secundária se torna a nova primária. Todos os dados já copiados para a região secundária são mantidos quando o failover acontece. No entanto, quaisquer dados gravados no primário que ainda não existam na região secundária são perdidos permanentemente.
A nova região primária é configurada para ser localmente redundante (LRS) após o failover.
Você também pode enfrentar inconsistências de arquivos ou dados se suas contas de armazenamento tiverem uma ou mais das seguintes opções habilitadas:
- Espaço de nomes hierárquico (Armazenamento Azure Data Lake)
- Change feed
- Point-in-time restore for block blobs
Hora da última sincronização
A propriedade Last Sync Time indica a hora mais recente em que os dados da região primária também foram gravados na região secundária. Para contas que têm um namespace hierárquico, a mesma propriedade Last Sync Time também se aplica aos metadados gerenciados pelo namespace hierárquico, incluindo listas de controle de acesso (ACLs). Todos os dados e metadados gravados antes da última hora de sincronização estão disponíveis no secundário. Por outro lado, os dados e metadados gravados após o último tempo de sincronização podem ainda não ser copiados para o secundário e podem ser perdidos. Durante uma interrupção, use essa propriedade para estimar a quantidade de perda de dados que você pode incorrer ao iniciar um failover de conta.
Como prática recomendada, projete seu aplicativo para que você possa usar o Tempo de Última Sincronização para avaliar a perda de dados esperada. Por exemplo, registrar todas as operações de gravação permite comparar os tempos da última operação de gravação com o último tempo de sincronização. This method enables you to determine which writes aren't yet synced to the secondary and are in danger of being lost.
Para obter mais informações sobre como verificar a propriedade Last Sync Time , consulte Verifique a propriedade Last Sync Time para uma conta de armazenamento.
File consistency for Azure Data Lake Storage
A replicação para contas de armazenamento com um namespace hierárquico habilitado (Armazenamento Azure Data Lake) ocorre no nível do arquivo. Como a replicação ocorre nesse nível, uma interrupção na região primária pode impedir que alguns dos arquivos dentro de um contêiner ou diretório sejam replicados com êxito para a região secundária. A consistência de todos os arquivos dentro de um contêiner ou diretório após um failover de conta de armazenamento não é garantida.
Change feed and blob data inconsistencies
Customer-managed (unplanned) failover of storage accounts with change feed enabled could result in inconsistencies between the change feed logs and the blob data and/or metadata. Essas inconsistências podem resultar da natureza assíncrona das atualizações do log de alterações e da replicação de dados entre as regiões primária e secundária. Pode evitar inconsistências tomando as seguintes precauções:
- Ensure that all log records are flushed to the log files.
- Certifique-se de que todos os dados de armazenamento sejam replicados da região primária para a secundária.
Para obter mais informações sobre o feed de alterações, consulte Como funciona o feed de alterações.
Lembre-se de que outros recursos da conta de armazenamento também exigem que o feed de alterações seja habilitado. These features include operational backup of Azure Blob Storage, Object replication, and Point-in-time restore for block blobs.
Point-in-time restore inconsistencies
Customer-managed failover is supported for general-purpose v2 standard tier storage accounts that include block blobs. However, performing a customer-managed failover on a storage account resets the earliest possible restore point for the account. Data for Point-in-time restore for block blobs is only consistent up to the failover completion time. As a result, you can only restore block blobs to a point in time no earlier than the failover completion time. Você pode verificar o tempo de conclusão do failover na guia redundância da sua conta de armazenamento no portal do Azure.
The time and cost of failing over
O tempo necessário para que um failover gerenciado pelo cliente seja concluído após ser iniciado pode variar, embora normalmente leve menos de uma hora.
A planned customer-managed failover doesn't lose its geo-redundancy after a failover and subsequent failback, but an unplanned customer-managed failover does.
Iniciar um failover não planejado gerenciado pelo cliente converte automaticamente sua conta de armazenamento em LRS (armazenamento com redundância local) em uma nova região primária e exclui a conta de armazenamento na região primária original.
You can re-enable geo-redundant storage (GRS) or read-access geo-redundant storage (RA-GRS) for the account, but re-replicating data to the new secondary region incurs a charge. Additionally, any archived blobs need to be rehydrated to an online tier before the account can be reconfigured for geo-redundancy. Esta reidratação também implica um custo adicional. Para obter mais informações sobre preços, consulte:
Depois de reativar o GRS para sua conta de armazenamento, a Microsoft começa a replicar os dados em sua conta para a nova região secundária. O tempo necessário para a conclusão da replicação depende de vários fatores. Esses fatores incluem:
- O número e o tamanho dos objetos na conta de armazenamento. Replicar muitos objetos pequenos pode levar mais tempo do que replicar menos objetos e maiores.
- Os recursos disponíveis para replicação em segundo plano, como CPU, memória, disco e capacidade WAN. O tráfego em tempo real tem prioridade sobre a replicação geográfica.
- The number of snapshots per blob, if applicable.
- A estratégia de particionamento de dados, se sua conta de armazenamento contiver tabelas. O processo de replicação não pode ser dimensionado além do número de chaves de partição que você usa.
Tipos de conta de armazenamento suportados
Todas as ofertas com redundância geográfica suportam failover gerenciado pela Microsoft. In addition, some account types support customer-managed account failover, as shown in the following table:
| Type of failover | GRS/RA-GRS | GZRS/RA-GZRS |
|---|---|---|
| Customer-managed planned failover (preview) | General-purpose v2 accounts General-purpose v1 accounts Legacy Blob Storage accounts |
General-purpose v2 accounts |
| Failover não planeado gerido pelo cliente | General-purpose v2 accounts General-purpose v1 accounts Legacy Blob Storage accounts |
General-purpose v2 accounts |
| Failover gerenciado pela Microsoft | Todos os tipos de conta | General-purpose v2 accounts |
Contas de armazenamento clássicas
Important
O failover gerenciado pelo cliente só é suportado para contas de armazenamento implantadas usando o modelo de implantação do Azure Resource Manager (ARM). O modelo de implantação do Azure Service Manager (ASM), também conhecido como modelo clássico , não é suportado. Para tornar as contas de armazenamento clássicas elegíveis para failover para contas geridas por clientes, devem primeiro ser migradas para o modelo ARM. Sua conta de armazenamento deve estar acessível para executar a atualização, para que a região primária não possa estar atualmente em um estado de falha.
Durante um desastre que afete a região principal, a Microsoft gerenciará o failover para contas de armazenamento clássicas. For more information, see Microsoft-managed failover.
Funcionalidades e serviços não suportados
Os seguintes recursos e serviços não são suportados para failover gerenciado pelo cliente:
- Azure File Sync doesn't support customer-managed account failover. Storage accounts used as cloud endpoints for Azure File Sync shouldn't be failed over. O failover interrompe a sincronização de arquivos e pode causar a perda inesperada de dados de arquivos recém-hierarquizados. Para obter mais informações, consulte Práticas recomendadas para recuperação de desastres com o Azure File Sync para obter detalhes.
- A storage account containing premium block blobs can't be failed over. Atualmente, as contas de armazenamento que suportam blobs de bloco premium não suportam redundância geográfica.
- Customer-managed failover isn't supported for either the source or the destination account in an object replication policy.
- Network File System (NFS) 3.0 (NFSv3) isn't supported for storage account failover. Não é possível criar uma conta de armazenamento configurada para redundância geográfica com NFSv3 habilitado.
A tabela a seguir pode ser usada para fazer referência ao suporte a recursos.
| Planned failover | Unplanned failover | |
|---|---|---|
| Azure Data Lake Storage | Suportado (versão preliminar) | Suportado |
| Change Feed | Não suportado | Suportado |
| Replicação de objetos | Não suportado | Não suportado |
| SFTP | Suportado (versão preliminar) | Suportado |
| NFSv3 | O GRS não é suportado | O GRS não é suportado |
| Ações de armazenamento | Supported1 | Supported1 |
| Point-in-time restore (PITR) | Não suportado | Suportado |
1 If you initiate a customer-managed planned or unplanned failover, storage tasks can't operate on the account until it fails back to the original primary region. Mais informações.
Failover isn't for account migration
Storage account failovers are a temporary solution used to develop and test your disaster recovery (DR) plans, or to recover from a service outage. Failover shouldn't be used as part of your data migration strategy. Para obter informações sobre como migrar suas contas de armazenamento, consulte Visão geral da migração do Armazenamento do Azure.
Contas de armazenamento que contêm blobs arquivados
Storage accounts containing archived blobs support account failover. However, after a customer-managed failover is complete, all archived blobs must be rehydrated to an online tier before the account can be configured for geo-redundancy.
Fornecedor de recursos de armazenamento
A Microsoft fornece duas APIs REST para trabalhar com recursos de Armazenamento do Azure. Essas APIs formam a base de todas as ações que você pode executar no Armazenamento do Azure. A API REST do Armazenamento do Azure permite que você trabalhe com dados em sua conta de armazenamento, incluindo dados de blob, fila, arquivo e tabela. A API REST do provedor de recursos de Armazenamento do Azure permite gerenciar a conta de armazenamento e os recursos relacionados.
Após a conclusão de um failover, os clientes podem ler e gravar novamente os dados do Armazenamento do Azure na nova região primária. No entanto, o provedor de recursos de Armazenamento do Azure não faz failover, portanto, as operações de gerenciamento de recursos ainda devem ocorrer na região primária. Se a região principal não estiver disponível, você não poderá executar operações de gerenciamento na conta de armazenamento.
Como o provedor de recursos de Armazenamento do Azure não faz failover, a propriedade Location retornará o local primário original após a conclusão do failover.
Máquinas virtuais do Azure
Azure virtual machines (VMs) don't fail over as part of a storage account failover. Any VMs that failed over to a secondary region in response to an outage need to be recreated after the failover completes. O failover de conta pode potencialmente resultar na perda de dados armazenados em um disco temporário quando a máquina virtual (VM) é desligada. A Microsoft recomenda seguir as diretrizes de alta disponibilidade e recuperação de desastres específicas para máquinas virtuais no Azure.
Azure unmanaged disks
Os discos não gerenciados são armazenados como blobs de página no Armazenamento do Azure. Quando uma VM está em execução no Azure, todos os discos não gerenciados anexados à VM são alugados. An account failover can't proceed when there's a lease on a blob. Antes que um failover possa ser iniciado em uma conta que contenha discos não gerenciados anexados a VMs do Azure, os discos devem ser desligados. Por esse motivo, as práticas recomendadas pela Microsoft incluem a conversão de quaisquer discos não gerenciados em discos gerenciados.
Para executar um failover em uma conta que contém discos não gerenciados, execute estas etapas:
- Antes de começar, observe os nomes de quaisquer discos não gerenciados, seus números de unidade lógica (LUN) e a VM à qual eles estão conectados. Isso facilitará a reconexão dos discos após o failover.
- Desligue a máquina virtual.
- Exclua a VM, mas mantenha os arquivos de disco rígido virtual (VHD) para os discos não gerenciados. Observe o momento em que você excluiu a VM.
- Aguarde até que o Último Tempo de Sincronização seja atualizado e verifique se é posterior ao momento em que você excluiu a VM. Esta etapa garante que o endpoint secundário esteja totalmente atualizado com os arquivos VHD quando ocorrer o failover e que a VM funcione corretamente na nova região primária.
- Initiate the account failover.
- Wait until the account failover is complete and the secondary region becomes the new primary region.
- Crie uma VM na nova região primária e reconecte os VHDs.
- Inicie a nova VM.
Lembre-se de que todos os dados armazenados em um disco temporário são perdidos quando a VM é desligada.
Copying data as a failover alternative
Conforme discutido anteriormente, você pode manter a alta disponibilidade configurando aplicativos para usar uma conta de armazenamento configurada para acesso de leitura a uma região secundária. However, if you prefer not to fail over during an outage within the primary region, you can manually copy your data as an alternative. Ferramentas como AzCopy e Azure PowerShell permitem que você copie dados de sua conta de armazenamento na região afetada para outra conta de armazenamento em uma região não afetada. Após a conclusão da operação de cópia, você pode reconfigurar seus aplicativos para usar a conta de armazenamento na região não afetada para disponibilidade de leitura e gravação.
Desenhar para alta disponibilidade
É importante projetar seu aplicativo para alta disponibilidade desde o início. Consulte estes recursos do Azure para obter orientação ao projetar seu aplicativo e planejar a recuperação de desastres:
- Projetando aplicativos resilientes para o Azure: uma visão geral dos principais conceitos para arquitetar aplicativos altamente disponíveis no Azure.
- Lista de verificação de resiliência: uma lista de verificação para verificar se seu aplicativo implementa as práticas recomendadas de design para alta disponibilidade.
- Use geo-redundancy to design highly available applications: Design guidance for building applications to take advantage of geo-redundant storage.
- Tutorial: Crie uma aplicação altamente disponível com armazenamento de Blobs: Este tutorial ensina a criar uma aplicação altamente disponível que alterna automaticamente entre endpoints quando falhas e recuperações são simuladas.
Consulte estas práticas recomendadas para manter a alta disponibilidade para seus dados de Armazenamento do Azure:
- Discos: use o Backup do Azure para fazer backup dos discos de VM usados por suas máquinas virtuais do Azure. Considere também usar o Azure Site Recovery para proteger suas VMs de um desastre regional.
- Block blobs: Turn on soft delete to protect against object-level deletions and overwrites, or copy block blobs to another storage account in a different region using AzCopy, Azure PowerShell, or the Azure Data Movement library.
- Arquivos: use o Backup do Azure para fazer backup de seus compartilhamentos de arquivos. Também habilite a exclusão suave para proteger contra exclusões acidentais de compartilhamento de arquivos. Para redundância geográfica quando o GRS não estiver disponível, use o AzCopy ou o Azure PowerShell para copiar seus arquivos para outra conta de armazenamento em uma região diferente.
- Tabelas: Use o AzCopy para exportar dados de tabela para outra conta de armazenamento em uma região diferente.
Track outages
Os clientes podem subscrever o Painel de Estado de Funcionamento do Serviço do Azure para controlar o estado de funcionamento e o estado do Armazenamento do Azure e de outros serviços do Azure.
A Microsoft também recomenda que desenhe a sua aplicação de modo a estar preparado para possíveis falhas de escrita. A aplicação deve expor as falhas de escrita de forma a alertá-lo para a possibilidade de uma interrupção na região primária.