Melhores práticas para a recuperação após desastre com Azure File Sync

  • Artigo

Para Azure File Sync, existem três áreas principais a considerar para a recuperação após desastre: elevada disponibilidade, proteção de dados/cópia de segurança e redundância de dados. Este artigo abrange cada área e ajuda-o a decidir que configuração deve utilizar para a sua própria solução de recuperação após desastre.

Numa implementação Azure File Sync, o ponto final da cloud contém sempre uma cópia completa dos seus dados, enquanto o servidor no local pode ser visto como uma cache descartável dos seus dados. Em caso de desastre do lado do servidor, pode recuperar ao aprovisionar um novo servidor, instalar o agente Azure File Sync no mesmo e configurá-lo como um novo ponto final do servidor.

Devido à sua natureza híbrida, algumas estratégias tradicionais de cópia de segurança do servidor e recuperação após desastre não funcionarão com Azure File Sync. Para qualquer servidor registado, Azure File Sync não suporta:

Aviso

A realização de qualquer uma destas ações pode originar problemas com ficheiros em camadas sincronizados ou danificados que resultem numa eventual perda de dados. Se tiver realizado uma destas ações, contacte suporte do Azure para garantir que a implementação está em bom estado de funcionamento.

  • Transferir/clonar unidades de disco (volume) de um servidor para outro enquanto o ponto final do servidor ainda está ativo
  • Restaurar a partir de uma cópia de segurança do sistema operativo
  • Clonar o sistema operativo de um servidor para outro servidor
  • Reverter para um ponto de verificação de máquina virtual anterior
  • Restaurar ficheiros em camadas a partir da cópia de segurança no local (de terceiros) para o ponto final do servidor

Elevada disponibilidade

Existem duas estratégias diferentes que pode utilizar para obter elevada disponibilidade para o seu servidor no local. Pode configurar um cluster de ativação pós-falha ou configurar um servidor de reserva. O fator decisivo entre qualquer uma das configurações é quanto está disposto a investir no seu sistema e, se minimizar o período de tempo em que o seu sistema está inativo em caso de desastre, vale esse custo extra.

Para um cluster de ativação pós-falha, não precisa de seguir passos especiais para utilizar Azure File Sync. Para um servidor de reserva, deve efetuar as seguintes configurações:

Tenha um servidor secundário com pontos finais de servidor diferentes que são sincronizados com o mesmo grupo de sincronização que o servidor primário, mas não permitem o acesso do utilizador final ao servidor. Isto permite que todos os ficheiros sincronizem do servidor primário para o servidor de reserva. Pode considerar a ativação de camadas apenas de espaço de nomes para que apenas o espaço de nomes seja transferido inicialmente. Se o servidor primário falhar, pode utilizar DFS-N para reconfigurar rapidamente o acesso do utilizador final ao servidor de reserva.

Proteção/cópia de segurança de dados

Proteger os seus dados reais é um componente fundamental de uma solução de recuperação após desastre. Existem duas formas principais de o fazer com as partilhas de ficheiros do Azure: pode fazer uma cópia de segurança dos seus dados na cloud ou no local. Recomendamos vivamente que faça uma cópia de segurança dos seus dados na cloud, uma vez que o ponto final da cloud irá conter uma cópia completa dos seus dados, enquanto os pontos finais do servidor podem conter apenas um subconjunto dos seus dados.

Fazer uma cópia de segurança dos seus dados na cloud

Deve utilizar Azure Backup como solução de cópia de segurança na cloud. Azure Backup processa o agendamento, a retenção e os restauros de cópias de segurança, entre outras coisas. Se preferir, pode tirar instantâneos de partilha manualmente e configurar a sua própria solução de agendamento e retenção, mas isto não é o ideal. Em alternativa, pode utilizar soluções de terceiros para fazer uma cópia de segurança direta das partilhas de ficheiros do Azure.

Se ocorrer um desastre, pode restaurar a partir de um instantâneo de partilha, que é uma cópia só de leitura para um ponto anterior no tempo da partilha de ficheiros. Uma vez que estes instantâneos são só de leitura, não serão afetados por ransomware. Para grandes conjuntos de dados em que as operações de restauro de partilha completa demoram muito tempo, pode permitir o acesso direto do utilizador ao instantâneo para que os utilizadores possam copiar os dados de que precisam para a unidade local enquanto o restauro é concluído.

Os instantâneos são armazenados diretamente na partilha de ficheiros do Azure, independentemente de os utilizar manualmente ou se Azure Backup os utiliza. Por isso, deve ativar a eliminação recuperável para proteger os seus instantâneos contra a eliminação acidental da partilha de ficheiros.

Para obter mais informações, veja Acerca da cópia de segurança da partilha de ficheiros do Azure ou contacte o fornecedor de cópias de segurança para ver se suportam a cópia de segurança de partilhas de ficheiros do Azure.

Fazer uma cópia de segurança dos seus dados no local

Se ativar o arrumo na cloud, não implemente uma solução de cópia de segurança no local. Com o arrumo na cloud ativado, apenas um subconjunto dos seus dados será armazenado localmente no servidor, os restantes dados são armazenados no ponto final da cloud. Dependendo da solução de cópia de segurança que utiliza para uma cópia de segurança local, os ficheiros em camadas serão:

  • ignorou e não efetuou uma cópia de segurança (devido ao respetivo FILE_ATTRIBUTE_RECALL_ONDATA_ACCESS atributo) ou
  • só será efetuada uma cópia de segurança como um ficheiro em camadas e poderá não estar acessível após o restauro devido a alterações na partilha em direto ou
  • serão relembradas para o disco, o que resultará em custos de saída elevados.

