Share via

Usar o RoboCopy para migrar para compartilhamentos de arquivos do Azure

  • Artigo

Este artigo de migração descreve o uso do RoboCopy para mover ou migrar arquivos para um compartilhamento de arquivos do Azure SMB. O RoboCopy é um utilitário de cópia de arquivos confiável e bem conhecido com um conjunto de recursos que o torna adequado para migrações. Ele usa o protocolo SMB, o que o torna amplamente aplicável a qualquer combinação de origem e destino que suporte SMB.

  • Fontes de dados: qualquer fonte que ofereça suporte ao protocolo SMB, como Network Attached Storage (NAS), servidores Windows ou Linux, outro compartilhamento de arquivos do Azure e muito mais
  • Rota de migração: do armazenamento de origem ⇒ máquina Windows com RoboCopy ⇒ compartilhamento de arquivos do Azure
  • Sem armazenamento em cache de arquivos no local: como o objetivo final é usar os compartilhamentos de arquivos do Azure diretamente na nuvem, não há nenhum plano para usar o Azure File Sync.

Há muitas rotas de migração diferentes para diferentes combinações de origem e implantação. Consulte a tabela de guias de migração para encontrar a migração que melhor se adapta às suas necessidades.

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

AzCopy vs. RoboCopy

AzCopy e RoboCopy são duas ferramentas de cópia de arquivos fundamentalmente diferentes. O RoboCopy usa qualquer versão do protocolo SMB. O AzCopy é uma ferramenta "nascida na nuvem" que pode ser usada para mover dados, desde que o destino esteja no armazenamento do Azure. AzCopy depende de um protocolo REST.

O RoboCopy, como uma ferramenta de cópia confiável baseada no Windows, tem a vantagem de copiar arquivos com total fidelidade. O RoboCopy suporta muitos cenários de migração devido ao seu rico conjunto de recursos e à capacidade de copiar arquivos e pastas com total fidelidade. Confira a seção fidelidade de arquivos no artigo de visão geral da migração para saber mais sobre a importância de copiar arquivos com a máxima fidelidade possível.

AzCopy, por outro lado, só recentemente se expandiu para suportar cópia de arquivos com alguma fidelidade e adicionou os primeiros recursos necessários para ser considerado como uma ferramenta de migração. No entanto, ainda existem lacunas, e pode facilmente haver mal-entendidos de funcionalidade ao comparar sinalizadores AzCopy com sinalizadores RoboCopy.

Um exemplo: RoboCopy /MIR irá espelhar a origem para o destino - isso significa que os arquivos adicionados, alterados e excluídos são considerados. Uma diferença importante no uso do AzCopy -sync é que os arquivos excluídos na origem não são removidos no destino. Isso cria um conjunto de recursos de cópia diferencial incompleto. AzCopy continuará a evoluir. No momento, não recomendamos o uso do AzCopy para cenários de migração com compartilhamentos de arquivos do Azure como destino.

Objetivos de migração

O objetivo é mover os dados de locais de compartilhamento de arquivos existentes para o Azure. No Azure, você armazenará seus dados em compartilhamentos de arquivos nativos do Azure que você pode usar sem a necessidade de um Windows Server. 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 possa caber ou apenas exceder ligeiramente as janelas de manutenção regulares.

Descrição geral da migração

O processo de migração consiste em várias fases. Primeiro, você precisará implantar contas de armazenamento do Azure e compartilhamentos de arquivos. Em seguida, você configurará a rede, considerará uma implantação de Namespace DFS (DFS-N) ou atualizará a existente. Quando chegar a hora da cópia de dados real, você precisará considerar execuções repetidas e diferenciais do RoboCopy para minimizar o tempo de inatividade e, finalmente, cortar seus usuários para os compartilhamentos de arquivos do Azure recém-criados. As seções a seguir descrevem as fases do processo de migração em detalhes.

Fase 1: Implantar recursos de armazenamento do Azure

Nesta fase, você provisionará as contas de armazenamento do Azure e os compartilhamentos de arquivos do Azure SMB dentro delas.

Lembre-se de que um compartilhamento de arquivos do Azure é implantado na nuvem em uma conta de armazenamento do Azure. Para compartilhamentos de arquivos padrão, essa disposição torna a conta de armazenamento um destino de escala para números de desempenho, como IOPS e taxa de transferência. Se você colocar vários compartilhamentos de arquivos em uma única conta de armazenamento, estará criando um pool compartilhado de IOPS e taxa de transferência para esses compartilhamentos.

