Partilhar via

Usar o Data Box para migrar do NAS (Network Attached Storage) para uma implantação de nuvem híbrida usando o Azure File Sync

  • Artigo

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

  • Fonte de dados: Network Attached Storage (NAS)
  • Rota de migração: NAS ⇒ Data Box ⇒ compartilhamento de arquivos do Azure ⇒ sincronização com o Windows Server
  • Armazenamento em cache de arquivos no local: Sim, o objetivo final é uma implantação do Azure File Sync

Se o seu cenário for diferente, consulte a tabela de guias de migração.

O Azure File Sync funciona em locais DAS (Direct Attached Storage). Ele não suporta sincronização com locais de Network Attached Storage (NAS). Então você precisa migrar seus arquivos. Este artigo orienta você pelo planejamento e implementação dessa migração.

Aplica-se a

Tipo de partilhas de ficheiros SMB NFS
Partilhas de ficheiros Standard (GPv2), LRS/ZRS Yes No
Partilhas de ficheiros Standard (GPv2), GRS/GZRS Yes No
Partilhas de ficheiros Premium (FileStorage), LRS/ZRS Yes No

Objetivos de migração

O objetivo é mover os compartilhamentos que você tem em seu dispositivo NAS para o Windows Server. Em seguida, você usará o Azure File Sync para uma implantação de nuvem híbrida. Essa migração precisa ser feita de forma a garantir a integridade dos dados de produção e a disponibilidade durante a migração. Este último requer manter o tempo de inatividade a um mínimo para que cumpra ou exceda apenas ligeiramente as janelas de manutenção regulares.

Descrição geral da migração

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

  • Implante contas de armazenamento do Azure e compartilhamentos de arquivos.
  • Implante um computador local executando o Windows Server.
  • Configure a Sincronização de Arquivos do Azure.
  • Migre arquivos usando o Robocopy.
  • Faça o corte.

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

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.

Fase 4: Provisionar uma instância adequada do Windows Server no local

Enquanto aguarda a chegada dos seus dispositivos Azure Data Box, pode começar a rever as necessidades de uma ou mais instâncias do Windows Server que irá utilizar com a Sincronização de Ficheiros do Azure.

  • Crie uma instância do Windows Server 2022 (no mínimo, Windows Server 2012 R2) como uma máquina virtual ou servidor físico. Um cluster de failover do Windows Server também é suportado.
  • Provisione ou adicione armazenamento com conexão direta. O NAS não é suportado.

A configuração de recursos (computação e RAM) da instância do Windows Server implantada depende principalmente do número de arquivos e pastas que você sincronizará. Recomendamos uma configuração de desempenho mais alto se você tiver alguma preocupação.

Saiba como dimensionar uma instância do Windows Server com base no número de itens que você precisa sincronizar.

Nota

O artigo vinculado anteriormente inclui uma tabela com um intervalo para memória do servidor (RAM). Você pode usar números na extremidade inferior do intervalo para seu servidor, mas espere que a sincronização inicial demore significativamente mais.

Fase 5: 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.
    Você pode usar o Robocopy (siga as instruções abaixo) ou o novo serviço de cópia de dados Data Box.
  3. Prepare o Data Box para carregar no Azure.

Gorjeta

Como alternativa ao Robocopy, a Data Box criou um serviço de cópia de dados. Pode utilizar este serviço para carregar ficheiros na sua Data Box com total fidelidade. Siga este tutorial do serviço de cópia de dados e certifique-se de definir o destino correto de compartilhamento de arquivos do Azure.

A documentação do Data Box 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 6: 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 7: 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 8: Configurar a Sincronização de Arquivos do Azure na instância do Windows Server

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.

Ative o recurso de hierarquização na nuvem e selecione Namespace somente na seção de download inicial.

Importante

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. Você precisará usar esse recurso se não tiver capacidade de disco local suficiente na instância do Windows Server para armazenar todos os dados da nuvem e quiser evitar baixar todos os dados da nuvem.

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. Aguarde até que a sincronização do namespace seja concluída. A seção a seguir explicará como você pode garantir que a sincronização seja concluída.

Nota

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 via Data Box para o compartilhamento de arquivos do Azure. Dependendo do tamanho do namespace, pode levar muito tempo até que o namespace da nuvem apareça no servidor.

