Share via

Use o Data Box para migrar do NAS (Armazenamento Conectado à Rede) para uma implantação em nuvem híbrida com a Sincronização de Arquivos do Azure

  • Artigo

Este artigo sobre migração é um dos vários que envolvem as palavras-chave NAS, Sincronização de Arquivos do Azure e Azure Data Box. Verifique se este artigo se aplica ao seu cenário:

  • Fonte de dados: NAS (Armazenamento Conectado à Rede)
  • Rota de migração: NAS ⇒ Data Box ⇒ compartilhamento de arquivo do Azure ⇒ sincronização com o Windows Server
  • Cache de arquivos locais: sim, o objetivo final é a implantação da Sincronização de Arquivos do Azure

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

A Sincronização de Arquivos do Azure funciona em locais de DAS (Armazenamento com Conexão Direta). No entanto, o serviço não é compatível com a sincronização com locais de NAS (Armazenamento Conectado à Rede). Portanto, você precisa migrar seus arquivos. Este artigo orienta o planejamento e a implementação dessa migração.

Aplica-se a

Tipo de compartilhamento de arquivos SMB NFS
Compartilhamentos de arquivos padrão (GPv2), LRS/ZRS Sim Não
Compartilhamentos de arquivos padrão (GPv2), GRS/GZRS Sim Não
Compartilhamento de arquivos premium (FileStorage), LRS/ZRS Sim Não

Metas de migração

O objetivo é mover os compartilhamentos do dispositivo NAS para o Windows Server. Em seguida, utilizar a Sincronização de Arquivos do Azure para a implantação em 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. O último requer um mínimo de tempo de inatividade para se ajustar ou ter uma janela um pouco maior do que a da manutenção regular.

Visão geral da migração

O processo de migração consiste em várias fases. Você precisará:

  • Implantar contas de armazenamento e compartilhamentos de arquivos do Azure.
  • Implantar um computador local que execute o Windows Server.
  • Configurar a Sincronização de Arquivos do Azure.
  • Migrar arquivos usando o Robocopy.
  • Fazer a transferência.

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

Dica

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

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

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

Você pode ter mais pastas em seus volumes que você compartilha localmente no momento como compartilhamentos SMB para seus usuários e aplicativos. A maneira mais fácil de descrever esse cenário é prever um compartilhamento local que mapeia 1:1 para um compartilhamento de arquivos do Azure. Se você tem um número pequeno suficiente de compartilhamentos, ou seja, menos de 30 para uma só instância do Windows Server, é recomendado um mapeamento de 1:1.

Se você tem mais de 30 compartilhamentos, geralmente não é necessário fazer o mapeamento de 1:1 de um compartilhamento local para um compartilhamento de arquivo do Azure. Considere as opções a seguir.

Agrupamento de compartilhamentos

Por exemplo, se o departamento de RH (Recursos Humanos) tiver 15 compartilhamentos, considere o armazenamento de todos os dados de RH em um só compartilhamento de arquivo 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

A Sincronização de Arquivos do Azure dá suporte à sincronização da raiz de um volume para um compartilhamento de arquivos do Azure. Se você sincronizar a raiz do volume, todas as subpastas e arquivos vão para o mesmo compartilhamento de arquivos do Azure.

A sincronização da raiz do volume nem sempre é a melhor opção. Há benefícios em sincronizar várias localizações. Por exemplo, isso ajuda a manter um menor número de itens por escopo de sincronização. Testamos os compartilhamentos de arquivo do Azure e a Sincronização de Arquivos do Azure com 100 milhões de itens (arquivos e pastas) por compartilhamento. Mas a prática recomendada é tentar manter o número abaixo de 20 ou 30 milhões em um só compartilhamento. A configuração da Sincronização de Arquivos do Azure com um número menor de itens traz benefícios não só para a sincronização de arquivos, mas também para cenários como estes:

  • O exame inicial do conteúdo da nuvem pode ser concluído com mais rapidez, o que 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 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 arquivo do Azure (fora da sincronização) podem ser detectadas e sincronizadas com mais rapidez.

Dica

Se você não sabe quantos arquivos e pastas tem, confira 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 da Sincronização de Arquivos do Azure você provisionará. Um grupo de sincronização vincula o compartilhamento de arquivos do Azure e a pasta em seu servidor em conjunto e estabelece uma conexão de sincronização.

Para decidir de quantos compartilhamentos de arquivo do Azure você precisa, examine os limites e as práticas recomendadas a seguir. Isso ajudará você a otimizar seu mapa.

  • Um servidor no qual o agente da Sincronização de Arquivos do Azure está instalado pode ser sincronizado com até 30 compartilhamentos de arquivo do Azure.

  • Um compartilhamento de arquivo do Azure é implantado em uma conta de armazenamento. Essa organização faz com que a conta de armazenamento seja uma meta 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 arquivo do Azure. O ideal seria mapear os compartilhamentos de arquivo um a um com as contas de armazenamento. No entanto, isso nem sempre é possível devido a vários limites e restrições, tanto da organização quanto do Azure. Quando não for possível ter apenas um compartilhamento de arquivo implantado em uma conta de armazenamento, considere quais compartilhamentos serão altamente ativos e quais serão menos ativos para garantir que os compartilhamentos de arquivos mais frequentes não sejam colocados na mesma conta de armazenamento.

    Se você planeja transferir para o Azure um aplicativo que usará o compartilhamento de arquivo do Azure de modo nativo, talvez seja necessário mais desempenho no compartilhamento de arquivo do Azure. Se esse tipo de uso for uma possibilidade, mesmo que futura, é melhor criar um só compartilhamento de arquivo Standard do Azure na respectiva conta de armazenamento.

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

