Partilhar via

Migrar dados offline para o Azure File Sync com o Azure Data Box

  • Artigo

Este artigo de migração é um dos vários que se aplicam às palavras-chave Azure File Sync e Azure Data Box. Verifique se este artigo se aplica ao seu cenário:

Uma exibição de três etapas sequenciais descritas neste guia de migração. A coluna ao lado da imagem descreve-os em detalhes.

  • Fonte de dados: Windows Server 2012 R2 ou mais recente, onde o Azure File Sync será instalado e apontará para o conjunto original de arquivos.
  • Rota de migração: Windows Server 2012 R2 ou mais recente ⇒ Data Box ⇒ compartilhamento de arquivos do Azure ⇒ sincronizar com o local do arquivo original do Windows Server
  • Armazenamento em cache de arquivos no local: Sim, o objetivo final é uma implantação do Azure File Sync que sincroniza os arquivos de onde eles estão agora.

Usar o Azure Data Box é um caminho viável para mover a maior parte dos dados do seu Windows Server local para separar compartilhamentos de arquivos do Azure e, opcionalmente, adicionar a Sincronização de Arquivos do Azure no servidor de origem original.

Existem diferentes caminhos de migração disponíveis para você, é importante seguir o caminho certo:

  • Seus dados vivem em um Windows Server 2012 R2 ou mais recente e você planeja instalar o AFS nesse servidor e sincronizar o local original. Nesse cenário, você não deseja carregar todos os arquivos e usar o Data Box em vez disso, em seguida, use a sincronização de arquivos para alterações contínuas. Se este for o seu cenário, este artigo descreve o caminho de migração.
  • Você tem dados em uma fonte na qual você não vai ou não pode instalar o AFS. Um NAS (Network Attached Storage), por exemplo, ou um servidor diferente. Em vez disso, você criará um novo servidor vazio e usará a Sincronização de Arquivos do Azure nesse servidor. Se esse é o seu cenário, então este não é o guia de migração certo para você. Em vez disso, confira: Migre do NAS via Data Box para o Azure File Sync ou encontre o melhor guia para o seu cenário na página de visão geral da migração.
  • Para todos os outros cenários, verifique a tabela de guias de migração de compartilhamento de arquivos do Azure. Esta página de visão geral fornece um bom ponto de partida para todos os cenários de migração.

Descrição geral da migração

O processo de migração consiste em várias fases. Terá de:

  • Implante contas de armazenamento e compartilhamentos de arquivos.
  • Implante um ou mais dispositivos do Azure Data Box para mover os dados do seu Windows Server 2012 R2 ou mais recente.
  • Configure a Sincronização de Arquivos do Azure com carregamento autoritativo.

As seções a seguir descrevem as fases do processo de migração em detalhes.

Gorjeta

Se você estiver voltando a este artigo, use a navegação no lado direito da tela para ir para a fase de migração de onde parou.

Fase 1: Determinar quantos compartilhamentos de arquivos do Azure você precisa

Com este guia de migração, você deve continuar a usar o DAS (Direct Attached Storage, armazenamento com conexão direta) local que contém seus arquivos. O Data Box será alimentado a partir desse local e a Sincronização de Arquivos do Azure também será configurada nesse local. O NAS (Network Attached Storage) não funciona com esse caminho de migração.

Você determina o que sincroniza configurando grupos de sincronização do Azure File Sync que determinam onde um conjunto de arquivos é sincronizado. Cada grupo de sincronização tem pelo menos um local de servidor, chamado de ponto de extremidade de servidor e um compartilhamento de arquivos do Azure, chamado de ponto de extremidade de nuvem.

Você pode sincronizar subcaminhos de um conjunto de arquivos para cada um de seu próprio compartilhamento de arquivos do Azure. Isso significa configurar vários grupos de sincronização para cobrir completamente um conjunto de arquivos. O restante da seção descreve suas opções. Se você precisar reestruturar seus dados, deverá fazê-lo como uma primeira etapa, antes de continuar com este guia, solicite um Data Box ou uma sincronização de configuração.

Atenção

É imperativo que sua estrutura de arquivos e pastas seja como você deseja que seja a longo prazo, antes de começar a migração. Evite qualquer reestruturação desnecessária da pasta durante a migração. Isso diminuirá os efeitos positivos do uso do Azure Data Box para o transporte inicial em massa de arquivos para o Azure.

Nesta etapa, você determinará quantos compartilhamentos de arquivos do Azure são necessários. Uma única instância (ou cluster) do Windows Server pode sincronizar até 30 compartilhamentos de arquivos do Azure.

Você pode ter mais pastas em seus volumes que você atualmente compartilha localmente como compartilhamentos SMB para seus usuários e aplicativos. A maneira mais fácil de imaginar esse cenário é imaginar um compartilhamento local que mapeia 1:1 para um compartilhamento de arquivos do Azure. Se você tiver um número pequeno o suficiente de compartilhamentos, abaixo de 30 para uma única instância do Windows Server, recomendamos um mapeamento 1:1.

Se você tiver mais de 30 compartilhamentos, mapear um compartilhamento local 1:1 para um compartilhamento de arquivos do Azure geralmente é desnecessário. Considere as seguintes opções.