Como regra geral, 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. No entanto, se você tiver compartilhamentos altamente ativos (compartilhamentos usados por muitos usuários e/ou aplicativos), convém implantar contas de armazenamento com um compartilhamento de arquivos cada. Essas limitações não se aplicam a contas de armazenamento FileStorage (premium), onde o desempenho é explicitamente provisionado e garantido para cada compartilhamento.

Nota

Há um limite de 250 contas de armazenamento por assinatura por região do Azure. Com um aumento de cota, você pode criar até 500 contas de armazenamento por região. Para obter mais informações, consulte Aumentar as cotas da conta de Armazenamento do Azure.

Outra consideração ao implantar uma conta de armazenamento é a redundância. Consulte Redundância de arquivos do Azure.

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

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.

Agora, implante o número apropriado de contas de armazenamento do Azure com o número apropriado de compartilhamentos de arquivos do Azure nelas, seguindo as instruções em Criar um compartilhamento de arquivos SMB. Na maioria dos casos, convém certificar-se de que a região de cada uma das suas contas de armazenamento é a mesma.

Fase 2: Preparando-se para usar compartilhamentos de arquivos do Azure

Com as informações nesta fase, você poderá decidir como seus servidores e usuários no Azure e fora do Azure serão habilitados para utilizar seus compartilhamentos de arquivos do Azure. As decisões mais críticas são:

  • Rede: permita que suas redes roteiem o tráfego SMB.
  • Autenticação: configure as contas de armazenamento do Azure para autenticação Kerberos. Usar a autenticação baseada em identidade e ingressar no domínio em sua conta de armazenamento permitirá que seus aplicativos e usuários usem sua identidade do AD para autenticação.
  • Autorização: as ACLs de nível de compartilhamento para cada compartilhamento de arquivos do Azure permitirão que usuários e grupos do AD acessem um determinado compartilhamento e, dentro de um compartilhamento de arquivos do Azure, as ACLs NTFS nativas assumirão o controle. A autorização baseada em ACLs de arquivo e pasta funciona como para compartilhamentos SMB locais.
  • Continuidade de negócios: integrar compartilhamentos de arquivos do Azure em um ambiente existente geralmente implica preservar endereços de compartilhamento existentes. Se você ainda não estiver usando DFS-Namespaces, considere estabelecer isso em seu ambiente. Você poderá manter os endereços de compartilhamento que seus usuários e scripts usam, inalterados. O DFS-N fornece um serviço de roteamento de namespace para SMB, redirecionando clientes para compartilhamentos de arquivos do Azure.

Este vídeo é um guia e uma demonstração de como expor com segurança os compartilhamentos de arquivos do Azure diretamente para operadores de informações e aplicativos em cinco etapas simples.
O vídeo faz referência à documentação dedicada aos seguintes tópicos. Observe que o Azure Ative Directory agora é o Microsoft Entra ID. Para obter mais informações, consulte Novo nome para o Azure AD.

Montando um compartilhamento de arquivos do Azure

Antes de usar o RoboCopy, você precisa tornar o compartilhamento de arquivos do Azure acessível pelo SMB. A maneira mais fácil é montar o compartilhamento como uma unidade de rede local no Windows Server que você planeja usar para o RoboCopy.

Importante

Certifique-se de montar o compartilhamento de arquivos do Azure usando a chave de acesso da conta de armazenamento. Não use uma identidade de domínio. Antes de montar com êxito um compartilhamento de arquivos do Azure em um Windows Server local, você precisa ter concluído a Fase 2: Preparando-se para usar compartilhamentos de arquivos do Azure.

Quando estiver pronto, consulte Usar um compartilhamento de arquivos do Azure com o Windows. Em seguida, monte o compartilhamento de arquivos do Azure para o qual você deseja iniciar o RoboCopy.

Fase 3: RoboCopy

O comando RoboCopy a seguir copiará apenas as diferenças (arquivos e pastas atualizados) do armazenamento de origem para o compartilhamento 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.
/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.

Gorjeta

Confira a seção Solução de problemas se o RoboCopy estiver afetando seu ambiente de produção, relatar muitos erros ou não estiver progredindo tão rápido quanto o esperado.