Dica

Considerando essas informações, geralmente é necessário agrupar várias pastas de nível superior dos volumes em um novo diretório raiz comum. Em seguida, você sincroniza esse novo diretório raiz e todas as pastas que você agrupou para ele para um único compartilhamento de arquivos do Azure. Essa técnica permite que você permaneça dentro do limite de 30 sincronizações de compartilhamento de arquivos do Azure por servidor.

Esse agrupamento em uma raiz comum não afeta o acesso aos dados. As ACLs continuam como estão. Você só precisa ajustar os caminhos dos compartilhamentos (como compartilhamentos SMB ou NFS) que estão nas pastas do servidor local que foram alteradas para uma raiz comum. Nada mais muda.

Importante

O vetor de escala mais importante da Sincronização de Arquivos do Azure é o número de itens (arquivos e pastas) que precisam ser sincronizados. Examine os destinos de escala de sincronização de arquivos do Azure para obter mais detalhes.

É uma prática recomendada manter o número de itens por escopo de sincronização baixo. Esse é um fator importante a ser considerado no mapeamento de pastas para compartilhamentos de arquivos do Azure. Sincronização de Arquivos do Azure é testado com 100 milhões itens (arquivos e pastas) por compartilhamento. Mas geralmente é melhor manter o número de itens abaixo de 20 ou 30 milhões em um só compartilhamento. Divida o 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 mais abaixo desses números. Essa prática fornecerá espaço para crescer.

Na sua situação, é possível que um conjunto de pastas seja sincronizado logicamente com o mesmo compartilhamento de arquivo do Azure (usando a nova abordagem de pasta raiz comum já mencionada). Mas talvez ainda seja melhor reagrupar as pastas para que elas sejam sincronizadas com dois compartilhamentos de arquivo do Azure em vez de um. Você pode usar essa abordagem para manter o número de arquivos e pastas por compartilhamento de arquivos balanceados pelo servidor. Você também pode dividir os compartilhamentos locais e sincronizá-los entre mais servidores locais adicionando a capacidade de sincronização com mais 30 compartilhamentos de arquivo do Azure por servidor extra.

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

# Cenário de sincronização Com suporte Considerações (ou limitações) Solução (ou solução alternativa)
1 Servidor de arquivos com vários discos/volumes e vários compartilhamentos para o mesmo compartilhamento de arquivos do Azure de destino (consolidação) No Um compartilhamento de arquivos do Azure de destino (ponto de extremidade de nuvem) dá suporte apenas à sincronização com um grupo de sincronização.

Um grupo de sincronização dá suporte apenas a um ponto de extremidade de servidor por servidor registrado.		 1) Comece sincronizando um disco (seu volume raiz) para direcionar o compartilhamento de arquivos do Azure. Começar com o maior disco/volume ajudará com os requisitos de armazenamento local. Configure a camada de nuvem para colocar todos os dados em camadas na nuvem, liberando assim espaço no disco do servidor de arquivos. Mova dados de outros volumes/compartilhamentos para o volume atual que está sendo sincronizado. Continue as etapas uma a uma até que todos os dados estejam em camadas para nuvem/migrados.
2) Direcione um volume raiz (disco) por vez. Use a camada de nuvem para colocar todos os dados em camadas para direcionar o compartilhamento de arquivos do Azure. 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. Observação: a reinstalação do agente pode ser necessária.
3) Recomendar 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 arquivos com volume único e vários compartilhamentos para o mesmo compartilhamento de arquivos do Azure de destino (consolidação) Yes 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) Raiz de sincronização 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 arquivos com vários compartilhamentos e/ou volumes para vários compartilhamentos de arquivos do Azure em uma única conta de armazenamento (mapeamento de compartilhamento 1:1) Sim Uma única instância do Windows Server (ou cluster) 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 compartilhados entre compartilhamentos de arquivos.

Mantenha o número de itens por grupo de sincronização em 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 com os quais sincronizar).
2) Somente 30 compartilhamentos podem ser sincronizados neste cenário por vez. Se você tiver mais de 30 compartilhamentos nesse servidor de arquivos, use Conceito de agrupamento de compartilhamento e Sincronização de volume para reduzir o número de pastas raiz ou de nível superior na origem.
3) Use servidores adicionais de Sincronização de Arquivos 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 diferentes contas de armazenamento (mapeamento de compartilhamento 1:1) Sim Uma única instância do Windows Server (ou cluster) pode sincronizar até 30 compartilhamentos de arquivos do Azure.

Mantenha o número de itens por grupo de sincronização em 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 a mencionada 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 diretrizes no Cenário nº 1 acima com consideração adicional sobre como direcionar um servidor de arquivos por vez.