Agrupamento de compartilhamentos

Por exemplo, se o seu departamento de recursos humanos (RH) tiver 15 compartilhamentos, você pode considerar armazenar todos os dados de RH em um único compartilhamento de arquivos do Azure. O armazenamento de vários compartilhamentos locais em um compartilhamento de arquivos do Azure não impede que você crie os 15 compartilhamentos SMB usuais em sua instância local do Windows Server. Isso significa apenas que você organiza as pastas raiz desses 15 compartilhamentos como subpastas em uma pasta comum. Em seguida, sincronize essa pasta comum com um compartilhamento de arquivos do Azure. Dessa forma, apenas um único compartilhamento de arquivos do Azure na nuvem é necessário para esse grupo de compartilhamentos locais.

Sincronização de volume

O Azure File Sync dá suporte à sincronização da raiz de um volume com um compartilhamento de arquivos do Azure. Se você sincronizar a raiz do volume, todas as subpastas e arquivos irão para o mesmo compartilhamento de arquivos do Azure.

Sincronizar a raiz do volume nem sempre é a melhor opção. Há benefícios em sincronizar vários locais. Por exemplo, isso ajuda a manter o número de itens mais baixo por escopo de sincronização. Testamos as partilhas de ficheiros do Azure e a Sincronização de Ficheiros do Azure com 100 milhões de itens (ficheiros e pastas) por partilha. Mas uma boa prática é tentar manter o número abaixo de 20 milhões ou 30 milhões em uma única ação. Configurar a Sincronização de Ficheiros do Azure com um número mais baixo de itens não é benéfico apenas para a sincronização de ficheiros. Um número menor de itens também beneficia cenários como estes:

  • A verificação inicial do conteúdo da nuvem pode ser concluída mais rapidamente, o que, por sua vez, diminui a espera para que o namespace apareça em um servidor habilitado para a Sincronização de Arquivos do Azure.
  • A restauração do lado da nuvem a partir de um instantâneo de compartilhamento de arquivos do Azure será mais rápida.
  • A recuperação de desastres de um servidor local pode acelerar significativamente.
  • As alterações feitas diretamente em um compartilhamento de arquivos do Azure (fora da sincronização) podem ser detetadas e sincronizadas mais rapidamente.

Gorjeta

Se não sabe quantos ficheiros e pastas tem, consulte a ferramenta TreeSize da JAM Software GmbH.

Uma abordagem estruturada para um mapa de implantação

Antes de implantar o armazenamento em nuvem em uma etapa posterior, é importante criar um mapa entre pastas locais e compartilhamentos de arquivos do Azure. Esse mapeamento informará quantos e quais recursos do grupo de sincronização do Azure File Sync você provisionará. Um grupo de sincronização vincula o compartilhamento de arquivos do Azure e a pasta em seu servidor e estabelece uma conexão de sincronização.

Para decidir quantos compartilhamentos de arquivos do Azure você precisa, revise os seguintes limites e práticas recomendadas. Isso irá ajudá-lo a otimizar o seu mapa.

  • Um servidor no qual o agente do Azure File Sync está instalado pode sincronizar com até 30 compartilhamentos de arquivos do Azure.

  • Um compartilhamento de arquivos do Azure é implantado em uma conta de armazenamento. Essa disposição torna a conta de armazenamento um destino de escala para números de desempenho, como IOPS e taxa de transferência.

    Preste atenção às limitações de IOPS de uma conta de armazenamento ao implantar compartilhamentos de arquivos do Azure. Idealmente, você deve mapear compartilhamentos de arquivos 1:1 com contas de armazenamento. No entanto, isso nem sempre é possível devido a vários limites e restrições, tanto da sua organização quanto do Azure. Quando não for possível ter apenas um compartilhamento de arquivos implantado em uma conta de armazenamento, considere quais compartilhamentos serão altamente ativos e quais compartilhamentos serão menos ativos para garantir que os compartilhamentos de arquivos mais quentes não sejam colocados na mesma conta de armazenamento juntos.

    Se você planeja elevar um aplicativo para o Azure que usará o compartilhamento de arquivos do Azure nativamente, talvez precise de mais desempenho do seu compartilhamento de arquivos do Azure. Se esse tipo de uso for uma possibilidade, mesmo no futuro, é melhor criar um único compartilhamento de arquivos padrão do Azure em sua própria conta de armazenamento.

  • Há um limite de 250 contas de armazenamento por assinatura por região do Azure.

Gorjeta

Dadas essas informações, muitas vezes torna-se necessário agrupar várias pastas de nível superior em seus volumes em um novo diretório raiz comum. Em seguida, sincronize esse novo diretório raiz e todas as pastas agrupadas nele com um único compartilhamento de arquivos do Azure. Essa técnica permite que você fique dentro do limite de 30 sincronizações de compartilhamento de arquivos do Azure por servidor.

Esse agrupamento sob uma raiz comum não afeta o acesso aos seus dados. Suas ACLs permanecem como estão. Você só precisa ajustar os caminhos de compartilhamento (como compartilhamentos SMB ou NFS) que possa ter nas pastas do servidor local que agora você alterou para uma raiz comum. Nada mais muda.

Importante