Fase 4: Transferência de utilizadores

Quando você executa o comando RoboCopy pela primeira vez, seus usuários e aplicativos ainda estão acessando arquivos na origem da migração e potencialmente alterando-os. É possível que o RoboCopy tenha processado um diretório, passado para o próximo e, em seguida, um usuário no local de origem adicione, altere ou exclua um arquivo que agora não será processado nesta execução atual do RoboCopy. Este comportamento é esperado.

A primeira execução é sobre como mover a maior parte dos dados alterados para seu compartilhamento de arquivos do Azure. Esta primeira cópia pode demorar um pouco. Consulte a secção Resolução de problemas para obter mais informações sobre o que pode afetar as velocidades do RoboCopy.

Quando a execução inicial estiver concluída, execute o comando novamente.

Na segunda vez que você executar o RoboCopy para o mesmo compartilhamento, ele terminará mais rápido, porque ele só precisa transportar as alterações que aconteceram desde a última execução. Você pode executar trabalhos repetidos para o mesmo compartilhamento.

Depois de considerar a quantidade de tempo de inatividade aceitável, você precisa remover o acesso do usuário aos seus compartilhamentos de origem. Você pode fazer isso por qualquer etapa que impeça os usuários de alterar a estrutura e o conteúdo de arquivos e pastas. Um exemplo é apontar seu DFS-Namespace para um local não existente ou alterar as ACLs em cada compartilhamento.

Execute uma última rodada do RoboCopy. Ele vai pegar quaisquer mudanças que possam ter sido perdidas. O tempo que esta etapa final demora 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.

Na Fase 2, você configurou os usuários para acessar o compartilhamento com sua identidade e deve ter estabelecido uma estratégia para que os usuários usem caminhos estabelecidos para seus novos compartilhamentos de arquivos do Azure (DFS-N).

Você pode tentar executar algumas dessas cópias entre diferentes compartilhamentos de origem e destino em paralelo. Ao fazer isso, tenha em mente a taxa de transferência da rede e a relação entre a contagem de threads e o núcleo para não sobrecarregar o sistema.

Solucionar problemas e otimizar

A velocidade e a taxa de sucesso de uma determinada execução do RoboCopy dependerão de vários fatores:

  • IOPS no armazenamento de origem e de destino
  • a largura de banda de rede disponível entre a origem e o destino
  • a capacidade de processar rapidamente arquivos e pastas em um namespace
  • o número de alterações entre as execuções do RoboCopy
  • o tamanho e o número de arquivos que você precisa copiar

Considerações sobre IOPS e largura de banda

Nesta categoria, você precisa considerar as habilidades do armazenamento de origem, do armazenamento de destino e da rede que os conecta. O rendimento máximo possível é determinado pelo mais lento destes três componentes. Certifique-se de que a sua infraestrutura de rede está configurada para suportar velocidades de transferência ideais para as suas melhores capacidades.

Atenção

Embora copiar o mais rápido possível seja muitas vezes mais desejável, considere a utilização de sua rede local e dispositivo NAS para outras tarefas, muitas vezes críticas para os negócios.

Copiar o mais rápido possível pode não ser desejável quando há o risco de que a migração possa monopolizar os recursos disponíveis.

  • Considere quando é melhor em seu ambiente executar migrações: durante o dia, fora do horário de expediente ou durante os fins de semana.
  • Considere também a QoS de rede em um Windows Server para limitar a velocidade do RoboCopy.
  • Evite trabalho desnecessário para as ferramentas de migração.

O RoboCopy pode inserir atrasos entre pacotes especificando o switch onde n é medido /IPG:n em milissegundos entre os pacotes RoboCopy. O uso desse switch pode ajudar a evitar a monopolização de recursos em dispositivos restritos de E/S e links de rede lotados.

/IPG:n não pode ser usado para limitação de rede precisa para um determinado Mbps. Em vez disso, use a QoS de rede do Windows Server. O RoboCopy depende inteiramente do protocolo SMB para todas as necessidades de rede. Usar o SMB é a razão pela qual o RoboCopy não pode influenciar a taxa de transferência da rede em si, mas pode retardar seu uso.