Se decidir utilizar uma solução de cópia de segurança no local, deve efetuar cópias de segurança num servidor no grupo de sincronização com o arrumo na cloud desativado. Ao efetuar um restauro, utilize as opções de restauro ao nível do volume ou ao nível do ficheiro. Os ficheiros restaurados com a opção de restauro ao nível do ficheiro serão sincronizados com todos os pontos finais no grupo de sincronização e os ficheiros existentes serão substituídos pela versão restaurada a partir da cópia de segurança. Os restauros ao nível do volume não substituem as versões de ficheiro mais recentes no ponto final da cloud ou noutros pontos finais do servidor.

Os instantâneos do Serviço de Cópia Sombra de Volumes (VSS) (incluindo o separador Versões Anteriores) são suportados em volumes com o arrumo na cloud ativado. Isto permite-lhe efetuar restauros self-service em vez de depender de um administrador para efetuar restauros por si. No entanto, tem de ativar a compatibilidade de versões anteriores através do PowerShell, o que irá aumentar os custos de armazenamento de instantâneos. Os instantâneos do VSS não protegem contra desastres no próprio ponto final do servidor, pelo que só devem ser utilizados juntamente com as cópias de segurança do lado da cloud. Para obter detalhes, veja Restauro self-service através de Versões Anteriores e VSS.

Redundância de dados

Para garantir uma solução robusta de recuperação após desastre, adicione alguma forma de redundância de dados à sua infraestrutura. Existem quatro ofertas de redundância para Ficheiros do Azure: armazenamento localmente redundante (LRS),armazenamento com redundância entre zonas (ZRS),armazenamento georredundante (GRS) e armazenamento com georredundância entre zonas (GZRS).

  • Armazenamento localmente redundante (LRS): com o LRS, cada ficheiro é armazenado três vezes num cluster de armazenamento do Azure. Isto protege contra a perda de dados devido a falhas de hardware, como uma unidade de disco incorreta. No entanto, se ocorrer um desastre como incêndio ou inundação no datacenter, todas as réplicas de uma conta de armazenamento com LRS poderão ser perdidas ou irrecuperáveis.
  • Armazenamento com redundância entre zonas (ZRS): com o ZRS, são armazenadas três cópias de cada ficheiro. No entanto, estas cópias estão fisicamente isoladas em três clusters de armazenamento distintos em diferentes zonas de disponibilidade do Azure. As zonas de disponibilidade são localizações físicas exclusivas numa região do Azure. Cada zona é composta por um ou mais datacenters equipados com energia, refrigeração e rede independentes. Uma escrita no armazenamento não é aceite até ser escrita nos clusters de armazenamento nas três zonas de disponibilidade.
  • Armazenamento georredundante (GRS): com o GRS, tem duas regiões, uma região primária e secundária. Os ficheiros são armazenados três vezes num cluster de armazenamento do Azure na região primária. As escritas são replicadas de forma assíncrona para uma região secundária definida pela Microsoft. O GRS fornece seis cópias dos seus dados distribuídos entre duas regiões do Azure.
  • Armazenamento com redundância entre zonas (GZRS): pode pensar no GZRS como se fosse como ZRS, mas com redundância geográfica. Com o GZRS, os ficheiros são armazenados três vezes em três clusters de armazenamento distintos na região primária. Em seguida, todas as escritas são replicadas de forma assíncrona para uma região secundária definida pela Microsoft.

Para uma solução robusta de recuperação após desastre, a maioria dos clientes deve considerar o ZRS. O ZRS adiciona o menor custo adicional para os benefícios de redundância de dados adicionados e é também o mais totalmente integrado em caso de indisponibilidade. Se a política ou os requisitos regulamentares da sua organização exigirem redundância geográfica para os seus dados, considere GRS ou GZRS.

Georredundância

Se a sua conta de armazenamento estiver configurada com replicação GRS ou GZRS, a Microsoft iniciará a ativação pós-falha do Serviço de Sincronização de Armazenamento se a região primária for considerada permanentemente irrecuperável ou indisponível durante muito tempo. Não é necessária qualquer ação por parte do utilizador em caso de desastre.

Embora possa pedir manualmente uma ativação pós-falha do Serviço de Sincronização de Armazenamento para a região emparelhada GRS ou GZRS, não recomendamos que o faça fora de falhas regionais em grande escala porque o processo não é totalmente integrado e pode incorrer em custos adicionais. Para iniciar o processo, abra um pedido de suporte e peça que as contas de armazenamento do Azure que contêm a partilha de ficheiros do Azure e o Serviço de Sincronização de Armazenamento sejam efetuada a ativação pós-falha.

Aviso

Tem de contactar o suporte para pedir a ativação pós-falha do Serviço de Sincronização de Armazenamento se estiver a iniciar este processo manualmente. Tentar criar um novo Serviço de Sincronização de Armazenamento com os mesmos pontos finais de servidor na região secundária pode resultar na permanência de dados adicionais na sua conta de armazenamento, uma vez que a instalação anterior do Azure File Sync não será limpa.

Assim que ocorrer uma ativação pós-falha, os pontos finais do servidor mudarão automaticamente para sincronizar com o ponto final da cloud na região secundária. No entanto, os pontos finais do servidor têm de se reconciliar com os pontos finais da cloud. Isto pode resultar em conflitos de ficheiros, uma vez que os dados na região secundária podem não ser apanhados na região primária.

Passos seguintes

Saiba mais sobre a cópia de segurança da partilha de ficheiros do Azure