O vetor de escala mais importante para o Azure File Sync é o número de itens (arquivos e pastas) que precisam ser sincronizados. Analise os destinos de escala do Azure File Sync para obter mais detalhes.

É uma prática recomendada manter baixo o número de itens por escopo de sincronização. Esse é um fator importante a ser considerado em seu mapeamento de pastas para compartilhamentos de arquivos do Azure. O Azure File Sync é testado com 100 milhões de itens (ficheiros e pastas) por partilha. Mas muitas vezes é melhor manter o número de itens abaixo de 20 milhões ou 30 milhões em uma única ação. Divida seu namespace em vários compartilhamentos se você começar a exceder esses números. Você pode continuar a agrupar vários compartilhamentos locais no mesmo compartilhamento de arquivos do Azure se ficar aproximadamente abaixo desses números. Esta prática proporcionar-lhe-á espaço para crescer.

É possível que, na sua situação, um conjunto de pastas possa sincronizar logicamente com o mesmo compartilhamento de arquivos do Azure (usando a nova abordagem de pasta raiz comum mencionada anteriormente). Mas ainda pode ser melhor reagrupar pastas para que elas sincronizem com duas em vez de um compartilhamento de arquivos do Azure. Você pode usar essa abordagem para manter o número de arquivos e pastas por compartilhamento de arquivos equilibrado no servidor. Você também pode dividir seus compartilhamentos locais e sincronizar em mais servidores locais, adicionando a capacidade de sincronizar com mais 30 compartilhamentos de arquivos do Azure por servidor extra.

Cenários e considerações comuns de sincronização de arquivos

# Cenário de sincronização Suportado Considerações (ou limitações) Solução (ou solução alternativa)
1 Servidor de ficheiros com vários discos/volumes e várias partilhas para o mesmo compartilhamento de arquivos do Azure de destino (consolidação) Não Um compartilhamento de arquivos do Azure de destino (ponto de extremidade na nuvem) só dá suporte à sincronização com um grupo de sincronização.

Um grupo de sincronização suporta apenas um ponto de extremidade de servidor por servidor registrado.		 1) Comece com a sincronização de um disco (seu volume raiz) para o compartilhamento de arquivos do Azure de destino. Começar com o maior disco/volume ajudará com os requisitos de armazenamento no local. Configure a hierarquização da nuvem para hierarquizar todos os dados na nuvem, liberando espaço no disco do servidor de arquivos. Mova dados de outros volumes/compartilhamentos para o volume atual que está sincronizando. Continue as etapas, uma a uma, até que todos os dados sejam hierarquizados para a nuvem/migrados.
2) Segmente um volume raiz (disco) de cada vez. Use a hierarquização na nuvem para hierarquizar todos os dados para o compartilhamento de arquivos do Azure de destino. Remova o ponto de extremidade do servidor do grupo de sincronização, recrie o ponto de extremidade com o próximo volume/disco raiz, sincronize e repita o processo. Nota: A reinstalação do agente pode ser necessária.
3) Recomende o uso de vários compartilhamentos de arquivos do Azure de destino (conta de armazenamento igual ou diferente com base nos requisitos de desempenho)
2 Servidor de ficheiros com volume único e várias partilhas para o mesmo compartilhamento de arquivos do Azure de destino (consolidação) Sim Não é possível ter vários pontos de extremidade de servidor por servidor registrado sincronizando com o mesmo compartilhamento de arquivos do Azure de destino (o mesmo que acima) Sincronize a raiz do volume que contém vários compartilhamentos ou pastas de nível superior. Consulte Conceito de agrupamento de compartilhamento e Sincronização de volume para obter mais informações.
3 Servidor de ficheiros com várias partilhas e/ou volumes para várias partilhas de ficheiros do Azure numa única conta de armazenamento (mapeamento de partilha 1:1) Sim Uma única instância (ou cluster) do Windows Server pode sincronizar até 30 compartilhamentos de arquivos do Azure.

Uma conta de armazenamento é um destino de escala para desempenho. IOPS e taxa de transferência são compartilhadas entre compartilhamentos de arquivos.

Mantenha o número de itens por grupo de sincronização dentro de 100 milhões de itens (arquivos e pastas) por compartilhamento. O ideal é ficar abaixo de 20 ou 30 milhões por ação.		 1) Use vários grupos de sincronização (número de grupos de sincronização = número de compartilhamentos de arquivos do Azure para sincronizar).
2) Apenas 30 compartilhamentos podem ser sincronizados neste cenário de cada vez. Se você tiver mais de 30 compartilhamentos nesse servidor de arquivos, use o conceito de agrupamento de compartilhamento e a sincronização de volume para reduzir o número de pastas raiz ou de nível superior na origem.
3) Use servidores de sincronização de arquivos adicionais no local e divida / mova dados para esses servidores para contornar as limitações no servidor Windows de origem.
4 Servidor de arquivos com vários compartilhamentos e/ou volumes para vários compartilhamentos de arquivos do Azure em conta de armazenamento diferente (mapeamento de compartilhamento 1:1) Sim Uma única instância (ou cluster) do Windows Server pode sincronizar até 30 compartilhamentos de arquivos do Azure (conta de armazenamento igual ou diferente).