Criar uma tabela de mapeamento

Diagrama que mostra um exemplo de uma tabela de mapeamento. Baixe o arquivo a seguir para experimentar e usar o conteúdo desta imagem.

Use as informações anteriores para determinar quantos compartilhamentos de arquivo do Azure são necessários e quais dos dados existentes serão enviados para qual compartilhamento de arquivo do Azure.

Crie uma tabela para registrar suas conclusões que possa ser consultada sempre que necessário. Manter-se organizado é importante porque pode ser fácil perder detalhes do seu plano de mapeamento quando você estiver provisionando muitos recursos do Azure de uma vez. Baixe o arquivo do Excel a seguir para usá-lo como um modelo na criação do 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 para registrar o provisionamento do número correto de contas de armazenamento do Azure e seus respectivos compartilhamentos de arquivos.

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ê tem compartilhamentos altamente ativos (compartilhamentos usados por muitos usuários e/ou aplicativos), dois compartilhamentos de arquivo 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 arquivo do Azure na mesma conta de armazenamento em caso de compartilhamentos de arquivamento ou de pouca atividade nos compartilhamentos.

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 a Sincronização de Arquivos do Azure nesses compartilhamentos, basta agrupar vários deles em uma só conta de armazenamento do Azure.

Se você já fez uma lista dos seus compartilhamentos, mapeie cada um deles para a conta de armazenamento na qual residirá.

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

Certifique-se de que a região de cada uma de suas contas de armazenamento seja a mesma e corresponda à região do recurso de serviço de sincronização de armazenamento que você já implantou.

Cuidado

Se você criar um compartilhamento de arquivo do Azure com um limite de 100 TiB, esse compartilhamento poderá usar apenas as opções de armazenamento com redundância local ou 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 arquivo do Azure para criar um compartilhamento de arquivo grande.

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

Os nomes de 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 os compartilhamentos de arquivo do Azure, use nomes semelhantes aos usados para as contrapartes locais.

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

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

Nesta fase, é necessário mapear os resultados do plano de migração da fase anterior para os limites das opções de Data Box disponíveis. Essas considerações ajudam a criar um plano referente a quais opções de Data Box você deve escolher e quantos são necessários para mover seus compartilhamentos de NAS para os compartilhamentos de arquivos do Azure.

Para determinar de quantos dispositivos de cada tipo você precisa, considere estes limites importantes:

  • Qualquer dispositivo do Azure Data Box pode mover dados para até dez contas de armazenamento.
  • Cada opção de Data Box vem com sua própria capacidade de uso. Confira Opções do Data Box.

Consulte seu plano de migração para saber o número de contas de armazenamento que você decidiu criar e os compartilhamentos em cada uma delas. Em seguida, examine o tamanho de cada um dos compartilhamentos em seu NAS. A combinação dessas informações permite 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 divida o conteúdo de um único compartilhamento de arquivo entre dois Data Box.

Opções do Data Box

Para uma migração padrão, uma ou a combinação dessas opções de Data Box deve ser escolhida:

  • Data Box Disk. A Microsoft enviará de um a cinco discos SSD com uma capacidade de 8 TiB cada, até um total máximo de 40 TiB. A capacidade usável é cerca de 20% menor devido à criptografia e à sobrecarga do sistema de arquivos. Para saber mais, confira a documentação do Data Box Disk.
  • Data Box. Esta é a opção mais comum. A Microsoft enviará a você um dispositivo Data Box robusto que funciona de modo semelhante a um NAS. Ele tem uma capacidade utilizável de 80 TiB. Para saber mais, confira a documentação do Data Box Disk.
  • Data Box Heavy. Esta opção apresenta um dispositivo Data Box robusto sob rodas, que funciona de forma semelhante a um NAS, com uma capacidade de 1 PiB. A capacidade usável é cerca de 20% menor devido à criptografia e à sobrecarga do sistema de arquivos. Para saber mais, confira a documentação do Data Box Heavy.

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

Enquanto aguarda seus dispositivos Data Box do Azure chegarem, você já pode começar a avaliar as necessidades de uma ou mais instâncias do Windows Server para usar com a Sincronização de Arquivos do Azure.

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

A configuração do recurso (computação e RAM) da instância do Windows Server implantada depende principalmente do número de arquivos e pastas que serão sincronizados. Se estiver em dúvida, recomenda-se uma configuração de alto desempenho.

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

Observação

O artigo vinculado anteriormente apresenta uma tabela com uma escala para a memória do servidor (RAM). Você pode usar números na extremidade inferior da escala para o servidor, mas a sincronização inicial deve demorar bem mais.

Fase 5: copiar arquivos para o Data Box

Quando o seu Data Box chegar, você precisará configurá-lo com uma conectividade de rede sem impedimentos para seu dispositivo NAS. Siga a documentação de instalação para o tipo de Data Box que você solicitou:

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

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

  • Se os 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 arquivos forem para uma conta de armazenamento Standard, haverá três compartilhamentos SMB por conta de armazenamento Standard (GPv1 e GPv2). Somente os compartilhamentos de arquivos que terminam com _AzFiles são relevantes para sua migração. Ignore quaisquer compartilhamentos de bloco e de blob de página.

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

  1. Conectar-se ao Data Box.
  2. Copie dados para o Data Box.
    Você pode usar o Robocopy (siga a instrução abaixo) ou o novo serviço de cópia de dados do Data Box.
  3. Preparar o Data Box para upload no Azure.