Fase 9: Aguarde até que o namespace apareça totalmente no servidor

Antes de continuar com as próximas etapas da migração, aguarde até que o servidor tenha baixado totalmente o namespace do compartilhamento de nuvem. Se você começar a mover arquivos para o servidor muito cedo, corre o risco de uploads desnecessários e até mesmo conflitos de sincronização de arquivos.

Para determinar se o servidor concluiu a sincronização de download inicial, abra o Visualizador de Eventos na instância de sincronização do Windows Server e use o log de eventos de telemetria do Azure File Sync. O log de eventos de telemetria está no Visualizador de Eventos em Aplicativos e Serviços\Microsoft\FileSync\Agent.

Procure o evento 9102 mais recente. A ID de evento 9102 é registrada quando uma sessão de sincronização é concluída. No texto do evento, há um campo para a direção de sincronização de download. HResult( precisa ser zero, e os arquivos precisam ser baixados.)

Você deseja ver dois eventos consecutivos desse tipo, com esse conteúdo, para garantir que o servidor tenha concluído o download do namespace. Tudo bem se houver outros eventos entre os dois eventos do 9102.

Fase 10: Executar o Robocopy a partir do seu NAS

Depois que o servidor concluir a sincronização inicial de todo o namespace do compartilhamento de nuvem, você poderá continuar com esta etapa. A sincronização inicial deve estar concluída antes de continuar com esta etapa. Consulte a seção anterior para obter detalhes.

Nesta etapa, você executará trabalhos do Robocopy para sincronizar seus compartilhamentos de nuvem com as alterações mais recentes em seu NAS que ocorreram desde que você bifurcou seus compartilhamentos no Data Box. Essa execução do Robocopy pode terminar rapidamente ou demorar um pouco, dependendo da quantidade de churn que aconteceu em seus compartilhamentos NAS.

Aviso

Devido ao comportamento regressado do Robocopy no Windows Server 2019, a opção Robocopy /MIR não é compatível com diretórios de destino hierárquicos. Não é possível usar o cliente Windows Server 2019 ou Windows 10 para esta fase da migração. Use o Robocopy em uma instância intermediária do Windows Server 2016.

Aqui está a abordagem básica de migração:

  • Execute o Robocopy a partir do dispositivo NAS para sincronizar a instância do Windows Server.
  • Use a Sincronização de Arquivos do Azure para sincronizar os compartilhamentos de arquivos do Azure do Windows Server.

Execute a primeira cópia local para a pasta de destino do Windows Server:

  1. Identifique o primeiro local em seu dispositivo NAS.
  2. Identifique a pasta correspondente na instância do Windows Server que já tem o Azure File Sync configurado nela.
  3. Inicie a cópia usando o Robocopy.

O comando Robocopy a seguir copiará apenas as diferenças (arquivos e pastas atualizados) do armazenamento NAS para a pasta de destino do Windows Server. A instância do Windows Server irá sincronizá-los com os compartilhamentos de arquivos do Azure.

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.

Se você provisionou menos armazenamento em sua instância do Windows Server do que seus arquivos usam no dispositivo NAS, você configurou a hierarquização na nuvem. À medida que o volume local do Windows Server se torna cheio, a hierarquização na nuvem entra em ação e hierarquiza os arquivos que já foram sincronizados com êxito. A hierarquização na nuvem gerará espaço suficiente para continuar a cópia do dispositivo NAS. A hierarquização da nuvem verifica uma vez por hora o que foi sincronizado e para liberar espaço em disco para atingir os 99% de espaço livre de volume.

O Robocopy pode precisar mover mais arquivos do que você pode armazenar localmente na instância do Windows Server. Você pode esperar que o Robocopy se mova mais rápido do que o Azure File Sync pode carregar seus arquivos e hierarquizar-los fora do seu volume local. Nessa situação, o Robocopy falhará. Recomendamos que você trabalhe com os compartilhamentos em uma sequência que impeça esse cenário. Por exemplo, mova apenas compartilhamentos que cabem no espaço livre disponível na instância do Windows Server. Ou evite iniciar trabalhos do Robocopy para todas as ações ao mesmo tempo. A boa notícia é que o /MIR switch garantirá que apenas deltas sejam movidos. Depois que um delta for movido, um trabalho reiniciado não precisará mover o arquivo novamente.

