Melhores práticas para recuperação de desastre com o Sincronização de Arquivos do Azure

  • Artigo

Na Sincronização de Arquivos do Azure, há três áreas principais a serem consideradas para recuperação de desastre: a alta disponibilidade, a proteção de dados/backup e a redundância de dados. Este artigo aborda cada área e ajuda a decidir qual configuração usar para sua própria solução de recuperação de desastres.

Em uma implantação da Sincronização de Arquivos do Azure, o ponto de extremidade de nuvem sempre contém uma cópia completa dos dados, enquanto o servidor local pode ser exibido como um cache descartável de seus dados. Em caso de um desastre no lado do servidor, você pode se recuperar ao provisionar um novo servidor, instalando o agente da Sincronização de Arquivos do Azure nele e configurando-o como um novo ponto de extremidade do servidor.

Devido à sua natureza híbrida, algumas estratégias tradicionais de backup e recuperação de desastres do servidor não funcionarão com a Sincronização de Arquivos do Azure. Para qualquer servidor registrado, não há suporte na Sincronização de Arquivos do Azure para:

Aviso

Realizar qualquer uma dessas ações pode levar a problemas com sincronização ou arquivos em camadas interrompidos que resultam em perda eventual de dados. Se você executou uma dessas ações, entre em contato com o Suporte do Azure para garantir que sua implantação esteja íntegra.

  • Transferir/clonar unidades de disco (volume) de um servidor para outro enquanto o ponto de extremidade do servidor ainda está ativo
  • Restaurar a partir de um backup do sistema operacional
  • Clonar o sistema operacional de um servidor para outro servidor
  • Reverter para um ponto de verificação de máquina virtual anterior
  • Restaurando arquivos em camadas do backup local (de terceiros) para o ponto de extremidade do servidor

Alta disponibilidade

Há duas estratégias diferentes que você pode usar para obter uma alta disponibilidade para o seu servidor local. Você pode configurar um cluster de failover ou configurar um servidor em espera. O fator decisivo para optar por uma dessas configurações é o quanto você está disposto a investir no seu sistema e se minimizar o período de tempo durante o qual seu sistema fica inativo em caso de um desastre vale o custo extra.

Para um cluster de failover, não é preciso realizar etapas especiais para usar a Sincronização de Arquivos do Azure. Para um servidor em espera, você deve fazer as seguintes configurações:

Ter um servidor secundário com pontos de extremidade de servidor diferentes que são sincronizados com o mesmo grupo de sincronização que o servidor primário, mas não habilitam o acesso do usuário final ao servidor. Isso permite que todos os arquivos sejam sincronizados do servidor primário para o servidor em espera. Você pode considerar habilitar a camada somente de namespace para que apenas o namespace seja baixado inicialmente. Se o servidor primário falhar, você pode usar o DFS-N para reconfigurar rapidamente o acesso do usuário final ao servidor em espera.

Proteção de dados/backup

Proteger seus dados reais é um componente fundamental de uma solução de recuperação de desastre. Há duas maneiras principais de fazer isso com seus compartilhamentos de arquivos do Azure: você pode fazer um backup dos seus dados na nuvem ou no local. É altamente recomendável que você faça um backup dos seus dados na nuvem porque seu ponto de extremidade na nuvem conterá uma cópia completa dos dados, enquanto os pontos de extremidade do servidor poderão conter apenas um subconjunto dos seus dados.

Faça o backup dos dados na nuvem

Você deve usar o Backup do Azure como solução de backup na nuvem. O Backup do Azure opera o agendamento, retenção e as restaurações de backup, entre outras coisas. Se preferir, você pode tirar instantâneos de compartilhamento manualmente e configurar sua própria solução de agendamento e retenção, mas isso não é o ideal. Como alternativa, você pode usar soluções de terceiros para fazer backup diretamente de seus compartilhamentos de arquivos do Azure.

Se ocorrer um desastre, você poderá restaurar de um instantâneo de compartilhamento, que é uma cópia somente leitura e pontual do seu compartilhamento de arquivos. Como são somente leitura, esses instantâneos não serão afetados por ransomware. Para grandes conjuntos de dados nos quais as operações de restauração do compartilhamento inteiro levam muito tempo, você pode habilitar o acesso direto dos usuários ao instantâneo de forma que possam copiar os dados de que precisam para seu drive local enquanto a restauração é executada.

Os instantâneos são armazenados diretamente no compartilhamento de arquivos do Azure, independentemente de você levá-los manualmente ou de o Backup do Azure levá-los para você. Por essa razão você deve habilitar a exclusão temporária para proteger seus instantâneos contra exclusões acidentais do seu compartilhamento de arquivos.

Para obter mais informações, consulte Sobre o backup do compartilhamento de arquivos do Azure ou contate seu provedor de backup para ver se ele dá suporte ao backup de compartilhamentos de arquivos do Azure.

Fazer backup dos dados locais

Se você habilitar a camada de nuvem, não implemente uma solução de backup local. Com a camada de nuvem habilitada, somente um subconjunto de seus dados será armazenado localmente no servidor, o restante dos dados será armazenado em seu ponto de extremidade na nuvem. Dependendo de qual solução de backup você usar para um backup local, os arquivos em camadas serão:

  • ignorados e não incluídos no backup (devido ao seu atributo FILE_ATTRIBUTE_RECALL_ONDATA_ACCESS); ou
  • incluídos no backup apenas como um arquivo em camadas, podendo não ficar acessíveis mediante a restauração devido a alterações no compartilhamento dinâmico; ou
  • recuperados para o seu disco, o que resultará em um preço muito alto para a saída.