Dica

Como alternativa ao Robocopy, o Data Box criou um serviço de cópia de dados. Ele pode ser usado para carregar arquivos em seu Data Box com fidelidade total. 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 arquivo e pasta. 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 que o Robocopy execute multithreading. O padrão de n é 8. O máximo é 128 threads. Embora uma alta contagem de threads ajude a saturar a largura de banda disponível, isso não significa que a migração sempre será mais rápida com mais threads. Testes com Arquivos do Azure indicam que entre 8 e 20 mostra um desempenho equilibrado para uma execução de cópia inicial. Execuções /MIR subsequentes são afetadas progressivamente pela computação disponível vs. largura de banda de rede disponível. Para as execuções subsequentes, relacione de forma mais aproximada o valor de contagem de threads com a contagem de núcleos do processador e a contagem de threads por núcleo. Considere se os núcleos precisam ser reservados para outras tarefas que um servidor de produção possa ter. Testes com o serviço Arquivos do Azure mostraram que até 64 threads produzem um bom desempenho, mas somente se os processadores puderem mantê-los ativos ao mesmo tempo.
/R:n Contagem máxima de novas tentativas de um arquivo cuja primeira tentativa de cópia falha. O Robocopy tentará n vezes antes que o arquivo falhe permanentemente ao copiar na execução. É possível otimizar o desempenho de sua execução: escolha um valor de dois ou três se você acreditar que os problemas de tempo limite causaram falhas no passado. Isso pode ser mais comum em links de WAN. Escolha não tentar novamente ou um valor de um se você acreditar que o arquivo falhou ao copiar porque estava ativamente em uso. Tentar novamente alguns segundos depois poderá não ser tempo suficiente para que o estado em uso do arquivo seja alterado. Os usuários ou os aplicativos que mantêm o arquivo aberto podem precisar de horas a mais. Nesse caso, aceitar que o arquivo não foi copiado e capturá-lo em uma de suas execuções de Robocopy subsequentes planejadas, pode conseguir eventualmente copiar o arquivo com êxito. Isso ajuda a execução atual a concluir mais rapidamente sem ser prolongada pelo excesso de tentativas que, basicamente, resulta na maioria das 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 espera para tentar copiar um arquivo que não foi copiado com êxito em uma tentativa anterior. n é o número de segundos de espera entre as novas tentativas. /W:n geralmente é usado junto com /R:n.
/B Executa o Robocopy do mesmo modo que um aplicativo de backup faria. Essa opção permite que o Robocopy mova arquivos para os quais o usuário atual não tem permissões. A opção de backup depende da execução do comando do Robocopy em um console elevado de administrador ou janela do PowerShell. Se você usar o Robocopy para Arquivos do Azure, monte o compartilhamento de Arquivos do Azure usando a chave de acesso da conta de armazenamento vs. uma identidade de domínio. Caso contrário, as mensagens de erro podem não levar intuitivamente a uma resolução do problema.
/MIR (Espelhar a origem para o destino.) Permite que o Robocopy copie apenas os deltas entre a origem e o destino. Subdiretórios vazios serão copiados. Itens (arquivos ou pastas) que foram alterados ou que não existem no destino serão copiados. Os itens que existem no destino, mas não na origem, serão eliminados (excluídos) do destino. Ao usar essa opção, faça a correspondência exata das estruturas de pasta de origem e de destino. Fazer a correspondência significa copiar do nível correto de pasta da origem para o nível de pasta correspondente no destino. Somente dessa maneira uma cópia "atualizada" pode ser bem-sucedida. Quando a origem e o destino não corresponderem, o uso de /MIR causará exclusões e novas cópias em grande escala.
/IT Garante que a fidelidade seja preservada em determinados cenários de espelhamento.
Por exemplo, se um arquivo apresentar uma alteração de ACL e uma atualização de atributo entre duas execuções do Robocopy, ele será marcado como oculto. Sem /IT, a alteração de ACL pode não ser percebida pelo Robocopy e não ser transferida para o local de destino.
/COPY:[copyflags] A fidelidade da cópia do arquivo. Padrão: /COPY:DAT. Sinalizadores de cópia: D = Dados, A = Atributos, T = Carimbos de data/hora, S = Segurança = NTFS ACLs, O = Informações do proprietário, U = InforDções de auditoria. As informações de auditoria não podem ser armazenadas em um compartilhamento de arquivo do Azure.
/DCOPY:[copyflags] Fidelidade da 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 não será exibido o progresso da cópia de cada arquivo e pasta. A exibição do progresso reduz significativamente o desempenho da cópia.
/NFL Especifica que os nomes de arquivo não são registrados. Melhora o desempenho da cópia.
/NDL Especifica que os nomes de diretório não são registrados. 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 System Volume Information oculta. Se usado conforme projetado, todas as informações serão específicas para o volume exato desse sistema exato e poderão 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 esse conteúdo para trás não deverá 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 somente devem ser listados. Eles não serão copiados, não excluídos e não terão carimbo de data/hora. Usado com frequência com /TEE para saída do console. Os sinalizadores do script de exemplo, como /NP, /NFL e /NDL, talvez precisem ser removidos para que você possa obter os resultados de teste documentados corretamente.
/LFSM Somente para destinos com armazenamento em camadas. Não há suporte quando o destino é um compartilhamento remoto de protocolo SMB.
Especifica que o Robocopy opera em "modo de espaço livre baixo". Esta opção é útil apenas para destinos com armazenamento em camadas que podem ficar sem capacidade local antes que o Robocopy conclua a operação. Ela foi adicionada especificamente para ser usada com um destino habilitado para a camada de nuvem da Sincronização de Arquivos do Azure. Ela pode ser usada independentemente da Sincronização de Arquivos do Azure. Nesse modo, o Robocopy fará uma pausa sempre que uma cópia de arquivo puder fazer com que o espaço livre do volume de destino fique abaixo de um valor base. Esse valor pode ser especificado pela forma /LFSM:n do sinalizador. O parâmetro n é especificado na base 2: nKB, nMB ou nGB. Se /LFSM for especificado sem nenhum valor de piso explícito, o piso será definido como dez por cento do tamanho do volume de destino. O modo de pouco espaço livre não é compatível com /MT, /EFSRAW ou /ZB. O suporte a /B foi adicionado ao Windows Server 2022. Confira a seção Windows Server 2022 e RoboCopy LFSM abaixo para obter mais informações, incluindo detalhes sobre um bug relacionado e uma solução alternativa.
/Z Usar com cautela
Copia os arquivos no modo de reinicialização. Essa opção é recomendada somente em um ambiente de rede instável. Ela reduz significativamente o desempenho da cópia devido ao registro em log extra.
/ZB Usar com cautela
Usa o modo de reinicialização. Se o acesso for negado, esta opção usa o modo backup. Essa opção reduz significativamente o desempenho da cópia devido ao ponto de verificação.