Uma linha de pensamento semelhante se aplica às IOPS observadas no NAS. O tamanho do cluster no volume NAS, os tamanhos dos pacotes e uma série de outros fatores influenciam as IOPS observadas. A introdução do atraso entre pacotes é muitas vezes a maneira mais fácil de controlar a carga no NAS. Teste vários valores, por exemplo, de cerca de 20 milissegundos (n=20) para múltiplos desse número. Depois de introduzir um atraso, você pode avaliar se seus outros aplicativos agora podem funcionar conforme o esperado. Essa estratégia de otimização permitirá que você encontre a velocidade ideal do RoboCopy em seu ambiente.

Velocidade de processamento

O RoboCopy percorrerá o namespace para o qual foi apontado e avaliará cada arquivo e pasta para cópia. Cada ficheiro será avaliado durante uma cópia inicial e durante as cópias de recuperação. Por exemplo, execuções repetidas do RoboCopy /MIR nos mesmos locais de armazenamento de origem e destino. Essas execuções repetidas são úteis para minimizar o tempo de inatividade de usuários e aplicativos e para melhorar a taxa de sucesso geral dos arquivos migrados.

Muitas vezes, consideramos a largura de banda como o fator mais limitante em uma migração - e isso pode ser verdade. Mas a capacidade de enumerar um namespace pode influenciar o tempo total para copiar ainda mais para namespaces maiores com arquivos menores. Considere que copiar 1 TiB de arquivos pequenos levará consideravelmente mais tempo do que copiar 1 TiB de arquivos menores, mas maiores, supondo que todas as outras variáveis permaneçam as mesmas. Portanto, você pode enfrentar uma transferência lenta se estiver migrando um grande número de arquivos pequenos. Este é um comportamento esperado.

A causa para essa diferença é o poder de processamento necessário para percorrer um namespace. O RoboCopy suporta cópias multi-threaded através do /MT:n parâmetro onde n significa o número de threads a serem usados. Portanto, ao provisionar uma máquina especificamente para o RoboCopy, considere o número de núcleos do processador e sua relação com a contagem de threads que eles fornecem. O mais comum são dois threads por núcleo. A contagem de núcleos e threads de uma máquina é um ponto de dados importante para decidir quais valores /MT:n multi-thread você deve especificar. Considere também quantos trabalhos do RoboCopy você planeja executar em paralelo em uma determinada máquina.

Mais threads copiarão nosso exemplo de 1 TiB de arquivos pequenos consideravelmente mais rápido do que menos threads. Ao mesmo tempo, o investimento de recursos extras em nossos 1 TiB de arquivos maiores pode não produzir benefícios proporcionais. Uma alta contagem de threads tentará copiar mais dos arquivos grandes pela rede simultaneamente. Essa atividade de rede extra aumenta a probabilidade de ser restringida por IOPS de taxa de transferência ou armazenamento.

Durante um primeiro RoboCopy em um destino vazio ou uma execução diferencial com muitos arquivos alterados, você provavelmente será limitado pela taxa de transferência da rede. Comece com uma contagem de threads elevada na execução inicial. Uma alta contagem de threads, mesmo além dos threads atualmente disponíveis na máquina, ajuda a saturar a largura de banda de rede disponível. As execuções subsequentes /MIR são progressivamente afetadas pelo processamento de itens. Menos alterações em uma execução diferencial significam menos transporte de dados pela rede. Sua velocidade agora depende mais de sua capacidade de processar itens de namespace do que movê-los pelo link de rede. Para execuções subsequentes, faça corresponder o valor da contagem de threads à contagem de núcleos do processador e à 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.

Gorjeta

Regra geral: A primeira execução do RoboCopy (que moverá muitos dados de uma rede de latência mais alta) se beneficia do provisionamento excessivo da contagem de threads (/MT:n). As execuções subsequentes copiarão menos diferenças e é mais provável que você mude de taxa de transferência de rede restrita para computação restrita. Nessas circunstâncias, muitas vezes é melhor combinar a contagem de threads do RoboCopy com os threads realmente disponíveis na máquina. O provisionamento excessivo nesse cenário pode levar a mais mudanças de contexto no processador, possivelmente retardando sua cópia.

Evite trabalho desnecessário