Se decidir usar uma solução de backup local, você deverá executar os backups em um servidor no grupo de sincronização com a camada de nuvem desabilitada. Ao executar uma restauração, use as opções de restauração no nível do volume ou no nível do arquivo. Os arquivos restaurados usando a opção de restauração no nível do arquivo serão sincronizados em todos os pontos de extremidade no grupo de sincronização e os arquivos existentes serão substituídos pela versão restaurada do backup. As restaurações em nível de volume não substituirão as versões de arquivo mais recentes no ponto de extremidade na nuvem ou em outros pontos de extremidade de servidor.

Os Instantâneos do VSS (Serviço de Cópias de Sombra de Volume) (incluindo a guia Versões Anteriores) não são compatíveis com volumes com camada de nuvem habilitada. Isso permite que você execute restaurações de autoatendimento em vez de depender de um administrador para realizar restaurações para você. No entanto, você deve habilitar a compatibilidade de versão anterior por meio do PowerShell, o que aumentará os custos de armazenamento do instantâneo. Os instantâneos do VSS não protegem contra desastres no próprio ponto de extremidade do servidor, portanto, eles só devem ser usados junto aos backups do lado da nuvem. Para mais detalhes, confira Restauração de autoatendimento por meio de versões anteriores e do VSS.

Redundância de dados

Para garantir uma solução de recuperação de desastres robusta, adicione alguma forma de redundância de dados à sua infraestrutura. Existem quatro ofertas de redundância para Arquivos do Azure: Armazenamento com Redundância Local (LRS), o Armazenamento com Redundância de Zona (ZRS), Armazenamento com Redundância Geográfica (GRS) e Armazenamento com Redundância Geográfica e de Zona (GZRS).

  • LRS (armazenamento com redundância local) : com o LRS, cada arquivo é armazenado três vezes em um cluster de armazenamento do Azure. Isso fornece proteção contra a perda de dados devido a falhas de hardware, como uma unidade de disco defeituosa. No entanto, caso ocorra um desastre no data center, como um incêndio ou uma inundação, todas as réplicas de uma conta de armazenamento que use o LRS poderão ser perdidas ou se tornarem irrecuperáveis.
  • ZRS (armazenamento com redundância de zona) : com o ZRS, três cópias de cada arquivo armazenado, no entanto, essas cópias são fisicamente isoladas em três clusters de armazenamento distintos em diferentes zonas de disponibilidade do Azure. As zonas de disponibilidade são locais físicos exclusivos em uma região do Azure. Cada zona é composta por um ou mais data centers equipados com energia, resfriamento e rede independentes. Uma gravação no armazenamento não será aceita até que seja gravada nos clusters de armazenamento das três zonas de disponibilidade.
  • GRS (Armazenamento com redundância geográfica) : com o GRS, você tem duas regiões, uma região primária e uma secundária. Os arquivos são armazenados três vezes em um cluster de armazenamento do Azure na região primária. As gravações são replicadas de maneira assíncrona para uma região secundária definida pela Microsoft. O GRS fornece seis cópias de seus dados difundidos entre duas regiões do Azure.
  • GZRS (armazenamento com redundância de zona geográfica): você pode considerar o GZRS como se fosse como o ZRS, mas com redundância geográfica. Com o GZRS, os arquivos são armazenados três vezes em três clusters de armazenamento distintos na região primária. Todas as gravações depois são replicadas de maneira assíncrona para uma região secundária definida pela Microsoft.

Para uma solução de recuperação de desastres robusta, a maioria dos clientes deve considerar o ZRS. O ZRS adiciona a menor quantidade de custo extra para seus benefícios de redundância de dados adicionais e também é o mais simples no caso de uma interrupção. Se os requisitos regulatórios ou política da sua organização exigirem redundância geográfica para seus dados, considere o GRS ou o GZRS.

Redundância geográfica

Se a conta de armazenamento estiver configurada com a replicação GRS ou GZRS, a Microsoft iniciará o failover do Serviço de Sincronização de armazenamento se a região primária for considerada irrecuperável permanentemente ou não disponível por muito tempo. Nenhuma ação de sua parte é necessária na eventualidade de um desastre.

Embora seja possível solicitar um failover manualmente junto ao seu Serviço de Sincronização de Armazenamento para a sua região de GRS ou GZRS emparelhada, não recomendamos fazê-lo, a não ser no caso de uma indisponibilidade regional em grande escala, pois o processo não é simples e pode gerar custo extra. Para iniciar o processo, abra um tíquete de suporte e solicite que as suas contas de armazenamento do Azure que contêm o compartilhamento de arquivos do Azure e seu Serviço de Sincronização de Armazenamento sejam submetidas a failover.

Aviso

Se estiver iniciando esse processo manualmente, você deve entrar em contato com o suporte para solicitar que seu Serviço de Sincronização de Armazenamento seja submetido a failover. Tentar criar um novo Serviço de Sincronização de Armazenamento usando os mesmos pontos de extremidade de servidor na região secundária poderá resultar em dados adicionais permanecendo na sua conta de armazenamento porque o processo não irá limpar a instalação anterior da Sincronização de Arquivos do Azure.

Quando ocorrer um failover, os pontos de extremidade do servidor serão alternados para sincronizar com o ponto de extremidade na nuvem na região secundária automaticamente. No entanto, os pontos de extremidade do servidor devem se reconciliar com os pontos de extremidade na nuvem. Isso poderá resultar em conflitos de arquivo porque os dados da região secundária poderão não estar atualizados de acordo com a região primária.

Próximas etapas

Saiba mais sobre o backup do compartilhamento de arquivos do Azure