Importante

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

Fase 6: implantar o recurso em nuvem da Sincronização de Arquivos do Azure

Antes de continuar com este guia, aguarde até que todos os arquivos estejam nos compartilhamentos de arquivos corretos do Azure. O processo de envio e ingestão de dados do Data Box demora.

Para concluir esta etapa, você precisa das credenciais da sua assinatura do Azure.

O recurso principal a ser Sincronização de Arquivos do Azure é 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, a prática recomendada é usar somente um Serviço de Sincronização de Armazenamento.

Escolha uma região do Azure para seu Serviço de Sincronização de Armazenamento próximo à sua localização. Todos os outros recursos de nuvem precisam ser implantados no mesma região. Para simplificar o gerenciamento, crie um novo grupo de recursos em sua assinatura que armazene recursos de sincronização e armazenamento.

Para obter mais informações, confira a seção sobre como implantar o Serviço de Sincronização de Armazenamento no artigo sobre como implantar a Sincronização de Arquivos do Azure. Siga somente essa seção do artigo. Haverá links para outras seções do artigo em etapas posteriores.

Fase 7: implantar o agente da Sincronização de Arquivos do Azure

Nesta seção, você instalará o agente de Sincronização de Arquivos do Azure 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. Essa medida de segurança não é aplicável com a Sincronização de Arquivos do Azure. Essa desativação permite que você se autentique no Azure sem nenhum problema.

Abra o PowerShell. Instale os módulos do PowerShell necessários usando os comandos a seguir. Instale o módulo completo e o provedor do NuGet quando isso for solicitado.

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

Se houver algum problema para acessar a Internet por meio do servidor, este é o momento de solucioná-lo. Sincronização de Arquivos do Azure usa qualquer conexão de rede disponível com a Internet. Também há suporte para exigir um servidor proxy para acessar a Internet. Você pode configurar um proxy para o computador todo agora ou, durante a instalação do agente, especificar um proxy que só a Sincronização de Arquivos do Azure usará.

Se a configuração de um proxy significa que você precisa abrir os 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 exatas do ponto de extremidade no Azure que Sincronização de Arquivos do Azure precisa se comunicar com a região que você selecionou. O relatório também informa por que a comunicação é necessária. Você pode usar o relatório para bloquear os firewalls relacionados ao servidor para URLs específicas.

Você também pode usar uma abordagem mais conservadora na qual os firewalls não são abertos amplamente. Nesse caso, você pode limitar o servidor para se comunicar com namespaces de DNS de nível superior. Para obter mais informações, consulte Configurações de firewall e proxy da Sincronização de Arquivos do Azure . 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 anteriormente.

Essas etapas são descritas mais detalhadamente no guia de implantação, que inclui os módulos do PowerShell que você deve instalar primeiro: Instalação do agente da Sincronização de Arquivos do Azure.

Use o agente mais recente. É possível baixá-lo do Centro de Download da Microsoft: Agente de Sincronização de Arquivos do Azure.

Após o sucesso da instalação e do registro do servidor, você pode confirmar que concluiu esta etapa com êxito. Vá até o recurso do Serviço de Sincronização de Armazenamento no portal do Azure. No menu à esquerda, acesse Servidores registrados. Você verá o servidor listado lá.