Mantenha o número de itens por grupo de sincronização dentro de 100 milhões de itens (arquivos e pastas) por compartilhamento. O ideal é ficar abaixo de 20 ou 30 milhões por ação.		 Mesma abordagem que acima
5 Vários servidores de arquivos com um único (volume raiz ou compartilhamento) para o mesmo compartilhamento de arquivos do Azure de destino (consolidação) Não Um grupo de sincronização não pode usar o ponto de extremidade de nuvem (compartilhamento de arquivos do Azure) já configurado em outro grupo de sincronização.

Embora um grupo de sincronização possa ter pontos de extremidade de servidor em servidores de arquivos diferentes, os arquivos não podem ser distintos.		 Siga as orientações no Cenário # 1 acima com consideração adicional de segmentar um servidor de arquivos de cada vez.

Criar uma tabela de mapeamento

Diagrama que mostra um exemplo de uma tabela de mapeamento. Transfira o seguinte ficheiro para experimentar e utilizar o conteúdo desta imagem.

Use as informações anteriores para determinar quantos compartilhamentos de arquivos do Azure você precisa e quais partes de seus dados existentes acabarão em qual compartilhamento de arquivos do Azure.

Crie uma tabela que registre seus pensamentos para que você possa consultá-la quando precisar. Manter-se organizado é importante porque pode ser fácil perder detalhes do seu plano de mapeamento quando você provisiona muitos recursos do Azure de uma só vez. Baixe o seguinte arquivo do Excel para usar como um modelo para ajudar a criar seu mapeamento.


Ícone do Excel que define o contexto para o download. Baixe um modelo de mapeamento de namespace.

Fase 2: Implantar recursos de armazenamento do Azure

Nesta fase, consulte a tabela de mapeamento da Fase 1 e use-a para provisionar o número correto de contas de armazenamento do Azure e compartilhamentos de arquivos dentro delas.

Um compartilhamento de arquivos do Azure é armazenado na nuvem em uma conta de armazenamento do Azure. Outro nível de considerações de desempenho se aplica aqui.

Se você tiver compartilhamentos altamente ativos (compartilhamentos usados por muitos usuários e/ou aplicativos), dois compartilhamentos de arquivos do Azure podem atingir o limite de desempenho de uma conta de armazenamento.

Uma prática recomendada é implantar contas de armazenamento com um compartilhamento de arquivos cada. Você pode agrupar vários compartilhamentos de arquivos do Azure na mesma conta de armazenamento se tiver compartilhamentos de arquivamento ou se esperar baixa atividade diária neles.

Essas considerações se aplicam mais ao acesso direto à nuvem (por meio de uma VM do Azure) do que à Sincronização de Arquivos do Azure. Se você planeja usar apenas o Azure File Sync nesses compartilhamentos, agrupar vários em uma única conta de armazenamento do Azure é bom.

Se você fez uma lista de seus compartilhamentos, você deve mapear cada compartilhamento para a conta de armazenamento em que estará.

Na fase anterior, você determinou o número apropriado de ações. Nesta etapa, você tem um mapeamento de contas de armazenamento para compartilhamentos de arquivos. Agora, implante o número apropriado de contas de armazenamento do Azure com o número apropriado de compartilhamentos de arquivos do Azure nelas.

Verifique se a região de cada uma das suas contas de armazenamento é a mesma e corresponde à região do recurso do Serviço de Sincronização de Armazenamento que você já implantou.

Atenção

Se você criar um compartilhamento de arquivos do Azure que tenha um limite de 100 TiB, esse compartilhamento poderá usar apenas armazenamento com redundância local ou opções de redundância de armazenamento com redundância de zona. Considere suas necessidades de redundância de armazenamento antes de usar compartilhamentos de arquivos de 100 TiB.

Os compartilhamentos de arquivos do Azure ainda são criados com um limite de 5 TiB por padrão. Siga as etapas em Criar um compartilhamento de arquivos do Azure para criar um compartilhamento de arquivos grande.

Outra consideração ao implantar uma conta de armazenamento é a redundância do Armazenamento do Azure. Consulte Opções de redundância do Armazenamento do Azure.

Os nomes dos seus recursos também são importantes. Por exemplo, se você agrupar vários compartilhamentos para o departamento de RH em uma conta de armazenamento do Azure, deverá nomear a conta de armazenamento adequadamente. Da mesma forma, ao nomear seus compartilhamentos de arquivos do Azure, você deve usar nomes semelhantes aos usados para suas contrapartes locais.

Fase 3: Determinar quantos dispositivos do Azure Data Box você precisa

Inicie esta etapa somente depois de concluir a fase anterior. Seus recursos de armazenamento do Azure (contas de armazenamento e compartilhamentos de arquivos) devem ser criados neste momento. Ao solicitar o Data Box, você precisa especificar as contas de armazenamento para as quais o Data Box está movendo dados.

Nesta fase, você precisa mapear os resultados do plano de migração da fase anterior para os limites das opções disponíveis do Data Box. Essas considerações ajudarão você a planejar quais opções do Data Box escolher e quantas delas você precisará mover seus compartilhamentos NAS para compartilhamentos de arquivos do Azure.