Evite alterações em grande escala em seu namespace, como mover arquivos entre diretórios, alterar propriedades em grande escala ou alterar permissões de diretório e nível de arquivo (ACLs NTFS). Especialmente as alterações de ACL podem ter um alto impacto porque geralmente têm um efeito de alteração em cascata em arquivos mais baixos na hierarquia de pastas. As consequências podem ser:

  • tempo de execução estendido do trabalho RoboCopy porque cada arquivo e pasta afetados por uma alteração de ACL precisa ser atualizado
  • A reutilização de dados movidos anteriormente pode precisar ser recopiada. Por exemplo, mais dados precisarão ser copiados quando as estruturas de pastas mudarem depois que os arquivos já tiverem sido copiados anteriormente. Um trabalho do RoboCopy não pode "reproduzir" uma alteração de namespace. O próximo trabalho deve limpar os arquivos anteriormente transportados para a estrutura de pastas antiga e carregar os arquivos na nova estrutura de pastas novamente.

Outro aspeto importante é usar a ferramenta RoboCopy de forma eficaz. Com o script RoboCopy recomendado, você criará e salvará um arquivo de log para erros. Erros de cópia podem ocorrer - isso é normal. Esses erros geralmente tornam necessário executar várias rodadas de uma ferramenta de cópia como o RoboCopy: uma execução inicial, digamos, de um NAS para DataBox ou um servidor para um compartilhamento de arquivos do Azure, e uma ou mais execuções extras com o /MIR switch para capturar e repetir arquivos que não foram copiados.

Você deve estar preparado para executar várias rodadas do RoboCopy em um determinado escopo de namespace. As execuções sucessivas terminarão mais rapidamente, pois têm menos para copiar, mas são cada vez mais limitadas pela velocidade de processamento do namespace. Quando você executa várias rodadas, você pode acelerar cada rodada não fazendo com que o RoboCopy tente copiar tudo em uma determinada execução. Estes comutadores RoboCopy podem fazer uma diferença significativa:

  • /R:n n = a frequência com que tenta copiar novamente um ficheiro com falha e
  • /W:n n = quantos segundos esperar entre novas tentativas

/R:5 /W:5 é uma configuração razoável que você pode ajustar ao seu gosto. Neste exemplo, um arquivo com falha será repetido cinco vezes, com tempo de espera de cinco segundos entre as tentativas. Se o arquivo ainda não conseguir copiar, o próximo trabalho do RoboCopy tentará novamente. Muitas vezes, os ficheiros que falharam porque estão a ser utilizados ou devido a problemas de tempo limite podem eventualmente ser copiados com êxito desta forma.

Estimativa de encargos de transação de armazenamento

À medida que inicia a migração para os Arquivos do Azure, o RoboCopy copia seus arquivos e pastas para o Azure. Dependendo do seu modelo de faturação para os Ficheiros do Azure, poderão aplicar-se taxas de transação. Consulte Noções básicas sobre faturamento.

Se você estiver usando um modelo de cobrança pré-pago para compartilhamentos de arquivos padrão do Azure, pode ser difícil estimar o número de transações que sua migração gerará.

  • Não é possível estimar o número de transações com base na capacidade de armazenamento utilizada da fonte. O número de transações é dimensionado com o número de itens de namespace (arquivos e pasta) e suas propriedades que são migradas, não com seu tamanho. Por exemplo, são necessárias mais transações para migrar 1 GiB de arquivos pequenos do que 1 GiB de arquivos maiores.
  • Para minimizar o tempo de inatividade, talvez seja necessário executar operações de cópia várias vezes da origem ao destino. Todos os itens de origem e destino são processados durante cada operação de cópia, embora as execuções subsequentes terminem mais rapidamente. Após as operações iniciais, apenas as diferenças introduzidas entre as execuções de cópia são transportadas pela rede. É importante entender que, embora menos dados estejam sendo transportados, o número de transações necessárias pode permanecer o mesmo.
  • Copiar o mesmo arquivo duas vezes pode não resultar no mesmo número de transações. O processamento de um item migrado em uma execução de cópia anterior pode resultar em apenas algumas transações de leitura. Por outro lado, as alterações nos metadados ou no conteúdo entre as execuções de cópia podem exigir um número maior de transações para atualizar o destino. Cada arquivo em seu namespace pode ter requisitos exclusivos, resultando em um número diferente de transações.

É aconselhável executar alguns testes iniciais em seus próprios dados para entender melhor quantas transações são incorridas. Isso lhe dará uma ideia melhor do número total de transações que uma migração de arquivo pode gerar.

Próximos passos

Os artigos a seguir ajudarão você a entender as opções avançadas e as práticas recomendadas.