Fase 8: configurar a Sincronização de Arquivos do Azure na instância do Windows Server

Para esse processo, a instância local do Windows Server registrado deve estar pronta e conectada à internet.

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

  1. Entre 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 arquivo do Azure. Na terminologia da Sincronização de Arquivos do Azure, o compartilhamento de arquivo 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ê a ele um nome familiar para que você reconheça qual conjunto de arquivos é sincronizado lá. Certifique-se de fazer referência ao compartilhamento de arquivos do Azure com um nome correspondente.
  4. Depois que você criar o grupo de sincronização, uma linha para ele será exibida na lista de grupos de sincronização. Selecione o nome (um link) para exibir o conteúdo do grupo de sincronização. Você verá o 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ê provisionar se tornará o caminho para esse ponto de extremidade do servidor.

Ative o recurso de camada de nuvem e selecione Somente namespace na seção de download inicial.

Importante

A camada de nuvem é o recurso da Sincronização de Arquivos do Azure que permite que o servidor local tenha menos capacidade de armazenamento do que o armazenado na nuvem, mas que tenha o namespace completo disponível. Dados importantes do local também são armazenados em cache localmente para desempenho rápido nos acessos. A camada de nuvem é opcional. Você pode defini-la individualmente para cada ponto de extremidade do servidor da Sincronização de Arquivos do Azure. Esse recurso é necessário se não houver capacidade de disco local suficiente na instância do Windows Server para manter todos os dados na nuvem e se quiser evitar o download de todos os dados da nuvem.

Em 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 do 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 esteja concluída.

Observação

Após a criação de um ponto de extremidade do servidor, a sincronização estrará funcionando. No entanto, a sincronização precisa enumerar (descobrir) os arquivos e as pastas que você moveu via Data Box para o compartilhamento de arquivos do Azure. Dependendo do tamanho do namespace, pode demorar até o namespace da nuvem aparecer no servidor.

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

Não avance nas próximas etapas da migração até que o servidor baixe todo o namespace do compartilhamento em nuvem. Se você começar a mover os arquivos para o servidor antes da hora, podem ocorrer carregamentos desnecessários e até mesmo conflitos de sincronização de arquivos.

Para saber se o servidor concluiu a sincronização do download inicial, abra o Visualizador de Eventos no Windows Server em sincronização e use o log de eventos de telemetria da Sincronização de Arquivos do Azure. No Visualizador de Eventos, o log do evento de telemetria está localizado em Aplicativos e Serviços\Microsoft\FileSync\Agent.

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

Precisam existir dois eventos consecutivos desse tipo, com este conteúdo, para garantir que o servidor concluiu o download do namespace. Tudo bem se houver outros eventos entre os dois eventos 9102.

Fase 10: executar o Robocopy do NAS

Depois que o servidor concluir a sincronização inicial de todo o namespace no compartilhamento em nuvem, você pode continuar com esta etapa. A sincronização inicial deve ser concluída antes de continuar com esta etapa. Confira a seção anterior para saber dos detalhes.

Nesta etapa, você executa os trabalhos do RoboCopy para sincronizar seus compartilhamentos em nuvem com as alterações mais recentes de seu NAS desde o momento em que você fez a bifurcação de seus compartilhamentos para o Data Box. Essa execução do RoboCopy pode terminar rapidamente ou demorar, dependendo da quantidade de rotatividade que aconteceu em seus compartilhamentos NAS.

Aviso

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

Esta é a abordagem de migração básica:

  • Execute o Robocopy do dispositivo NAS para sincronizar sua 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 em sua 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 a Sincronização de Arquivos do Azure configurada nela.
  3. Inicie a cópia usando o RoboCopy.