Para determinar quantos dispositivos você precisa e seus tipos, considere estes limites importantes:

  • Qualquer dispositivo Azure Data Box pode mover dados para até 10 contas de armazenamento.
  • Cada opção Data Box vem com sua própria capacidade utilizável. Consulte Opções da Caixa de Dados.

Consulte seu plano de migração para encontrar o número de contas de armazenamento que você decidiu criar e os compartilhamentos em cada uma. Em seguida, observe o tamanho de cada uma das ações no seu NAS. A combinação dessas informações permitirá que você otimize e decida qual dispositivo deve enviar dados para quais contas de armazenamento. Dois dispositivos Data Box podem mover arquivos para a mesma conta de armazenamento, mas não dividem o conteúdo de um único compartilhamento de arquivos em duas Data Boxes.

Opções do Data Box

Para uma migração padrão, escolha uma ou uma combinação destas opções do Data Box:

  • Disco Data Box. A Microsoft irá enviar-lhe entre um e cinco discos SSD com uma capacidade de 8 TiB cada, para um total máximo de 40 TiB. A capacidade utilizável é cerca de 20% menor devido à criptografia e à sobrecarga do sistema de arquivos. Para obter mais informações, consulte a documentação do disco Data Box.
  • Caixa de dados. Esta opção é a mais comum. A Microsoft enviará um dispositivo Data Box robusto que funciona de forma semelhante a um NAS. Tem uma capacidade utilizável de 80 TiB. Para obter mais informações, consulte a documentação do Data Box.
  • Data Box pesado. Esta opção apresenta um dispositivo Data Box robusto sobre rodas que funciona de forma semelhante a um NAS. Tem capacidade para 1 PiB. A capacidade utilizável é cerca de 20% menor devido à criptografia e à sobrecarga do sistema de arquivos. Para obter mais informações, consulte a documentação pesada do Data Box.

Nota

Para Data Box e Data Box Heavy, apenas a cópia de dados via SMB é suportada. A cópia de dados através do serviço de cópia de dados não é suportada porque não preserva a fidelidade do ficheiro.

Fase 4: Copiar ficheiros para o Data Box

Quando o seu Data Box chegar, você precisa configurá-lo com conectividade de rede desimpedida para o seu dispositivo NAS. Siga a documentação de configuração para o tipo de Data Box que encomendou:

Dependendo do tipo de Data Box, as ferramentas de cópia do Data Box podem estar disponíveis. Neste ponto, não os recomendamos para migrações para compartilhamentos de arquivos do Azure porque eles não copiam seus arquivos para o Data Box com total fidelidade. Em vez disso, use o Robocopy.

Quando o seu Data Box chegar, ele terá compartilhamentos SMB pré-provisionados disponíveis para cada conta de armazenamento que você especificou quando o encomendou.

  • Se seus arquivos forem para um compartilhamento de arquivos premium do Azure, haverá um compartilhamento SMB por conta de armazenamento premium de "Armazenamento de arquivos".
  • Se os seus ficheiros forem para uma conta de armazenamento padrão, haverá três partilhas SMB por conta de armazenamento padrão (GPv1 e GPv2). Somente os compartilhamentos de arquivos que terminam com _AzFiles são relevantes para sua migração. Ignore qualquer bloco e compartilhamento de blob de página.

Siga as etapas na documentação do Azure Data Box:

  1. Conecte-se ao Data Box.
  2. Copie dados para o Data Box.
  3. Prepare o Data Box para carregar no Azure.

A documentação do Data Box vinculado especifica um comando Robocopy. Esse comando não é adequado para preservar a fidelidade completa de arquivos e pastas. Em vez disso, use este comando:

robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
Comutador Significado
/MT:n Permite ao Robocopy ser executado com vários threads. O padrão para n é 8. O máximo é de 128 threads. Embora uma alta contagem de threads ajude a saturar a largura de banda disponível, isso não significa que sua migração será sempre mais rápida com mais threads. Os testes com os Arquivos do Azure indicam que entre 8 e 20 mostram um desempenho equilibrado para uma execução de cópia inicial. As execuções subsequentes /MIR são progressivamente afetadas pela computação disponível vs largura de banda de rede disponível. Nas execuções subsequentes, faça corresponder o valor da contagem de threads a um valor próximo da contagem de núcleos do processador e da contagem de threads por núcleo. Considere se os núcleos precisam de ser reservados para outras tarefas que um servidor de produção possa ter. Testes com Arquivos do Azure mostraram que até 64 threads produzem um bom desempenho, mas somente se seus processadores puderem mantê-los ativos ao mesmo tempo.
/R:n Contagem máxima de novas tentativas para um ficheiro cuja cópia falhou na primeira tentativa. O Robocopy tentará n vezes antes que o arquivo não consiga copiar permanentemente na execução. Você pode otimizar o desempenho de sua execução: escolha um valor de dois ou três se acreditar que problemas de tempo limite causaram falhas no passado. Isso pode ser mais comum em links WAN. Escolha nenhuma nova tentativa ou um valor de um se você acredita que o arquivo não conseguiu copiar porque estava ativamente em uso. Tentar novamente alguns segundos depois pode não ser tempo suficiente para que o estado em uso do arquivo mude. Os usuários ou aplicativos que mantêm o arquivo aberto podem precisar de horas a mais de tempo. Nesse caso, aceitar que o arquivo não foi copiado e capturá-lo em uma de suas execuções subsequentes planejadas do Robocopy pode ter sucesso em eventualmente copiar o arquivo com sucesso. Isso ajuda a execução atual a terminar mais rápido sem ser prolongada por muitas tentativas que, em última análise, acabam em uma maioria de falhas de cópia devido a arquivos ainda abertos após o tempo limite de repetição.
/W:n Especifica o tempo que o Robocopy aguarda antes de tentar copiar um ficheiro que não foi copiado com êxito na tentativa anterior. n é o número de segundos de espera entre as tentativas. /W:n é frequentemente utilizado em conjunto com /R:n.
/B Executa o Robocopy no mesmo modo que uma aplicação de cópia de segurança utilizaria. Esta opção permite que o Robocopy mova os ficheiros para os quais o atual utilizador não tem permissões. A opção de backup depende da execução do comando Robocopy em um console elevado do administrador ou em uma janela do PowerShell. Se você usar o Robocopy para Arquivos do Azure, certifique-se de montar o compartilhamento de arquivos do Azure usando a chave de acesso da conta de armazenamento versus uma identidade de domínio. Se não o fizer, as mensagens de erro poderão não o levar intuitivamente a uma resolução do problema.
/MIR (Espelhar origem para destino.) Permite que o Robocopy copie apenas os detalhes entre a origem e o destino. Os subdiretórios vazios serão copiados. Os itens (ficheiros ou pastas) que tenham sido alterados ou não existam no destino serão copiados. Os itens que existam no destino, mas não na origem, serão removidos (eliminados) do destino. Quando utilizar esta opção, faça corresponder exatamente as estruturas das pastas de origem e de destino. Correspondência significa copiar do nível de origem e pasta correto para o nível de pasta correspondente no destino. Só, assim, é que uma cópia “atualizada” pode ter êxito. Quando a origem e o destino são incompatíveis, o uso /MIR levará a exclusões e recópias em grande escala.
/IT Garante que a fidelidade é preservada em determinados cenários de espelhamento.
Por exemplo, se um arquivo tiver uma alteração de ACL e uma atualização de atributo entre duas execuções do Robocopy, ele será marcado como oculto. Sem /ITo , a alteração da ACL pode ser perdida pelo Robocopy e não transferida para o local de destino.
/COPY:[copyflags] A fidelidade da cópia do ficheiro. Padrão: /COPY:DAT. Sinalizadores de cópia: D= Dados, A= Atributos, T= Carimbos de data/hora, S= Segurança = ACLs NTFS, O= Informações do proprietário, U= Auditing information. As informações de auditoria não podem ser armazenadas numa partilha de ficheiros do Azure.
/DCOPY:[copyflags] Fidelidade para a cópia de diretórios. Padrão: /DCOPY:DA. Sinalizadores de cópia: D= Dados, A= Atributos, T= Carimbos de data/hora.
/NP Especifica que o progresso da cópia de cada ficheiro e pasta não será apresentado. A apresentação do progresso reduz significativamente o desempenho da cópia.
/NFL Especifica que os nomes de ficheiro não estão registados. Melhora o desempenho da cópia.
/NDL Especifica que os nomes de diretório não estão registados. Melhora o desempenho da cópia.
/XD Especifica os diretórios a serem excluídos. Ao executar o Robocopy na raiz de um volume, considere excluir a pasta oculta System Volume Information . Se usado como projetado, todas as informações lá são específicas para o volume exato neste sistema exato e podem ser reconstruídas sob demanda. Copiar essas informações não será útil na nuvem ou quando os dados forem copiados de volta para outro volume do Windows. Deixar este conteúdo para trás não deve ser considerado perda de dados.
/UNILOG:<file name> Grava o status no arquivo de log como Unicode. (Substitui o log existente.)
/L Somente para uma execução
de teste, os arquivos devem ser listados somente. Não serão copiados, nem eliminados e não terão nenhum carimbo de data/hora. Muitas vezes usado com /TEE para saída de console. Os sinalizadores do script de exemplo, como /NP, /NFLe /NDL, podem precisar ser removidos para obter resultados de teste devidamente documentados.
/LFSM Só para destinos com armazenamento escalonado. Não há suporte quando o destino é um compartilhamento SMB remoto.
Especifica que o Robocopy opera no "modo de pouco espaço livre". Essa opção é útil apenas para destinos com armazenamento hierárquico que podem ficar sem capacidade local antes que o Robocopy termine. Foi adicionado especificamente para utilização com um destino ativado para o arrumo na cloud do Azure File Sync. Pode ser utilizado independentemente do Azure File Sync. Neste modo, o Robocopy será colocado em pausa sempre que a cópia de um ficheiro possa fazer com que o espaço livre num volume de destino fique abaixo do valor “limite”. Este valor pode ser especificado pela /LFSM:n forma da bandeira. O parâmetro n é especificado na base 2: nKB, nMB, ou nGB. Se /LFSM for especificado sem valor de piso explícito, o piso será definido como 10% do tamanho do volume de destino. O modo de pouco espaço livre não é compatível com /MT, /EFSRAWou /ZB. O suporte para /B foi adicionado no Windows Server 2022. Consulte a seção Windows Server 2022 e RoboCopy LFSM abaixo para obter mais informações, incluindo detalhes sobre um bug relacionado e solução alternativa.
/Z Use com cautela
Copia arquivos no modo de reinicialização. Esta opção só é recomendada num ambiente de rede instável. Reduz significativamente o desempenho da cópia devido ao registo extra.
/ZB Use com cautela
Usa o modo de reinicialização. Se o acesso for negado, esta opção utilizará o modo de cópia de segurança. Esta opção reduz significativamente o desempenho da cópia devido ao controlo de pontos de verificação.