Faça a transição

Quando você executa o comando Robocopy pela primeira vez, seus usuários e aplicativos ainda estarão acessando arquivos no NAS e potencialmente alterando-os. Robocopy irá processar um diretório e, em seguida, passar para o próximo. Um usuário no NAS pode então adicionar, alterar ou excluir um arquivo no primeiro diretório que não será processado durante a execução atual do Robocopy. Este comportamento é esperado.

A primeira execução é sobre como mover a maior parte dos dados alterados para sua instância do Windows Server e para a nuvem por meio da Sincronização de Arquivos do Azure. Esta primeira cópia pode demorar muito tempo, dependendo de:

  • A largura de banda de upload.
  • A velocidade da rede local e quão idealmente o número de threads do Robocopy corresponde a ela.
  • O número de itens (arquivos e pastas) que precisam ser processados pelo Robocopy e pela Sincronização de Arquivos do Azure.

Após a conclusão da execução inicial, execute o comando novamente.

O Robocopy terminará mais rápido na segunda vez que você executá-lo para um compartilhamento. Precisa transportar apenas as mudanças que aconteceram desde a última corrida. Você pode executar trabalhos repetidos para o mesmo compartilhamento.

Ao considerar o tempo de inatividade aceitável, você precisa remover o acesso do usuário aos seus compartilhamentos baseados em NAS. Você pode fazer isso de qualquer maneira que impeça os usuários de alterar a estrutura de arquivos e pastas e o conteúdo. Por exemplo, você pode apontar seu namespace DFS para um local que não existe ou alterar as ACLs raiz no compartilhamento.

Execute o Robocopy uma última vez. Ele vai pegar todas as alterações que foram perdidas. Quanto tempo demora este passo final depende da velocidade da varredura Robocopy. Você pode estimar o tempo (que é igual ao seu tempo de inatividade) medindo a duração da execução anterior.

Crie um compartilhamento na pasta do Windows Server e, possivelmente, ajuste sua implantação do DFS-N para apontar para ele. Certifique-se de definir as mesmas permissões de nível de compartilhamento que estão em seu compartilhamento SMB NAS. Se você tiver um NAS ingressado em domínio de classe empresarial, os SIDs do usuário corresponderão automaticamente porque os usuários estão no Ative Directory e o Robocopy copia arquivos e metadados com total fidelidade. Se você usou usuários locais em seu NAS, você precisa:

  • Recrie esses usuários como usuários locais do Windows Server.
  • Mapeie os SIDs existentes que o Robocopy moveu para sua instância do Windows Server para os SIDs de seus novos usuários locais do Windows Server.

Você terminou de migrar um compartilhamento ou grupo de compartilhamentos para uma raiz ou volume comum (dependendo do seu mapeamento da Fase 1).

Você pode tentar executar algumas dessas cópias em paralelo. Recomendamos que você processe o escopo de um compartilhamento de arquivos do Azure de cada vez.

Opção preterida: "transferência de dados offline"

Antes do lançamento da versão 13 do agente do Azure File Sync, a integração do Data Box era realizada por meio de um processo chamado "transferência de dados offline". Esse processo foi preterido e você não pode mais criar um ponto de extremidade do servidor no modo "transferência de dados offline". Com a versão 13 do agente, ele foi substituído pelas etapas muito mais simples e rápidas descritas neste artigo.

Resolução de Problemas

O problema mais comum é que o comando Robocopy falhe com "Volume cheio" no lado do Windows Server. A hierarquização na nuvem atua uma vez a cada hora para evacuar o conteúdo do disco local do Windows Server sincronizado. Seu objetivo é alcançar 99% de espaço livre no volume.

Permita que o progresso da sincronização e a hierarquização da nuvem liberem espaço em disco. Você pode observar isso no Explorador de Arquivos em sua instância do Windows Server.

Quando a instância do Windows Server tiver capacidade disponível suficiente, execute o comando novamente para resolver o problema. Nada quebra nesta situação. Pode avançar com confiança. O inconveniente de executar o comando novamente é a única consequência.

Para solucionar problemas do Azure File Sync, consulte o artigo listado na próxima seção.

Próximos passos

Os artigos a seguir ajudarão você a entender as opções avançadas e as práticas recomendadas para Arquivos do Azure e Sincronização de Arquivos do Azure.