O comando RoboCopy a seguir copia apenas as diferenças (arquivos e pastas atualizados) do armazenamento NAS para a pasta de destino do Windows Server. Em seguida, o Windows Server os sincroniza 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 que o Robocopy execute multithreading. O padrão de n é 8. O máximo é 128 threads. Embora uma alta contagem de threads ajude a saturar a largura de banda disponível, isso não significa que a migração sempre será mais rápida com mais threads. Testes com Arquivos do Azure indicam que entre 8 e 20 mostra um desempenho equilibrado para uma execução de cópia inicial. Execuções /MIR subsequentes são afetadas progressivamente pela computação disponível vs. largura de banda de rede disponível. Para as execuções subsequentes, relacione de forma mais aproximada o valor de contagem de threads com a contagem de núcleos do processador e a contagem de threads por núcleo. Considere se os núcleos precisam ser reservados para outras tarefas que um servidor de produção possa ter. Testes com o serviço Arquivos do Azure mostraram que até 64 threads produzem um bom desempenho, mas somente se os processadores puderem mantê-los ativos ao mesmo tempo.
/R:n Contagem máxima de novas tentativas de um arquivo cuja primeira tentativa de cópia falha. O Robocopy tentará n vezes antes que o arquivo falhe permanentemente ao copiar na execução. É possível otimizar o desempenho de sua execução: escolha um valor de dois ou três se você acreditar que os problemas de tempo limite causaram falhas no passado. Isso pode ser mais comum em links de WAN. Escolha não tentar novamente ou um valor de um se você acreditar que o arquivo falhou ao copiar porque estava ativamente em uso. Tentar novamente alguns segundos depois poderá não ser tempo suficiente para que o estado em uso do arquivo seja alterado. Os usuários ou os aplicativos que mantêm o arquivo aberto podem precisar de horas a mais. Nesse caso, aceitar que o arquivo não foi copiado e capturá-lo em uma de suas execuções de Robocopy subsequentes planejadas, pode conseguir eventualmente copiar o arquivo com êxito. Isso ajuda a execução atual a concluir mais rapidamente sem ser prolongada pelo excesso de tentativas que, basicamente, resulta na maioria das 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 espera para tentar copiar um arquivo que não foi copiado com êxito em uma tentativa anterior. n é o número de segundos de espera entre as novas tentativas. /W:n geralmente é usado junto com /R:n.
/B Executa o Robocopy do mesmo modo que um aplicativo de backup faria. Essa opção permite que o Robocopy mova arquivos para os quais o usuário atual não tem permissões. A opção de backup depende da execução do comando do Robocopy em um console elevado de administrador ou janela do PowerShell. Se você usar o Robocopy para Arquivos do Azure, monte o compartilhamento de Arquivos do Azure usando a chave de acesso da conta de armazenamento vs. uma identidade de domínio. Caso contrário, as mensagens de erro podem não levar intuitivamente a uma resolução do problema.
/MIR (Espelhar a origem para o destino.) Permite que o Robocopy copie apenas os deltas entre a origem e o destino. Subdiretórios vazios serão copiados. Itens (arquivos ou pastas) que foram alterados ou que não existem no destino serão copiados. Os itens que existem no destino, mas não na origem, serão eliminados (excluídos) do destino. Ao usar essa opção, faça a correspondência exata das estruturas de pasta de origem e de destino. Fazer a correspondência significa copiar do nível correto de pasta da origem para o nível de pasta correspondente no destino. Somente dessa maneira uma cópia "atualizada" pode ser bem-sucedida. Quando a origem e o destino não corresponderem, o uso de /MIR causará exclusões e novas cópias em grande escala.
/IT Garante que a fidelidade seja preservada em determinados cenários de espelhamento.
Por exemplo, se um arquivo apresentar uma alteração de ACL e uma atualização de atributo entre duas execuções do Robocopy, ele será marcado como oculto. Sem /IT, a alteração de ACL pode não ser percebida pelo Robocopy e não ser transferida para o local de destino.
/COPY:[copyflags] A fidelidade da cópia do arquivo. Padrão: /COPY:DAT. Sinalizadores de cópia: D = Dados, A = Atributos, T = Carimbos de data/hora, S = Segurança = NTFS ACLs, O = Informações do proprietário, U = InforDções de auditoria. As informações de auditoria não podem ser armazenadas em um compartilhamento de arquivo do Azure.
/DCOPY:[copyflags] Fidelidade da 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 não será exibido o progresso da cópia de cada arquivo e pasta. A exibição do progresso reduz significativamente o desempenho da cópia.
/NFL Especifica que os nomes de arquivo não são registrados. Melhora o desempenho da cópia.
/NDL Especifica que os nomes de diretório não são registrados. 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 System Volume Information oculta. Se usado conforme projetado, todas as informações serão específicas para o volume exato desse sistema exato e poderão 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 esse conteúdo para trás não deverá 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 somente devem ser listados. Eles não serão copiados, não excluídos e não terão carimbo de data/hora. Usado com frequência com /TEE para saída do console. Os sinalizadores do script de exemplo, como /NP, /NFL e /NDL, talvez precisem ser removidos para que você possa obter os resultados de teste documentados corretamente.
/LFSM Somente para destinos com armazenamento em camadas. Não há suporte quando o destino é um compartilhamento remoto de protocolo SMB.
Especifica que o Robocopy opera em "modo de espaço livre baixo". Esta opção é útil apenas para destinos com armazenamento em camadas que podem ficar sem capacidade local antes que o Robocopy conclua a operação. Ela foi adicionada especificamente para ser usada com um destino habilitado para a camada de nuvem da Sincronização de Arquivos do Azure. Ela pode ser usada independentemente da Sincronização de Arquivos do Azure. Nesse modo, o Robocopy fará uma pausa sempre que uma cópia de arquivo puder fazer com que o espaço livre do volume de destino fique abaixo de um valor base. Esse valor pode ser especificado pela forma /LFSM:n do sinalizador. O parâmetro n é especificado na base 2: nKB, nMB ou nGB. Se /LFSM for especificado sem nenhum valor de piso explícito, o piso será definido como dez por cento do tamanho do volume de destino. O modo de pouco espaço livre não é compatível com /MT, /EFSRAW ou /ZB. O suporte a /B foi adicionado ao Windows Server 2022. Confira a seção Windows Server 2022 e RoboCopy LFSM abaixo para obter mais informações, incluindo detalhes sobre um bug relacionado e uma solução alternativa.
/Z Usar com cautela
Copia os arquivos no modo de reinicialização. Essa opção é recomendada somente em um ambiente de rede instável. Ela reduz significativamente o desempenho da cópia devido ao registro em log extra.
/ZB Usar com cautela
Usa o modo de reinicialização. Se o acesso for negado, esta opção usa o modo backup. Essa opção reduz significativamente o desempenho da cópia devido ao ponto de verificação.