Importante

Recomendamos o uso de um Windows Server 2022. Ao usar um Windows Server 2019, verifique se o nível de patch mais recente ou, pelo menos , o KB5005103 de atualização do sistema operacional está instalado. Ele contém correções importantes para determinados cenários do Robocopy.

Fase 5: Implantar o recurso de nuvem do Azure File Sync

Antes de continuar com este guia, aguarde até que todos os seus arquivos tenham chegado aos compartilhamentos de arquivos corretos do Azure. O processo de envio e ingestão de dados Data Box levará tempo.

Para concluir esta etapa, você precisa de suas credenciais de assinatura do Azure.

O recurso principal a ser configurado para o Azure File Sync é chamado de Serviço de Sincronização de Armazenamento. Recomendamos que você implante apenas um para todos os servidores que estão sincronizando o mesmo conjunto de arquivos agora ou no futuro. Crie vários Serviços de Sincronização de Armazenamento somente se você tiver conjuntos distintos de servidores que nunca devem trocar dados. Por exemplo, você pode ter servidores que nunca devem sincronizar o mesmo compartilhamento de arquivos do Azure. Caso contrário, usar um único Serviço de Sincronização de Armazenamento é a prática recomendada.

Escolha uma região do Azure para o seu Serviço de Sincronização de Armazenamento que esteja perto da sua localização. Todos os outros recursos de nuvem devem ser implantados na mesma região. Para simplificar o gerenciamento, crie um novo grupo de recursos em sua assinatura que hospede recursos de sincronização e armazenamento.

Para obter mais informações, consulte a seção sobre a implantação do Serviço de Sincronização de Armazenamento no artigo sobre a implantação do Azure File Sync. Siga apenas esta seção do artigo. Haverá links para outras seções do artigo em etapas posteriores.

Fase 6: Implantar o agente do Azure File Sync

Nesta seção, você instala o agente do Azure File Sync em sua instância do Windows Server.

O guia de implantação explica que você precisa desativar a Configuração de Segurança Reforçada do Internet Explorer. Esta medida de segurança não é aplicável ao Azure File Sync. Desativá-lo permite que você se autentique no Azure sem problemas.

Abra o PowerShell. Instale os módulos necessários do PowerShell usando os seguintes comandos. Certifique-se de instalar o módulo completo e o provedor NuGet quando for solicitado.

Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync

Se você tiver algum problema para acessar a internet a partir do seu servidor, agora é a hora de resolvê-los. A Sincronização de Ficheiros do Azure utiliza qualquer ligação de rede disponível à Internet. Exigir um servidor proxy para acessar a Internet também é suportado. Você pode configurar um proxy em toda a máquina agora ou, durante a instalação do agente, especificar um proxy que somente o Azure File Sync usará.

Se configurar um proxy significa que você precisa abrir seus firewalls para o servidor, essa abordagem pode ser aceitável para você. No final da instalação do servidor, depois de concluir o registro do servidor, um relatório de conectividade de rede mostrará as URLs de ponto de extremidade exatas no Azure com as quais a Sincronização de Arquivos do Azure precisa se comunicar para a região selecionada. O relatório também explica por que razão é necessária comunicação. Você pode usar o relatório para bloquear os firewalls ao redor do servidor para URLs específicas.

Você também pode adotar uma abordagem mais conservadora, na qual você não abre os firewalls amplamente. Em vez disso, você pode limitar o servidor para se comunicar com namespaces DNS de nível superior. Para obter mais informações, consulte Configurações de proxy e firewall do Azure File Sync. Siga suas próprias práticas recomendadas de rede.

No final do assistente de instalação do servidor, um assistente de registro do servidor será aberto. Registre o servidor no recurso do Azure do Serviço de Sincronização de Armazenamento a partir de antes.

Essas etapas são descritas com mais detalhes no guia de implantação, que inclui os módulos do PowerShell que você deve instalar primeiro: Instalação do agente do Azure File Sync.

Use o agente mais recente. Você pode baixá-lo do Centro de Download da Microsoft: Azure File Sync Agent.

Após uma instalação bem-sucedida e o registro do servidor, você pode confirmar que concluiu esta etapa com êxito. Vá para o recurso Serviço de Sincronização de Armazenamento no portal do Azure. No menu à esquerda, vá para Servidores registrados. Você verá seu servidor listado lá.

Fase 7: Configurar a Sincronização de Arquivos do Azure no Windows Server existente

Sua instância do Windows Server local registrada deve estar pronta e conectada à Internet para esse processo.

Esta etapa reúne todos os recursos e pastas que você configurou em sua instância do Windows Server durante as etapas anteriores.

  1. Inicie sessão no portal do Azure.
  2. Localize o recurso do Serviço de Sincronização de Armazenamento.
  3. Crie um novo grupo de sincronização dentro do recurso do Serviço de Sincronização de Armazenamento para cada compartilhamento de arquivos do Azure. Na terminologia do Azure File Sync, o compartilhamento de arquivos do Azure se tornará um ponto de extremidade de nuvem na topologia de sincronização que você está descrevendo com a criação de um grupo de sincronização. Ao criar o grupo de sincronização, dê-lhe um nome familiar para que você reconheça qual conjunto de arquivos sincroniza lá. Certifique-se de fazer referência ao compartilhamento de arquivos do Azure com um nome correspondente.
  4. Depois de criar o grupo de sincronização, uma linha para ele aparecerá na lista de grupos de sincronização. Selecione o nome (um link) para exibir o conteúdo do grupo de sincronização. Você verá seu compartilhamento de arquivos do Azure em Pontos de extremidade de nuvem.
  5. Localize o botão Adicionar ponto de extremidade do servidor. A pasta no servidor local que você provisionou se tornará o caminho para esse ponto de extremidade do servidor.

Uma seção do portal do Azure do assistente para criar ponto de extremidade do servidor é mostrada. É realçada uma caixa de verificação que corresponde ao cenário de propagação da partilha de ficheiros do Azure com dados. Marque esta caixa se você conectar o AFS ao mesmo local local de onde você copiou para o Data Box antes.

Quando estiver no assistente Criar ponto de extremidade do servidor, utilize a caixa de seleção fornecida abaixo do caminho da pasta. Só faça essa seleção se tiver inserido um caminho que aponte para a mesma estrutura de arquivos e pastas que pode ser encontrada no compartilhamento de arquivos do Azure (onde o Data Box moveu os arquivos e pastas para esse namespace).

Se houver uma incompatibilidade da hierarquia de pastas, isso se apresentará como diferenças que não podem ser resolvidas automaticamente. Evite uma incompatibilidade ou qualquer investimento no processo Data Box resultará em benefício zero para você. Todos os dados serão excluídos no compartilhamento de arquivos do Azure. Todos os dados terão de ser carregados a partir do servidor local. As estruturas de diretório devem corresponder para obter o benefício de uma migração em massa com o Azure Data Box e uma atualização contínua do compartilhamento de nuvem com as alterações mais recentes do servidor.

Nota

Habilitar essa caixa de seleção definirá o Modo de sincronização inicial como Substituir autoritariamente arquivos e pastas no compartilhamento de arquivos do Azure com conteúdo no caminho deste servidor. Essa opção só está disponível para o primeiro ponto de extremidade do servidor em um grupo de sincronização.

Depois de configurar o carregamento autoritativo para esse novo ponto de extremidade do servidor, você pode, opcionalmente, habilitar a hierarquização na nuvem.

A hierarquização na nuvem é o recurso de Sincronização de Arquivos do Azure que permite que o servidor local tenha menos capacidade de armazenamento do que a armazenada na nuvem, mas tenha o namespace completo disponível. Dados localmente interessantes também são armazenados em cache localmente para um desempenho de acesso rápido. A hierarquização na nuvem é opcional. Você pode defini-lo individualmente para cada ponto de extremidade do servidor de Sincronização de Arquivos do Azure. Use esse recurso para obter uma pegada de armazenamento fixa no local, mas ainda assim fornecer aos usuários um cache de desempenho local e armazenar dados mais legais na nuvem.

Saiba mais consultando a visão geral da hierarquização na nuvem ou examinando mais de perto as diferentes políticas de hierarquização da nuvem que você pode usar para ajustar o que é armazenado em cache/hierarquizado no servidor local.

Conclua a migração

Depois de criar um ponto de extremidade do servidor, a sincronização está funcionando. Mas a sincronização precisa enumerar (descobrir) os arquivos e pastas que você moveu por meio do Azure Data Box para o compartilhamento de arquivos do Azure. Dependendo do tamanho do namespace, pode levar muito tempo até que as alterações mais recentes do servidor sejam sincronizadas com a nuvem. Seus usuários não são afetados e podem continuar a trabalhar com os dados no servidor. Essa estratégia alcança uma migração para a nuvem sem tempo de inatividade.

Para todos os compartilhamentos de arquivos/locais de servidor do Azure que você precisa configurar para sincronização, repita as etapas para criar grupos de sincronização e adicionar as pastas de servidor correspondentes como pontos de extremidade de servidor. Você usou o Azure Data Box para mover seus arquivos para vários compartilhamentos de arquivos do Azure. Sua migração será concluída depois que você tiver criado todos os pontos de extremidade do servidor que conectam seus dados locais a esses compartilhamentos de arquivos do Azure.

Próximos passos

Há mais para descobrir sobre os compartilhamentos de arquivos do Azure e a Sincronização de Arquivos do Azure. Os artigos a seguir ajudarão você a entender as opções avançadas e as práticas recomendadas. Eles também fornecem ajuda com a solução de problemas. Estes artigos contêm links para a documentação de compartilhamento de arquivos do Azure, quando apropriado.