Importante

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

Se você provisionou menos armazenamento na instância do Windows Server do que seus arquivos ocupam no dispositivo NAS, você configurou a camada de nuvem. Conforme o volume do Windows Server local fica cheio, são iniciados a camada de nuvem e os arquivos da camada que já foram sincronizados com êxito. A camadas de nuvem gera espaço suficiente para continuar a cópia do dispositivo NAS. A camada de nuvem faz verificações uma vez por hora para ver o que foi sincronizado e liberar espaço em disco para atingir os 99% de espaço livre do volume.

O Robocopy pode precisar mover mais arquivos do que você pode armazenar localmente na instância do Windows Server. Espera-se que o RoboCopy mova muito mais rápido do que a Sincronização de Arquivos do Azure possa carregar os arquivos e separá-los do volume local. Nessa situação, o Robocopy falhará. É recomendável trabalhar nos compartilhamentos em uma sequência de etapas que impeça a falha. Por exemplo, mova somente compartilhamentos que caibam no espaço livre disponível na instância do Windows Server. Ou não inicie trabalhos de Robocopy para todos os compartilhamentos ao mesmo tempo. A boa notícia é que a opção /MIR garantirá que apenas os deltas sejam movidos. Depois que um delta for movido, um trabalho reiniciado não precisará mover o arquivo novamente.

Fazer a transferência

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

A primeira execução faz a movimentação em massa dos dados atualizados para a instância do Windows Server e para a nuvem, usando a Sincronização de Arquivos do Azure. Essa primeira cópia pode demorar, dependendo de:

  • Largura de banda de upload.
  • Velocidade da rede local e a otimização correspondente do número de threads do RoboCopy.
  • O número de itens (arquivos e pastas) que precisam ser processados pelo RoboCopy e pela Sincronização de Arquivos do Azure.

Depois que a execução inicial for concluída, execute o comando novamente.

O Robocopy será concluído mais rapidamente na segunda vez em que for executado para um compartilhamento, porque precisa transportar somente as alterações ocorridas desde a última execução. Você pode executar os trabalhos várias vezes para o mesmo compartilhamento.

Se o tempo de inatividade for aceitável, você precisará remover o acesso dos usuários aos seus compartilhamentos no NAS. Você pode fazer isso em qualquer etapa para impedir que os usuários alterem o conteúdo e a estrutura dos arquivos e pastas. Por exemplo, você pode apontar o namespace do DFS para um local que não existe ou alterar as ACLs raiz no compartilhamento.

Execute o Robocopy uma última vez. Ele detecta todas as alterações que possam ter sido perdidas. A duração desta etapa final depende da velocidade da verificação do RoboCopy. Você pode estimar o tempo (que é igual ao seu tempo de inatividade) medindo quanto tempo a execução anterior levou.

Crie um compartilhamento na pasta do Windows Server e ajuste sua implantação do DFS-N para apontar para ele. Não esqueça de definir as mesmas permissões de nível de compartilhamento que estão em seu compartilhamento SMB do NAS. Se o NAS for de classe corporativa e conectado ao domínio, as SIDs do usuário corresponderão automaticamente, porque os usuários estão no Active Directory e o Robocopy copia arquivos e metadados com total fidelidade. Se você usou usuários locais no NAS, será preciso:

  • Recriar esses usuários como usuários locais do Windows Server.
  • Mapear as SIDs existentes que o Robocopy moveu para a instância do Windows Server para as SIDs de seus novos usuários locais do Windows Server.

Você concluiu a migração de um compartilhamento ou de um grupo de compartilhamentos para um volume ou raiz comum (dependendo do mapeamento da Fase 1).

Você pode tentar executar algumas dessas cópias em paralelo. É recomendável processar o escopo de um compartilhamento de arquivo do Azure por vez.

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

Antes do lançamento do agente de Sincronização de Arquivos do Azure versão 13, 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 de servidor no modo de "transferência de dados offline". Com o agente versão 13, esse processo foi substituído por etapas muito mais simples e rápidas descritas neste artigo.

Solução de problemas

O problema mais comum é o comando Robocopy falhar com "Volume cheio" no lado do Windows Server. A camada de nuvem atua uma vez a cada hora para liberar o conteúdo do disco local do Windows Server que foi sincronizado. Seu objetivo é atingir 99% de espaço livre no volume.

Deixe que a sincronização avance e a camada de nuvem libere espaço em disco. Você pode observar isso no Explorador de Arquivos do Windows Server.

Quando a instância do Windows Server tiver capacidade disponível suficiente, reexecute o comando para resolver o problema. Nada falha nessa situação. Você pode avançar com confiança. A inconveniência de executar o comando novamente é a única consequência.

Para solucionar problemas da Sincronização de Arquivos do Azure, confira o artigo listado na próxima seção.

Próximas etapas

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