Migração do StorSimple 8100 e 8600 para a Sincronização de Arquivos do Azure

O StorSimple série 8000 inclui os dispositivos locais e físicos 8100 ou 8600 e seus componentes de serviço de nuvem. As soluções de virtualização StorSimple 8010 e 8020 também são abordadas neste guia de migração. É possível migrar os dados de qualquer uma dessas soluções para compartilhamentos de arquivos do Azure com Sincronização de Arquivos do Azure opcionais. A Sincronização de Arquivos do Azure é o serviço do Azure de longo prazo padrão e estratégico que substitui a funcionalidade local do StorSimple. Este artigo fornece o conhecimento em segundo plano necessário e as etapas de migração para uma migração bem-sucedida para a Sincronização de Arquivos do Azure.

Observação

O serviço StorSimple chegou ao fim do suporte (incluindo o Gerenciador de Dispositivos do StorSimple para as séries 8000 e 1200 e o Gerenciador de Dados do StorSimple). O fim do suporte do StorSimple foi publicado em 2019 nas páginas Política de ciclo de vida da Microsoft e Comunicações do Azure. Notificações adicionais foram enviadas por email e postadas no portal do Azure e na visão geral do StorSimple. Entre em contato com o Suporte da Microsoft para obter mais detalhes.

Este vídeo fornece uma visão geral do seguinte:

• Arquivos do Azure
• Sincronização de Arquivos do Azure
• Comparação entre o StorSimple e os Arquivos do Azure
• Visão geral da ferramenta e do processo de migração do Gerenciador de Dados do StorSimple

Fase 1: preparar para a migração

Esta seção contém as etapas que você deve seguir no início da migração de volumes do StorSimple para compartilhamentos de arquivos do Azure.

Este vídeo aborda o seguinte:

• Seleção da camada de armazenamento
• Seleção das opções de redundância de armazenamento
• Seleção do acesso de compartilhamento direto ou da Sincronização de Arquivos do Azure
• Número de série e chave de criptografia de dados de serviço do StorSimple
• Migração de backups de volume do StorSimple
• Mapeamento de compartilhamentos e volumes do StorSimple para compartilhamentos de arquivos do Azure
• Agrupamento de compartilhamentos em compartilhamentos de arquivos do Azure
• Considerações sobre o mapeamento
• Planilha de planejamento de migração
• Planilha de mapeamento de namespace

Inventário

Ao começar a planejar a migração, primeiro identifique todos os dispositivos e volumes do StorSimple que você precisa migrar. Posteriormente, você pode decidir sobre o melhor caminho de migração.

• Os dispositivos físicos do StorSimple (série 8000) usam este guia de migração.
• Os dispositivos virtuais StorSimple (série 1200) usam um guia de migração diferente.

Resumo do custo de migração

As migrações para compartilhamentos de arquivos do Azure de volumes do StorSimple por meio de trabalhos de migração em um recurso de Gerenciador de Dados do StorSimple são gratuitas. Outros custos podem ser incorridos durante e após uma migração:

• Saída de rede: os arquivos do StorSimple residem em uma conta de armazenamento dentro de uma região específica do Azure. Se você provisionar os compartilhamentos de arquivos do Azure que migra para uma conta de armazenamento localizada na mesma região do Azure, não ocorrerá nenhum custo de saída. No entanto, se você mover seus arquivos para uma conta de armazenamento em uma região diferente como parte dessa migração, serão aplicados custos de saída.
• Transações de compartilhamento de arquivos do Azure: quando os arquivos são copiados para um compartilhamento de arquivos do Azure (como parte de uma migração ou fora de uma), os custos de transações se aplicam à medida que os arquivos e os metadados estão sendo gravados. Como prática recomendada, inicie o compartilhamento de arquivos do Azure na camada de transação otimizada durante a migração. Alterne para a camada desejada após a conclusão da migração. As fases descritas neste artigo destacam isso no ponto apropriado.
• Alterar uma camada de compartilhamento de arquivos do Azure: alterar a camada de um compartilhamento de arquivos do Azure custa transações. Na maioria dos casos, será mais econômico seguir o conselho do ponto anterior.
• Custo de armazenamento: quando essa migração começa a copiar arquivos em um compartilhamento de arquivo do Azure, o armazenamento é consumido e cobrado. Os backups migrados se tornarão instantâneos de compartilhamento de arquivos do Azure. Os instantâneos de compartilhamento de arquivos consomem apenas a capacidade de armazenamento para as diferenças que eles contêm.
• StorSimple: até que você desprovisione os dispositivos e as contas de armazenamento do StorSimple, continuará a ocorrer o custo do StorSimple para armazenamento, backups e dispositivos.

Acesso direto ao compartilhamento contra a Sincronização de Arquivos do Azure

Os compartilhamentos de arquivos do Azure abrem um novo mundo de oportunidades para estruturar sua implantação de serviços de arquivos. Um compartilhamento de arquivo do Azure é um compartilhamento SMB na nuvem que você pode configurar para que os usuários acessem diretamente o protocolo SMB com a autenticação Kerberos familiar e as permissões NTFS existentes (ACLs de arquivo e pasta) funcionando nativamente. Saiba mais sobre o acesso baseado em identidade aos compartilhamentos de arquivos do Azure.

Uma alternativa ao acesso direto é a sincronização de arquivos do Azure. A Sincronização de Arquivos do Azure é uma analogia direta para a capacidade do StorSimple de armazenar em cache arquivos usados com frequência no local.

A Sincronização de Arquivos do Azure é um serviço de nuvem da Microsoft, com base em dois componentes principais:

• A Sincronização de arquivos e camadas de nuvem para criar um cache de acesso de desempenho em qualquer servidor Windows.
• Os compartilhamentos de arquivos como armazenamento nativo no Azure que podem ser acessados por meio de vários protocolos, como o SMB e REST de arquivo.

Os compartilhamentos de arquivos do Azure mantêm aspectos importantes de fidelidade de arquivo, como atributos, permissões e carimbos de data/hora. Com compartilhamentos de arquivos do Azure, não há mais necessidade de um aplicativo ou serviço para interpretar os arquivos e as pastas armazenados na nuvem. Você pode acessá-los nativamente por meio de protocolos e clientes familiares. Os compartilhamentos de arquivos do Azure permitem armazenar dados do servidor de arquivos de uso geral e dados de aplicativo na nuvem.

Este artigo se concentra nas etapas de migração. Se você quiser saber mais sobre a Sincronização de Arquivos do Azure antes de migrar, consulte os seguintes artigos:

• Guia de planejamento da Sincronização de Arquivos do Azure
• Guia de implantação da Sincronização de Arquivos do Azure

Chave de criptografia de dados do serviço StorSimple

Quando você configurou o dispositivo StorSimple pela primeira vez, ele gerou uma chave de criptografia de dados de serviço e instruiu você a armazenar a chave com segurança. Essa chave é usada para criptografar todos os dados na conta de armazenamento do Azure associada na qual o dispositivo StorSimple armazena seus arquivos.

A chave de criptografia de dados de serviço é necessária para uma migração bem-sucedida. Recupere essa chave de seus registros, uma para cada um dos dispositivos no seu estoque.

Se você não encontrar as chaves em seus registros, poderá gerar uma nova chave a partir do dispositivo. Cada dispositivo tem uma chave de criptografia exclusiva.

Alterar a chave de criptografia de dados do serviço

As chaves de criptografia de dados de serviço são usadas para criptografar dados confidenciais, como credenciais de conta de armazenamento, que são enviadas de seu serviço StorSimple Manager ao dispositivo StorSimple. Você precisará alterar essas chaves periodicamente se sua organização de TI tiver uma política de rotação de chave nos dispositivos de armazenamento. O processo de alteração de chave pode ser ligeiramente diferente dependendo se há um só ou vários dispositivos gerenciados pelo serviço StorSimple Manager. Para obter mais informações, acesse Segurança e proteção de dados do StorSimple.

A alteração da chave de criptografia de dados de serviço é um processo de três etapas:

1. Usando scripts do Windows PowerShell para o Azure Resource Manager, autorize um dispositivo a alterar a chave de criptografia de dados de serviço.
2. Usar o Windows PowerShell para StorSimple para iniciar a alteração da chave de criptografia de dados de serviço.
3. Se você tiver mais de um dispositivo StorSimple, atualize a chave de criptografia de dados de serviço nos outros dispositivos.

Etapa 1: use um script do Windows PowerShell para autorizar um dispositivo a alterar a chave de criptografia de dados de serviço

Normalmente, o administrador do dispositivo solicita que o administrador do serviço autorize um dispositivo a alterar as chaves de criptografia de dados de serviço. O administrador do serviço então autoriza o dispositivo a alterar a chave.

Esta etapa é executada usando o script baseado no Azure Resource Manager. O administrador de serviços pode selecionar um dispositivo qualificado para receber a autorização. O dispositivo é então autorizado a iniciar o processo de alteração da chave de criptografia de dados de serviço.

Para obter mais informações sobre como usar o script, acesse Authorize-ServiceEncryptionRollover.ps1

Quais dispositivos podem ser autorizados a alterar as chaves de criptografia de dados de serviço?

Um dispositivo deve atender aos seguintes critérios para que possa ser autorizado a iniciar as alterações da chave de criptografia de dados de serviço:

• O dispositivo deve estar online para ser qualificado para autorização da alteração da chave de criptografia de dados de serviço.
• Você pode autorizar o mesmo dispositivo novamente após 30 minutos, caso a alteração de chave não tenha sido iniciada.
• Você pode autorizar um dispositivo diferente, desde que a alteração de chave não tenha sido iniciada pelo dispositivo autorizado anteriormente. Depois que o novo dispositivo tiver sido autorizado, o dispositivo antigo não poderá iniciar a alteração.
• Não é possível autorizar um dispositivo enquanto a substituição da chave de criptografia de dados de serviço estiver em andamento.
• Você pode autorizar um dispositivo quando alguns dos dispositivos registrados no serviço tiverem substituído a criptografia, enquanto outros não.

Etapa 2: Usar o Windows PowerShell para StorSimple para iniciar a alteração da chave de criptografia de dados de serviço

Essa etapa é executada na interface do Windows PowerShell para StorSimple no dispositivo StorSimple autorizado.

Observação

Nenhuma operação poderá ser executada no Portal do Azure do serviço do StorSimple Manager até que a substituição de chave esteja concluída.

Se você estiver usando o console serial do dispositivo para se conectar à interface do Windows PowerShell, execute as etapas a seguir.

Para iniciar a alteração da chave de criptografia de dados de serviço

1. Selecione a Opção 1 para fazer logon com acesso completo.

2. No prompt de comando, digite:

   Invoke-HcsmServiceDataEncryptionKeyChange

3. Depois que o cmdlet tiver sido concluído com êxito, você receberá uma nova chave de criptografia de dados de serviço. Copie e salve essa chave para uso na etapa 3 deste processo. Essa chave será usada para atualizar todos os dispositivos restantes registrados no serviço StorSimple Manager.

   Observação

   Esse processo deve ser iniciado em quatro horas, a contar da autorização de um dispositivo StorSimple.

   Essa nova chave é então enviada ao serviço para ser enviada por push a todos os dispositivos que são registrados no serviço. Um alerta aparecerá no painel de serviço. O serviço desabilitará todas as operações nos dispositivos registrados e o administrador do dispositivo precisará atualizar a chave de criptografia de dados de serviço nos outros dispositivos. No entanto, as E/Ss (hosts que enviam dados à nuvem) não serão interrompidas.

   Se você tiver um único dispositivo registrado no serviço, o processo de substituição agora está concluído e a próxima etapa poderá ser ignorada. Se você tiver vários dispositivos registrados em seu serviço, passe para a etapa 3.

Etapa 3: Atualizar a chave de criptografia de dados de serviço em outros dispositivos StorSimple

Essas etapas devem ser executadas na interface do Windows PowerShell de seu dispositivo StorSimple, caso você tenha vários dispositivos registrados no serviço StorSimple Manager. A chave que você obteve na Etapa 2 deve ser usada para atualizar todos os demais dispositivos StorSimple registrados com o serviço do StorSimple Manager.

Execute as etapas a seguir para atualizar a criptografia de dados de serviço no seu dispositivo.

Para atualizar a chave de criptografia de dados de serviço em dispositivos físicos

1. Use o Windows PowerShell para StorSimple para se conectar ao console. Selecione a Opção 1 para fazer logon com acesso completo.
2. No prompt de comando, digite: Invoke-HcsmServiceDataEncryptionKeyChange – ServiceDataEncryptionKey
3. Forneça a chave de criptografia de dados de serviço que você obteve na Etapa 2: Usar o Windows PowerShell para StorSimple para iniciar a alteração da chave de criptografia de dados de serviço.

Para atualizar a chave de criptografia de dados de serviço em todos os dispositivos de nuvem 8010/8020

1. Baixe e instale o script do PowerShell Update-CloudApplianceServiceEncryptionKey.ps1.
2. Abra o PowerShell e, no prompt de comando, digite: Update-CloudApplianceServiceEncryptionKey.ps1 -SubscriptionId [subscription] -TenantId [tenantid] -ResourceGroupName [resource group] -ManagerName [device manager]

Esse script garantirá que essa chave de criptografia de dados de serviço seja definida em todos os dispositivos de nuvem 8010/8020 no gerenciador de dispositivos.

Cuidado

Quando estiver decidindo a forma de se conectar ao aplicativo do StorSimple, considere o seguinte:

• A conexão por meio de uma sessão HTTPS é a opção mais segura e recomendada.
• Conectar-se diretamente ao console serial do dispositivo é seguro, mas conectar-se ao console serial em comutadores de rede não é.
• As conexões de sessão HTTP são uma opção, mas não são criptografadas. Elas não são recomendadas a menos que sejam usadas em uma rede de confiança fechada.

Limitações conhecidas

O Gerenciador de Dados do StorSimple e os compartilhamentos de arquivos do Azure têm algumas limitações que você deve considerar antes de começar, pois eles podem impedir uma migração:

• Há suporte apenas para volumes NTFS da sua solução StorSimple. Não há suporte para volumes ReFS.
• Não há suporte para volumes colocados em Discos Dinâmicos do Windows Server.
• O serviço não funciona com volumes criptografados pelo BitLocker ou que têm a Eliminação de Duplicação de Dados habilitada.
• Os backups do StorSimple corrompidos não podem ser migrados.
• Opções de sistema de rede especiais, como firewalls ou comunicação somente de ponto de extremidade privado, não podem ser habilitadas na conta de armazenamento de origem em que os backups do StorSimple são armazenados, nem na conta de armazenamento de destino que mantém seus compartilhamentos de arquivos do Azure.

Fidelidade do arquivo

Se nenhuma das limitações em Limitações conhecidas impedir uma migração, ainda haverá limitações sobre o que pode ser armazenado em compartilhamentos de arquivos do Azure.

A fidelidade do arquivo refere-se à infinidade de atributos, carimbos de data e hora e dados que compõem um arquivo. Em uma migração, a fidelidade do arquivo é uma medida do nível da qualidade da tradução (migração) das informações na origem (volume do StorSimple) para o compartilhamento de arquivo do Azure.

Os Arquivos do Azure dão suporte a um subconjunto das Propriedades do arquivo NTFS. As ACLs, os metadados comuns e alguns carimbos de data/hora do Windows serão migrados.

Os itens a seguir não impedirão uma migração, mas causarão problemas por item durante uma migração:

• Carimbos de data/hora: o horário de alteração do arquivo não será definido. Atualmente, ele é somente leitura sobre o protocolo REST. O carimbo de data/hora do último acesso em um arquivo não será movido, pois, no momento, isso não é um atributo com suporte em arquivos armazenados em um compartilhamento de arquivo do Azure.
• Os Fluxos de dados alternativos não podem ser armazenados em compartilhamentos de arquivos do Azure. Arquivos que contêm Fluxos de dados alternativos são copiados, mas os Fluxos de dados alternativos são removidos do arquivo no processo.
• Links simbólicos, links físicos, junções e pontos de nova análise são ignorados durante uma migração. Os logs de cópia de migração listam cada item ignorado e um motivo.
• Os arquivos criptografados EFS não são copiados. Os logs de cópia mostram que o item não pôde ser copiado com "Acesso negado".
• Arquivos corrompidos são ignorados. Os logs de cópia podem listar erros diferentes nos itens corrompidos no disco do StorSimple: "A solicitação falhou devido a um erro fatal de hardware do dispositivo" ou "O arquivo ou diretório está corrompido ou ilegível" ou "A estrutura da ACL (lista de controle de acesso) é inválida".
• Arquivos individuais com mais de 4 TiB são ignorados.
• Os comprimentos do caminho do arquivo devem ser iguais ou menores do que 2048 caracteres. Arquivos e pastas com caminhos mais longos serão ignorados.
• Pontos de nova análise são ignorados. Quaisquer pontos de nova análise da Eliminação de Duplicação de Dados da Microsoft/SIS ou de terceiros não podem ser resolvidos pelo mecanismo de migração e impedirão a migração dos arquivos e pastas afetados.

A seção de solução de problemas no final deste artigo tem mais detalhes sobre códigos de erro no nível do trabalho de migração e, sempre que possível, de suas opções de mitigação.

Backups de volume do StorSimple

O StorSimple oferece backups diferenciais no nível de volume. Os compartilhamentos de arquivos do Azure também têm essa capacidade, chamada de instantâneos de compartilhamento.

Seus trabalhos de migração só podem mover backups, nunca dados do volume ativo. Portanto, o backup mais recente está mais próximo dos dados dinâmicos e, portanto, sempre deve fazer parte da lista de backups a serem movidos em uma migração.

Decida se você precisa mover qualquer backup mais antigo durante a migração. A melhor prática é manter essa lista o menor possível, para que seus trabalhos de migração sejam concluídos mais rapidamente.

Para identificar os backups críticos que devem ser migrados, faça uma lista de verificação das políticas de backup. Por exemplo:

• O backup mais recente.
• Um backup por mês por 12 meses.
• Um backup de um ano por três anos.

Ao criar seus trabalhos de migração, você poderá usar essa lista para identificar os backups de volume do StorSimple exatos que devem ser migrados para atender aos seus requisitos.

É melhor suspender todas as políticas de retenção de backup do StorSimple antes de selecionar um backup para migração. A migração dos seus backups pode levar vários dias ou semanas. O StorSimple oferece políticas de retenção de backup que excluem backups antigos. Os backups selecionados para essa migração podem ser excluídos antes de terem a oportunidade de serem migrados.

Cuidado

Não há suporte para a seleção de mais de 50 backups de volume do StorSimple.

Mapear os volumes do StorSimple existentes para compartilhamentos de arquivos do Azure

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

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.

Baixe um modelo de mapeamento de namespace.

Número de contas de armazenamento

Sua migração provavelmente se beneficiará de uma implantação de várias contas de armazenamento, cada uma mantendo um número menor de compartilhamentos de arquivos do Azure.

Se os compartilhamentos de arquivos estiverem altamente ativos (utilizados por muitos usuários ou aplicativos), dois compartilhamentos de arquivos do Azure poderão alcançar o limite de desempenho da sua conta de armazenamento. Por isso, geralmente é melhor prática migrar para várias contas de armazenamento, cada uma com seus próprios compartilhamentos de arquivos individuais e, normalmente, não mais do que dois ou três compartilhamentos por 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 neles.

Essas considerações se aplicam mais ao acesso direto à nuvem (por meio de uma VM ou serviço do Azure) do que a Sincronização de Arquivos do Azure. Se você planeja usar exclusivamente a Sincronização de Arquivos do Azure nesses compartilhamentos, não tem problema agrupar vários em uma única conta de armazenamento do Azure. No futuro, talvez seu desejo seja usar o "lift and shift" em um aplicativo para a nuvem que acessaria diretamente um compartilhamento de arquivo, pois esse cenário se beneficiaria ao ter IOPS e taxa de transferência maiores. Ou você poderia começar a usar um serviço no Azure que também se beneficiaria ao ter IOPS e taxa de transferência maiores.

Após fazer uma lista de seus compartilhamentos, mapeie cada compartilhamento para a conta de armazenamento na qual ele residirá. Decida qual região do Azure usar e verifique se cada conta de armazenamento e recurso da Sincronização de Arquivos do Azure corresponde à região selecionada.

Importante

Não defina as configurações de rede e firewall para as contas de armazenamento agora. Fazer essas configurações neste ponto tornaria uma migração impossível. Defina essas configurações de armazenamento do Azure após a conclusão da migração.

Configurações da conta de armazenamento

Há muitas configurações que você pode fazer em uma conta de armazenamento. Use a lista de verificação a seguir para confirmar as configurações da conta de armazenamento. Você pode alterar a configuração do sistema de rede após a conclusão da migração.

• Compartilhamentos de arquivos grandes: habilitado – os compartilhamentos de arquivos grandes melhoram o desempenho e permitem armazenar até 100 TiB em um compartilhamento. Essa configuração se aplica às contas de armazenamento de destino com compartilhamentos de arquivos do Azure.
• Firewall e redes virtuais: desabilitado – não configure nenhuma restrição de IP ou limite o acesso à conta de armazenamento a uma rede virtual específica. O ponto de extremidade público da conta de armazenamento é usado durante a migração. Todos os endereços IP de VMs do Azure devem ser permitidos. É melhor configurar as regras de firewall na conta de armazenamento após a migração. Configure suas contas de armazenamento de origem e de destino dessa maneira.
• Pontos de extremidade privados: com suporte – você pode habilitar pontos de extremidade privados, mas o ponto de extremidade público é usado na migração e deve permanecer disponível. Isso se aplica às contas de armazenamento de origem e de destino.

Resumo da fase 1

No final da fase 1:

• Você tem uma boa visão geral de seus dispositivos e volumes do StorSimple.
• O serviço de Gerenciador de Dados está pronto para acessar os volumes do StorSimple na nuvem porque você recuperou sua chave de criptografia de dados de serviço para cada dispositivo StorSimple.
• Você tem um plano para o qual os volumes e backups (se houver mais recentes) precisam ser migrados.
• Você sabe como mapear seus volumes para o número apropriado de compartilhamentos de arquivos do Azure e contas de armazenamento.

Fase 2: implantar recursos de migração e armazenamento do Azure

Esta seção discute considerações sobre a implantação de diferentes tipos de recursos que são necessários no Azure. Alguns manterão seus dados após a migração e alguns são necessários apenas para a migração. Não inicie a implantação de recursos até que você tenha finalizado seu plano de implantação. É difícil, às vezes impossível, alterar determinados aspectos dos recursos do Azure depois que eles são implantados.

Este vídeo aborda a implantação do seguinte:

• Contas de armazenamento
• Assinaturas e grupos de recursos
• Contas de armazenamento
• Tipos e nomes
• Desempenho e tamanho do compartilhamento
• Tipos de replicação e localização
• Compartilhamentos de arquivos do Azure
• Serviço do Gerenciador de Dados do StorSimple

Implantar contas de armazenamento

Provavelmente, você precisará implantar várias contas de armazenamento do Azure. Cada uma delas manterá um número menor de compartilhamentos de arquivos do Azure, de acordo com seu plano de implantação. Vá para o portal do Azure para implantar suas contas de armazenamento planejadas. Considere obedecer às configurações básicas a seguir para novas contas de armazenamento.

Importante

Não defina as configurações de rede e firewall para suas contas de armazenamento agora. Fazer essas configurações neste momento tornaria uma migração impossível. Defina essas configurações de armazenamento do Azure após a conclusão da migração.

Assinatura

Você pode usar a mesma assinatura utilizada para sua implantação do StorSimple ou uma diferente. A única limitação é que sua assinatura deve estar no mesmo locatário do Microsoft Entra que a assinatura do StorSimple. Considere mover a assinatura do StorSimple para o locatário apropriado antes de iniciar uma migração. Você só pode mover a assinatura inteira, pois recursos individuais do StorSimple não podem ser movidos para um locatário ou assinatura diferente.

Grupo de recursos

Os grupos de recursos no Azure ajudam com a organização de recursos e permissões de gerenciamento de administração. Saiba mais.

Nome da conta de armazenamento

O nome da sua conta de armazenamento se tornará parte de uma URL usada para acessar o compartilhamento de arquivo e terá determinadas limitações de caracteres. Na convenção de nomenclatura, considere que os nomes de conta de armazenamento devem ser exclusivos no mundo, permitir apenas letras minúsculas e números, exigir entre 3 e 24 caracteres e não permitir caracteres especiais como hifens ou sublinhados. Consulte Regras de nomenclatura de recursos de armazenamento do Azure.

Localidade

A região do Azure de uma conta de armazenamento é importante. Se você usar a Sincronização de Arquivos do Azure, todas as suas contas de armazenamento deverão estar na mesma região que o recurso do Serviço de Sincronização de Armazenamento. A região do Azure que você escolher deve ser próxima ou central para seus servidores e usuários locais. Depois que o recurso tiver sido implantado, você não poderá alterar sua região.

Você pode escolher uma região diferente de onde os dados do StorSimple (conta de armazenamento) residem no momento. No entanto, se você fizer isso, encargos de saída serão aplicados durante a migração. Os dados deixarão a região do StorSimple e entrarão em sua nova região de conta de armazenamento. Nenhum encargo de largura de banda se aplica se você permanecer dentro da mesma região do Azure.

Desempenho

Você tem a opção de escolher o armazenamento Premium (SSD) para compartilhamentos de arquivos do Azure ou o armazenamento Standard. O armazenamento Standard inclui várias camadas para um compartilhamento de arquivos. O armazenamento Standard é a opção certa para a maioria dos clientes que estão migrando do StorSimple.

• Escolha o armazenamento Premium se você precisar do desempenho de um compartilhamento de arquivos premium do Azure.
• Escolha o armazenamento padrão para cargas de trabalho de servidor de arquivos de uso geral, que inclui dados de acesso frequente e dados de arquivo. Escolha também o armazenamento padrão se a única carga de trabalho no compartilhamento na nuvem for a Sincronização de Arquivos do Azure.
• Para compartilhamentos de arquivos premium, escolha Compartilhamentos de arquivos no assistente para criar conta de armazenamento.

Replicação

Há várias configurações de replicação disponíveis. Escolha uma das duas opções a seguir:

• LRS (armazenamento com redundância local) .
• ZRS (armazenamento com redundância de zona) , que não está disponível em todas as regiões do Azure.

Observação

Não há suporte para GRS (armazenamento com redundância geográfica) e armazenamento com redundância de zona geográfica.

Habilitar compartilhamentos de arquivos com capacidade de 100 TiB

Na seção Avançado do assistente de nova conta de armazenamento na portal do Azure, você pode habilitar o suporte a compartilhamentos de arquivos grandes nesta conta de armazenamento. Se essa opção não estiver disponível, provavelmente você selecionou o tipo de redundância incorreto. Certifique-se de selecionar somente LRS ou ZRS para que essa opção fique disponível.

O uso de compartilhamentos de arquivo grandes tem vários benefícios:

• O desempenho é aumentado em comparação com os compartilhamentos de arquivos menores de 5 TiB (por exemplo, dez vezes a IOPS).
• Sua migração será concluída com mais rapidez.
• Você garante que um compartilhamento de arquivo tem capacidade suficiente para manter todos os dados que serão migrados para ele, incluindo a capacidade de armazenamento que os backups diferenciais exigem.
• O crescimento futuro é abordado.

Importante

Não aplique um sistema de rede especial à conta de armazenamento antes ou durante a migração. O ponto de extremidade público deve estar acessível nas contas de armazenamento de origem e de destino. Não há suporte para a limitação de intervalos de IP ou redes virtuais específicos. Você pode alterar as configurações de rede da conta de armazenamento após a migração.

Compartilhamentos de arquivos do Azure

Depois que as contas de armazenamento forem criadas, vá para a seção Compartilhamento de arquivo das contas de armazenamento e implante o número apropriado de compartilhamentos de arquivos do Azure de acordo com seu plano de migração da Fase 1. Considere cumprir as seguintes configurações básicas para seus novos compartilhamentos de arquivos no Azure.

Há suporte para letras minúsculas, números e hifens.



A cota aqui é comparável a uma cota fixa do SMB em uma instância do Windows Server. A melhor prática é não definir uma cota aqui porque a migração e outros serviços falharão quando a cota for atingida.



Selecione
para seu novo compartilhamento de arquivo. Durante a migração, muitas transações ocorrerão. Seu mais econômico é alterar sua camada posteriormente para a camada mais adequada para sua carga de trabalho.

StorSimple Data Manager

O recurso do Azure que armazena seus trabalhos de migração é chamado de Gerenciador de Dados do StorSimple. Selecione Novo recursoe pesquise por ele. Em seguida, selecione Criar.

Esse recurso temporário é usado para orquestração. Você o desprovisiona após a conclusão da migração. Certifique-se de implantá-lo na mesma assinatura, grupo de recursos e região que sua conta de armazenamento do StorSimple.

Sincronização de Arquivos do Azure

Com a Sincronização de Arquivos do Azure, você pode adicionar o cache local dos arquivos acessados com mais frequência. Semelhante aos recursos de cache do StorSimple, o recurso de camadas de nuvem da Sincronização de Arquivos do Azure oferece latência de acesso local combinado ao controle aprimorado sobre a capacidade de cache disponível na instância do Windows Server e na sincronização de vários sites. Se ter um cache local for seu objetivo, em sua rede local, prepare uma VM do Windows Server (também há suporte para servidores físicos e clusters de failover) com capacidade de armazenamento suficiente de conexão direta.

Importante

Não configure ainda a Sincronização de Arquivos do Azure. A implantação da Sincronização de Arquivos do Azure não deve iniciar antes da Fase 4 de uma migração.

Resumo da fase 2

No final da fase 2, você implantará suas contas de armazenamento e todos os compartilhamentos de arquivos do Azure entre elas. Você também terá um recurso de Gerenciador de Dados do StorSimple. Você usará este último na fase 3, quando configurar seus trabalhos de migração.

Fase 3: criar e executar um trabalho de migração

Esta seção descreve como configurar um trabalho de migração e mapear os diretórios em um volume do StorSimple que devem ser copiados para o compartilhamento de arquivo de destino do Azure selecionado.

Este vídeo aborda o seguinte:

• Criar um trabalho de migração
• Resumo
• Fonte
• Selecionando backups de volume para migrar
• Destino
• Mapeamento de diretórios
• Regras semânticas
• Executar um trabalho de migração
• Executar uma definição de trabalho
• Exibir o estado do trabalho
• Executar trabalhos em paralelo
• Interpretar os arquivos de log

Para começar, vá para o Gerenciador de Dados do StorSimple, localize Definições de trabalho no menu e selecione + Definição de trabalho. O tipo de armazenamento de destino correto é o padrão: Compartilhamento de arquivos do Azure.

Nome da definição de trabalho
Esse nome deve indicar o conjunto de arquivos que está sendo migrado. Dar um nome semelhante ao compartilhamento de arquivos do Azure é uma boa prática.



Ao selecionar uma região, você precisará selecionar a mesma região da sua conta de armazenamento do StorSimple ou uma região próxima a ela, se isso não estiver disponível.

Fonte

Assinatura de origem
Selecione a assinatura na qual você armazena o recurso do Gerenciador de Dispositivos StorSimple.



Selecione o Gerenciador de Dispositivos StorSimple no qual seu dispositivo está registrado.



Marque esta
caso não consiga localizar a chave nos seus registros.



Selecione o dispositivo StorSimple que contém o volume para o local em que deseja migrá-lo.



Selecione o volume de origem. Posteriormente, você decidirá se deseja migrar todo o volume ou subdiretórios para o compartilhamento de arquivos de destino do Azure.

Backups de volumes
Você pode clicar em Selecionar backups de volume para escolher backups específicos a serem movidos como parte desse trabalho. Uma próxima seção dedicada neste artigo abordará o processo em detalhes.

Destino

Selecione a assinatura, a conta de armazenamento e o compartilhamento de arquivo do Azure como o destino deste trabalho de migração.

Mapeamento de diretórios

Uma seção dedicada neste artigoaborda todos os detalhes relevantes.

Selecionando backups de volume para migrar

Há aspectos importantes em relação à escolha de backups que precisam ser migrados:

• Seus trabalhos de migração só podem mover backups, não dados do volume ativo. Portanto, o backup mais recente está mais próximo dos dados dinâmicos e deve estar sempre na lista de backups movidos em uma migração. Quando abrir a caixa de diálogo Seleção de backup, ela será selecionada por padrão.
• Verifique se o último backup é o mais recente para manter o Delta para o compartilhamento dinâmico o menor possível. Pode valer a pena disparar e concluir outro backup de volume antes de criar um trabalho de migração. Um delta pequeno para o compartilhamento dinâmico melhora sua experiência de migração. Se esse delta pode ser zero, significa que nenhuma alteração no volume do StorSimple ocorreu depois que o backup mais recente foi feito na lista, portanto, a migração de usuário será drasticamente simplificada e acelerada.
• Os backups devem ser reproduzidos no compartilhamento de arquivos do Azure do mais antigo para o mais recente. Um backup mais antigo não pode ser "classificado" na lista de backups no compartilhamento de arquivo do Azure após a execução de um trabalho de migração. Portanto, você deve garantir que a lista de backups seja concluída antes de criar um trabalho.
• Essa lista de backups em um trabalho não pode ser modificada depois que o trabalho é criado, mesmo que o trabalho nunca seja executado.
• Para selecionar backups, o volume do StorSimple que você deseja migrar precisará estar online.

Para selecionar backups do seu volume StorSimple para seu trabalho de migração, selecione o selecionar backups de volume no formulário de criação de trabalho.

Quando o painel de seleção de backup é aberto, ele é separado em duas listas. Na primeira lista, todos os backups disponíveis são exibidos. Você pode expandir e restringir o conjunto de resultados filtrando um intervalo de tempo específico. (confira a próxima seção)

Um backup selecionado será exibido como esmaecido e será adicionado a uma segunda lista na metade inferior do painel. A segunda lista exibe todos os backups selecionados para migração. Um backup selecionado em erro também pode ser removido novamente.

Cuidado

Você deve selecionar todos os backups que deseja migrar. Não é possível adicionar backups mais antigos depois. Não é possível modificar o trabalho para alterar a seleção depois que o trabalho é criado.

Por padrão, a lista é filtrada para mostrar os backups de volume do StorSimple nos últimos sete dias. O backup mais recente é selecionado por padrão, mesmo que ele não tenha ocorrido nos últimos sete dias. Para backups mais antigos, use o filtro de intervalo de tempo na parte superior da folha. Você pode selecionar um filtro existente ou definir um intervalo de tempo personalizado para filtrar apenas os backups feitos durante esse período.

Cuidado

Não há suporte para a seleção de mais de 50 backups de volume do StorSimple. Trabalhos com um grande número de backups podem falhar. Verifique se as suas políticas de retenção de backup não podem excluir um backup selecionado antes que ele seja migrado.

Mapeamento de diretórios

O mapeamento de diretório é opcional para seu trabalho de migração. Se você deixar a seção vazia, todos os arquivos e pastas na raiz do seu volume do StorSimple serão movidos para a raiz do seu compartilhamento de arquivos de destino do Azure. Na maioria dos casos, armazenar o conteúdo de um volume inteiro em um compartilhamento de arquivos do Azure não é a melhor abordagem. Muitas vezes, é melhor dividir o conteúdo de um volume em vários compartilhamentos de arquivos no Azure. Se você ainda não fez um plano, confira primeiro como Mapear seu volume do StorSimple para compartilhamentos de arquivos do Azure.

Como parte do plano de migração, você pode ter decidido que as pastas em um volume do StorSimple precisam ser divididas em vários compartilhamentos de arquivos do Azure. Se esse for o caso, você poderá fazer essa divisão por:

1. Definir vários trabalhos para migrar as pastas em um volume. Cada uma terá a mesma fonte de volume do StorSimple, mas um compartilhamento de arquivos do Azure diferente como destino.
2. Especifique com precisão quais pastas do volume StorSimple precisam ser migradas para o compartilhamento de arquivos especificado usando a seção Mapeamento de diretório do formulário de criação de trabalho e seguindo a semântica de mapeamento específica.

Importante

Os caminhos e as expressões de mapeamento neste formulário não podem ser validados quando o formulário for enviado. Se os mapeamentos forem especificados incorretamente, um trabalho poderá falhar completamente ou produzir um resultado indesejável. Nesse caso, geralmente é melhor excluir o compartilhamento de arquivos do Azure, recriá-lo e, em seguida, corrigir as instruções de mapeamento em um novo trabalho de migração para o compartilhamento. A execução de um novo trabalho com instruções de mapeamento fixo pode corrigir as pastas omitidas e colocá-las no compartilhamento existente. No entanto, somente as pastas que foram omitidas devido a erros de ortografia de caminho podem ser abordadas dessa forma.

Elementos semânticos

Um mapeamento é expresso da esquerda para a direita: [Caminho \source] > [caminho \target].

Caractere semântico	Significado
\	Indicador de nível raiz.
>	Operador [Origem] e [destino-mapeamento].
| ou RETURN (nova linha)	Separador de duas instruções de mapeamento de pasta. Como alternativa, você pode omitir esse caractere e selecionar para obter a próxima expressão de mapeamento na sua linha.

Exemplos

Move o conteúdo dos dados de usuário da pasta para a raiz do compartilhamento de arquivos de destino:

\User data > \

Move todo o conteúdo do volume para um novo caminho no compartilhamento de arquivos de destino:

\ > \Apps\HR tracker

Move o conteúdo da pasta de origem para um novo caminho no compartilhamento de arquivos de destino:

\HR resumes-Backup > \Backups\HR\resumes

Classifica vários locais de origem em uma nova estrutura de diretório:

\HR\Candidate Tracker\v1.0 > \Apps\Candidate tracker
\HR\Candidates\Resumes > \HR\Candidates\New
\Archive\HR\Old Resumes > \HR\Candidates\Archived

Regras semânticas

• Sempre especifique os caminhos de pasta relativos ao nível raiz.
• Inicie cada caminho de pasta com um indicador de nível raiz "\".
• Não inclua letras da unidade.
• Ao especificar vários caminhos, os caminhos de origem ou de destino não podem se sobrepor:
  Exemplo de sobreposição de caminho de origem inválido:
  
  
  
  
  Exemplo de sobreposição de caminho de destino inválido:
  >
  
  
  
• As pastas de origem que não existem são ignoradas.
• As estruturas de pasta que não existem no destino são criadas.
• Como o Windows, os nomes das pastas não diferenciam maiúsculas de minúsculas, mas as preservam.

Observação

O conteúdo da pasta Informação de volume \System e a $Recycle.bin no seu volume do StorSimple não serão copiados pelo trabalho de migração.

Executar um trabalho de migração

Os trabalhos de migração são listados em Definições de trabalho no recurso de Gerenciador de Dados que você implantou em um grupo de recursos. Na lista de definições de trabalho, selecione o trabalho que você deseja executar.

Na folha de trabalho que é aberta, você pode ver o status atual do seu trabalho e uma lista de backups selecionados. A lista de backups é classificada do mais antigo para o mais recente e será migrada para o compartilhamento de arquivos do Azure nesta ordem.

Inicialmente, o trabalho de migração terá o status: Nunca executar.
Quando estiver pronto, inicie o trabalho de migração. Selecione a imagem para uma versão com resolução mais alta.
Quando um backup é migrado com sucesso, um instantâneo automático do compartilhamento de arquivo do Azure é feito. A data de backup original do seu backup do StorSimple é colocada na seção Comentários do instantâneo do compartilhamento de arquivo do Azure. Usar esse campo permitirá ver quando o backup dos dados foi originalmente feito em comparação com a hora em que o instantâneo de compartilhamento de arquivo foi feito.

Cuidado

Os backups devem ser processados do mais antigo para o mais recente. Depois que um trabalho de migração é criado, você não pode alterar a lista de backups de volume StorSimple selecionados. Não inicie o trabalho se a lista de backups estiver incorreta ou incompleta. Exclua o trabalho e crie um novo com os backups corretos selecionados. Para cada backup selecionado, verifique os agendamentos de retenção. Os backups podem ser excluídos por uma ou mais políticas de retenção antes mesmo de terem a chance de serem migrados!

Erros por item

Os trabalhos de migração têm duas colunas na lista de backups que listam os problemas que podem ter ocorrido durante a cópia:

• Erros de cópia
  Esta coluna lista os arquivos ou as pastas que deviam ter sido copiados, mas não foram. Esses erros geralmente são recuperáveis. Quando um backup listar problemas de item nesta coluna, revise os logs de cópia. Se você precisar migrar esses arquivos, selecione repetir backup. Essa opção fica disponível quando o backup conclui o processamento. A seção Gerenciando um trabalho de migração explica suas opções em mais detalhes.
• Arquivos sem suporte
  Esta coluna lista as pastas ou os arquivos que não podem ser migrados. O Armazenamento do Microsoft Azure têm limitações em nomes de arquivo, comprimentos de caminho e tipos de arquivo que atualmente ou logicamente não podem ser armazenados em um compartilhamento de arquivos do Azure. Um trabalho de migração não será pausado para esses tipos de erros. Repetir a migração do backup não alterará o resultado. Quando um backup listar problemas de item nesta coluna, revise os logs de cópia e anote. Se esses problemas surgirem no último backup e você encontrar no log de cópia que a falha ocorreu devido a um nome de arquivo, comprimento de caminho ou outro problema sobre o qual você tem influência, convém corrigir o problema dinamicamente no volume do StorSimple, pegar um backup de volume do StorSimple e criar um novo trabalho de migração com apenas esse backup. Em seguida, você pode migrar esse namespace corrigido e ele se tornará a versão mais recente/dinâmica do compartilhamento de arquivo do Azure. Esse é um processo manual e demorado. Revise os logs de cópia com cuidado e avalie se vale a pena.

Esses logs de cópia são arquivos *.csv que listam os itens de namespace bem-sucedidos e os itens que não foram copiados. Os erros são divididos ainda mais nas categorias discutidas anteriormente. No local do arquivo de registro, você pode encontrar registros de arquivos com falha pesquisando por "falha". O resultado deverá um conjunto de logs para arquivos que não foram copiados. Classifique esses registros por tamanho. Pode haver logs extras produzidos com 17 bytes de tamanho. Eles estão vazios e podem ser ignorados. Com uma classificação, você pode se concentrar nos registros com conteúdo.

O mesmo processo se aplica a arquivos de log que registram cópias bem-sucedidas.

Gerenciar um trabalho de migração

Os trabalhos de migração têm os seguintes estados:

• Nunca executado
  Um trabalho novo que foi definido, mas nunca executado.
• Aguardando
  Um trabalho nesse estado está aguardando que os recursos sejam provisionados no serviço de migração. Ele será alternado automaticamente para um estado diferente quando estiver pronto.
• Com falha
  Um trabalho com falha atingiu um erro fatal que o impede de processar mais backups. Um trabalho não deve apresentar esse estado. A melhor atitude a tomar é fazer uma solicitação ao suporte.
• Cancelado / Cancelando
  Todo o trabalho de migração ou apenas backups individuais do trabalho podem ser cancelados. Backups cancelados não serão processados, pois um trabalho de migração cancelado interromperá o processamento de backups. Espera-se que o cancelamento de um trabalho leve muito tempo. Isso não impede a criação de um novo trabalho. A melhor atitude a tomar é esperar que um trabalho chegue totalmente ao estado de Cancelado. Você pode ignorar trabalhos com falha/cancelados ou excluí-los mais tarde. Você não precisa excluir trabalhos antes de excluir o recurso Gerenciador de Dados no final da migração do StorSimple.

Em execução

Um trabalho em execução está processando um backup no momento. Consulte a tabela na parte inferior da folha para ver qual backup está sendo processado no momento e quais já podem ter sido migrados.
Os backups migrados têm uma coluna com um link para um log de cópia. Se um backup relatar erros, você deverá examinar o log de cópia.

Em pausa

Um trabalho de migração está em pausa quando há uma decisão necessária. Essa condição habilita dois botões de comando na parte superior da folha:
Escolha
quando o backup mostrar arquivos que deveriam ser migrados, mas não foram (Coluna Erro de cópia).
Escolha
quando o backup estiver ausente (foi excluído pela política desde que você criou o trabalho de migração) ou quando o backup estiver corrompido. Você pode encontrar informações de erro detalhadas na folha aberta ao clicar no backup com falha.

Quando você
ou
o backup atual, o serviço de migração criará um instantâneo no compartilhamento de arquivo de destino do Azure. Talvez você deseje excluir o anterior mais tarde, pois ele provavelmente está incompleto.

Concluído e Concluído com avisos

Um trabalho de migração é listado como Concluído quando todos os backups no trabalho foram processados com êxito.
Concluído com avisos é um estado que ocorre quando:

• Um backup encontrou um problema recuperável. Esse backup é marcado como com êxito parcial ou com falha.
• Você decidiu continuar o trabalho em pausa ignorando o backup com esses problemas. (Você escolheu Ignorar backup em vez de Repetir backup)

Se o trabalho de migração for concluído com avisos, você sempre deverá revisar o log de cópia para os backups relevantes.

Executar trabalhos em paralelo

Você provavelmente terá vários volumes do StorSimple, cada um com seus próprios compartilhamentos que devem ser migrados para um compartilhamento de arquivo do Azure. É importante que você entenda o quanto você pode fazer em paralelo. Existem limitações que não são aplicadas na experiência do usuário e irão prejudicar ou inibir uma migração completa se os trabalhos forem executados ao mesmo tempo.

Não há limites para definir trabalhos de migração. Você pode definir o mesmo volume de origem do StorSimple, o mesmo compartilhamento de arquivos do Azure, nas mesmas ou em soluções diferentes do StorSimple. No entanto, a execução delas tem limitações:

• Somente um trabalho de migração com o mesmo volume de origem do StorSimple pode ser executado ao mesmo tempo.
• Somente um trabalho de migração com o mesmo compartilhamento de arquivos do Azure de destino pode ser executado ao mesmo tempo.
• Antes de iniciar o próximo trabalho, garanta que qualquer um dos trabalhos anteriores esteja no copy stage e mostre o progresso da movimentação de arquivos por pelo menos 30 minutos.
• Você pode executar até quatro trabalhos de migração em paralelo por gerenciador de dispositivos do StorSimple, desde que você cumpra as regras anteriores.

Quando você tenta iniciar um trabalho de migração, as regras anteriores são verificadas. Se houver trabalhos em execução, talvez você não consiga iniciar um novo trabalho. Você receberá um alerta que lista o nome dos trabalho em execução no momento que devem ser executados antes de iniciar o novo trabalho.

Dica

É uma boa ideia verificar regularmente seus trabalhos de migração na guia Definição de trabalho do recurso Gerenciador de Dados para ver se algum deles pausou e precisa da sua entrada para ser concluído.

Resumo da fase 3

No final da fase 3, você terá executado pelo menos um dos seus trabalhos de migração de volumes do StorSimple em compartilhamento(s) de arquivos do Azure. Com a sua execução, você terá migrado seus backups especificados para instantâneos de compartilhamento de arquivos do Azure. Agora você pode se concentrar em Configurar a Sincronização de Arquivos do Azure para o compartilhamento (como os trabalhos de migração para um compartilhamento foram concluídos) ou direcionar o acesso de compartilhamento para seus trabalhadores de informações e aplicativos para o compartilhamento de arquivos do Azure.

Fase 4: acessar seus compartilhamentos de arquivos do Azure

Há duas estratégias principais para acessar seus compartilhamentos de arquivos do Azure:

• Sincronização de arquivos do Azure: implante a Sincronização de Arquivos do Azure em uma instância local do Windows Server. A Sincronização de Arquivos do Azure tem todas as vantagens de um cache local, assim como o StorSimple.
• Acesso direto ao compartilhamento: implantar o acesso direto ao compartilhamento. Use essa estratégia se o cenário de acesso para um determinado compartilhamento de arquivo do Azure não se beneficiar do cache local ou se você não tiver mais a capacidade de hospedar uma instância do Windows Server local. Aqui, seus usuários e aplicativos continuarão a acessar compartilhamentos SMB pelo protocolo SMB. Esses compartilhamentos não estão mais em um servidor local, mas diretamente na nuvem.

Você já deve ter decidido qual é a melhor opção para você na Fase 1 deste guia.

O restante desta seção se concentra nas instruções de implantação.

Este vídeo aborda o seguinte:

• Abordagens de acesso a compartilhamentos de arquivos do Azure
• Sincronização de Arquivos do Azure
• Acesso de compartilhamento direto
• Implantando a Sincronização de Arquivos do Azure
• Implantar o recurso em nuvem da Sincronização de Arquivos do Azure
• Implantar uma instância local do Windows Server
• Preparação da instância do Windows Server para a Sincronização de Arquivos do Azure
• Configuração da Sincronização de Arquivos do Azure na instância do Windows Server
• Monitoramento da sincronização inicial
• Teste da Sincronização de Arquivos do Azure
• Criação dos compartilhamentos SMB

Implantar a Sincronização de Arquivos do Azure

É hora de implantar uma parte da Sincronização de Arquivos do Azure.

1. Criar o recurso em nuvem da Sincronização de Arquivos do Azure.
2. Implantar o agente da Sincronização de Arquivos do Azure no servidor local.
3. Registre o servidor com o recurso da nuvem.

Não crie ainda nenhum grupo de sincronização. A configuração da sincronização com um compartilhamento de arquivos do Azure só deve ocorrer depois que os trabalhos de migração para um compartilhamento de arquivos do Azure forem concluídos. Se você começar a usar a Sincronização de Arquivos do Azure antes de concluir a migração, ela poderá tornar a sua migração desnecessariamente difícil, já que você não poderia dizer com facilidade quando seria a hora de iniciar uma migração.

Implantar o recurso em nuvem da Sincronização de Arquivos do Azure

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.

Dica

Se você quiser alterar a região do Azure em que os dados residem após a conclusão da migração, implante o serviço da Sincronização de Armazenamento na mesma região que as contas de armazenamento de destino para essa migração.

Implantar uma instância local do Windows Server

• Criar um Windows Server 2019 (no mínimo um 2012R2) como uma máquina virtual ou um servidor físico. O cluster de failover do Windows Server também é compatível. Não reutilize o servidor a frente do StorSimple 8100 ou 8600.
• Provisione ou adicione armazenamento com conexão direta. Não há suporte para armazenamento de rede anexada.

É uma melhor prática dar à sua nova instância do Windows Server uma quantidade de armazenamento igual ou maior do que o dispositivo StorSimple 8100 ou 8600 tem disponível localmente para cache. Você usará a instância do Windows Server da mesma maneira que usou o dispositivo do StorSimple. Se ele tiver a mesma quantidade de armazenamento que o dispositivo, a experiência de cache deverá ser semelhante, se não for a mesma. Você pode adicionar ou remover o armazenamento de sua instância do Windows Server à vontade. Essa funcionalidade permite que você dimensione o tamanho do volume local e a quantidade de armazenamento local disponível para cache.

Preparar a instância do Windows Server para sincronização de arquivos

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á.

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.

Importante

A migração de arquivos e pastas do StorSimple para o compartilhamento de arquivos do Azure deve ser concluída antes de prosseguir. Verifique se não existem mais alterações feitas no compartilhamento de arquivos.

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.

Importante

Certifique-se de ativar a camada de nuvem. A camada de nuvem é o recurso AFS (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. Outro motivo para ativar a camada de nuvem nesta etapa é que não queremos sincronizar o conteúdo do arquivo neste estágio. Somente o namespace deve ser movido neste momento.

Implantar o acesso direto ao compartilhamento

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

• Visão geral de identidade
• Como ingressar no domínio de uma conta de armazenamento
• Visão geral de rede para compartilhamentos de arquivos do Azure
• Como configurar pontos de extremidade públicos e privados
• Como configurar uma VPN S2S
• Como configurar uma VPN P2S no Windows
• Como configurar uma VPN P2S no Linux
• Como configurar o encaminhamento de DNS
• Configurar DFS-N

Resumo da fase 4

Ao final desta fase, você criou e executou vários trabalhos de migração em seu Gerenciador de Dados do StorSimple. Esses trabalhos migraram seus arquivos, pastas e seus backups para compartilhamentos de arquivos do Azure. Você também implantou a Sincronização de Arquivos do Azure ou preparou suas contas de rede e de armazenamento para acesso direto ao compartilhamento.

Fase 5: migrar o usuário

Nesta fase, você concluirá sua migração:

• Planeje seu tempo de inatividade.
• Acompanhe todas as alterações de seus usuários e aplicativos produzidos no lado do StorSimple enquanto os trabalhos de migração na fase 3 estão em execução.
• Faça o failover de seus usuários para a nova instância do Windows Server com a Sincronização de Arquivos do Azure ou para os compartilhamentos de arquivos do Azure por meio do acesso direto ao compartilhamento.

Este vídeo aborda o seguinte:

• Etapas a serem seguidas antes da transferência da carga de trabalho
• Executar a transferência
• Etapas pós-transferência

Planeje seu tempo de inatividade

Essa abordagem de migração requer algum tempo de inatividade para seus usuários e aplicativos. O objetivo é manter o menor tempo de inatividade possível. As considerações a seguir podem ajudar:

• Mantenha os volumes do StorSimple disponíveis ao executar seus trabalhos de migração.
• Quando você terminar de executar seus trabalhos de migração de dados para um compartilhamento, é hora de remover o acesso do usuário (pelo menos acesso de gravação) dos volumes ou compartilhamentos do StorSimple. Um RoboCopy final irá acompanhar o compartilhamento de arquivos do Azure. Em seguida, você pode migrar seus usuários. O local em que você executa o RoboCopy depende se você optou por usar a Sincronização de Arquivos do Azure ou acesso direto ao compartilhamento. A próxima seção aborda esse assunto.
• Depois de concluir a atualização do RoboCopy, você estará pronto para expor o novo local para os usuários, diretamente pelo compartilhamento de arquivos do Azure ou por um compartilhamento SMB em uma instância do Windows Server com a Sincronização de Arquivos do Azure. Muitas vezes, uma implantação DFS-N ajudará a fazer uma migração rápida e eficiente. Ele manterá os endereços de compartilhamento existentes consistentes e reapontará para um novo local que contém seus arquivos e pastas migrados.

Uma abordagem totalmente viável para dados de arquivamento é tirar tempo de inatividade no seu volume (ou subpasta) do StorSimple, obter mais um backup de volume do StorSimple, migrar e, em seguida, abrir o destino de migração para acesso por usuários e aplicativos. Isso poupará você da necessidade de um RoboCopy de atualização. No entanto, essa abordagem é o custo de uma janela de tempo de inatividade prolongada que pode ser ampliada para vários dias ou mais, dependendo do número de arquivos e backups que você precisa migrar. Isso é provavelmente apenas uma opção para cargas de trabalho de arquivamento que pode fazer sem acesso de gravação por períodos prolongados de tempo.

Determinar quando seu namespace foi totalmente sincronizado com o servidor

Quando você usa a Sincronização de Arquivos do Azure para um compartilhamento de arquivo do Azure, é importante determinar que todo o namespace terminou o download para o servidor antes de iniciar um RoboCopy local. O tempo necessário para baixar seu namespace depende do número de itens em seu compartilhamento de arquivos do Azure. Há dois métodos para determinar se o namespace foi totalmente recebido no servidor.

Portal do Azure

Você pode usar o portal do Azure para ver quando o namespace foi totalmente entregue.

• Entre no portal do Azure e acesse seu grupo de sincronização. Verifique o status de sincronização do seu grupo de sincronização e do ponto de extremidade do servidor.
• A direção interessante é baixar. Se o ponto de extremidade do servidor for provisionado recentemente, ele mostrará a sincronização inicial, o que indica que o namespace ainda está sendo encerrado. Após essa alteração de estado para qualquer outro, exceto a sincronização inicial, o namespace será totalmente preenchido no servidor.

Agora você pode continuar com um RoboCopy local.

Visualizador de Eventos do Windows Server

Você também pode usar o Visualizador de Eventos em sua instância do Windows Server para saber quando o namespace foi totalmente entregue.

1. Abra o Visualizador de Eventos e vá até Aplicativos e Serviços.
2. Vá para e abra Microsoft\FileSync\Agent\Telemetry.
3. Procure o evento 9102 mais recente, que corresponde a uma sessão de sincronização concluída.
4. Selecione Detalhese confirme que você está observando um evento em que o valor de SyncDirection é Download.
5. No momento em que o namespace concluir o download para o servidor, haverá um único evento com Cenário, o valor FullGhostedSync e HResult = 0.
6. Se você perder esse evento, também poderá procurar outros eventos 9102 com o SyncDirection = Download e o Cenário = "RegularSync". A localização de um desses eventos também indica que o namespace concluiu o download e a sincronização progrediu para sessões de sincronização regulares, existindo alguma coisa a ser sincronizada ou não no momento.

Um RoboCopy final

Neste ponto, há diferenças entre sua instância local do Windows Server e o dispositivo do StorSimple 8100 ou 8600.

1. Você precisa acompanhar as alterações que os usuários ou aplicativos produziram no lado do StorSimple enquanto a migração estava em andamento.
2. Para casos em que você usa a Sincronização de Arquivos do Azure: o dispositivo do StorSimple tem um cache populado contra a instância do Windows Server com apenas um namespace sem conteúdo de arquivo armazenado localmente neste momento. O RoboCopy final pode ajudar a iniciar rapidamente o cache da Sincronização de Arquivos do Azure local ao efetuar pull do conteúdo do arquivo armazenado em cache localmente, assim como está disponível e pode caber no servidor da Sincronização de Arquivos do Azure.
3. Alguns arquivos podem ter sido deixados para trás pelo trabalho de migração devido a caracteres inválidos. Nesse caso, copie-os para a instância do Windows Server habilitada para a Sincronização de Arquivos do Azure. Posteriormente, você poderá ajustá-los para que eles sejam sincronizados. Se você não usar a Sincronização de Arquivos do Azure para um compartilhamento específico, será melhor renomear os arquivos com caracteres inválidos no volume do StorSimple. Em seguida, execute o RoboCopy diretamente no compartilhamento de arquivos do Azure.

Aviso

O Robocopy no Windows Server 2019 apresentava um problema que fazia com que os arquivos em camadas pela Sincronização de Arquivos do Azure no servidor de destino fossem copiados novamente da origem e recarregados no Azure ao usar a função /MIR. É recomendável executar o Robocopy em um Windows Server diferente do 2019, como o Windows Server 2016.

Aviso

Você não deve iniciar o Robocopy antes que o servidor tenha o namespace para um compartilhamento de arquivos do Azure baixado totalmente. Para obter mais informações, consulte Determinar quando seu namespace foi totalmente baixado no seu servidor.

Você só deseja copiar os arquivos que foram alterados após a última execução do trabalho de migração e os arquivos que não foram movidos por meio desses trabalhos antes. Você pode resolver o problema para o motivo pelo qual eles não se moveram mais tarde no servidor, após a conclusão da migração. Para saber mais, consulte Solução de problemas da Sincronização de Arquivos do Azure.

O RoboCopy tem vários parâmetros. O exemplo a seguir demonstra um comando concluído e uma lista de motivos para escolher esses parâmetros.

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 do Robocopy.

Quando você configurar os locais de origem e de destino do comando RoboCopy, certifique-se de examinar a estrutura da origem e do destino para garantir que elas correspondam. Se você usou o recurso de mapeamento de diretório do trabalho de migração, sua estrutura de diretório raiz poderá ser diferente da estrutura do seu volume StorSimple. Se esse for o caso, talvez sejam necessários vários trabalhos do RoboCopy, um para cada subdiretório. Se você não tiver certeza se o comando será executado conforme o esperado, você poderá usar o parâmetro /L, que simulará o comando sem realmente fazer nenhuma alteração.

Esse comando do RoboCopy usa /MIR, portanto, não moverá arquivos que são os mesmos (arquivos em camadas, por exemplo). Mas se você receber o caminho de origem e de destino errado, o /MIR também limpará as estruturas do diretório na instância do Windows Server ou no compartilhamento de arquivo do Azure que não estão presentes no caminho de origem do StorSimple. Eles devem corresponder exatamente ao trabalho do RoboCopy para alcançar seu objetivo pretendido de atualizar o conteúdo migrado com as últimas alterações feitas enquanto a migração está em andamento.

Consulte o arquivo de log do RoboCopy para ver se arquivos foram deixados para trás. Se surgirem problemas, corrija-os e execute novamente o comando RoboCopy. Não desprovisione nenhum recurso do StorSimple antes de corrigir problemas pendentes dos arquivos ou pastas com os quais você se preocupa.

Caso você não use a Sincronização de Arquivos do Azure para armazenar em cache o compartilhamento de arquivos do Azure específico em questão, mas opte pelo acesso direto ao compartilhamento:

1. Monte o compartilhamento de arquivos do Azure como uma unidade de rede em uma máquina local do Windows.
2. Execute o RoboCopy entre o StorSimple e o compartilhamento de arquivos do Azure montado. Se os arquivos não copiarem, corrija os nomes deles no lado do StorSimple para remover caracteres inválidos. Em seguida, tente o RoboCopy novamente. O comando RoboCopy listado anteriormente pode ser executado várias vezes sem causar uma recall desnecessária ao StorSimple.

Solucionar problemas e otimizar

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

• IOPS no armazenamento da origem e do 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

Nessa categoria, você precisa considerar as capacidades do armazenamento de origem, do armazenamento de destinoe da rede que os conecta. A taxa de transferência máxima possível é determinada pelos três componentes mais lentos. Verifique se sua infraestrutura de rede está configurada para dar suporte a velocidades de transferência ideais em suas melhores capacidades.

Cuidado

Embora a cópia mais rápida possível seja muitas vezes mais desejável, considere a utilização da rede local e do dispositivo NAS para outras tarefas muitas vezes comercialmente críticas.

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

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

O RoboCopy pode inserir atrasos entre pacotes especificando a opção /IPG:n, em que n é medido em milissegundos entre os pacotes do RoboCopy. O uso dessa opção pode ajudar a evitar a monopolização de recursos em ambos os dispositivos com restrição de e/s e links de rede lotados.

/IPG:n não pode ser usado para a limitação de rede exata em determinados Mbps. Em vez disso, use a QoS de rede do Windows Server. O RoboCopy conta totalmente com o protocolo SMB para todas as necessidades de rede. Usar o SMB é o motivo pelo 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 ao IOPS observado no NAS. O tamanho do cluster no volume do NAS, os tamanhos de pacotes e uma série de outros fatores influenciam o IOPS observado. A introdução do atraso entre pacotes geralmente é a maneira mais fácil de controlar a carga no NAS. Teste vários valores, por exemplo, de cerca de 20 milissegundos (n=20) a múltiplos desse número. Depois de introduzir um atraso, você poderá avaliar se os 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 ele está apontado e avaliará cada arquivo e pasta para cópia. Cada arquivo será avaliado durante uma cópia inicial e durante as cópias de atualização. Por exemplo, execuções repetidas de RoboCopy/MIR em relação aos mesmos locais de armazenamento de origem e de destino. Essas execuções repetidas são úteis para minimizar o tempo de inatividade de usuários e aplicativos, e para melhorar a taxa geral de êxito dos arquivos migrados.

Geralmente, o padrão é considerar a largura de banda como o fator mais limitador em uma migração, e isso pode ser verdadeiro. Mas a capacidade de enumerar um namespace pode influenciar no tempo total para copiar ainda mais para namespaces maiores com arquivos menores. Considere que a cópia de 1 TiB de arquivos pequenos levará consideravelmente mais tempo do que a cópia de 1 TiB de menos arquivos com um tamanho maior, supondo que todas as outras variáveis permaneçam iguais. Portanto, você poderá ter uma transferência lenta se estiver migrando um grande número de arquivos pequenos. Este é um comportamento esperado.

A causa dessa diferença é a capacidade de processamento necessária para percorrer um namespace. O RoboCopy dá suporte a cópias em vários threads por meio do parâmetro /MT:n, em que n significa o número de threads a serem usados. Portanto, ao provisionar um computador especificamente para o RoboCopy, considere o número de núcleos de processador e sua relação com a contagem de threads que eles fornecem. O mais comum são dois threads por núcleo. O núcleo e a contagem de threads de um computador são pontos de dados importantes para decidir quais valores de vários threads /MT:n devem ser especificados. Considere também quantos trabalhos do RoboCopy você planeja executar em paralelo em um determinado computador.

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 extra de recursos em nossos 1 TiB de arquivos maiores pode não produzir benefícios proporcionais. Uma alta contagem de threads tentará copiar mais arquivos grandes pela rede simultaneamente. Essa atividade extra de rede aumenta a probabilidade de se restringir pela taxa de transferência ou pelo IOPS de armazenamento.

Durante um primeiro trabalho do RoboCopy em um destino vazio ou uma execução diferencial com muitos arquivos alterados, é provável que você se depare com uma restrição causada pela taxa de transferência da sua rede. Comece com uma alta contagem de threads para uma execução inicial. Uma alta contagem de threads, mesmo além dos threads disponíveis no momento no computador, ajuda a saturar a largura de banda de rede disponível. As execuções /MIR subsequentes são impactadas progressivamente pelo processamento de itens. Menos alterações em uma execução diferencial significam menos transporte de dados pela rede. Sua velocidade agora é mais dependente de sua capacidade de processar itens de namespace do que movê-los no link de rede. Para as execuções subsequentes, relacione o valor de contagem de threads com a contagem de núcleos do processador e a contagem de threads por núcleo. Pondere se os núcleos precisam ser reservados para outras tarefas que um servidor de produção possa ter.

Dica

Regra geral: o provisionamento em excesso da contagem de threads (/MT:n) é útil para a primeira execução do RoboCopy, que vai transferir muitos dados de uma rede de maior latência. As execuções seguintes terão menos dados diferentes a copiar, e é mais provável que você queira alterar de taxa de transferência de rede restrita para computação restrita. Nessas circunstâncias, é melhor corresponder a contagem de threads do RoboCopy com a de threads realmente disponíveis no computador. O excesso de provisionamento nesse cenário pode levar a mais mudanças de contexto no processador, e provavelmente vai retardar a cópia.

Evitar trabalho desnecessário

Evite alterações em grande escala em seu namespace. Por exemplo, mover arquivos entre diretórios, alterar propriedades em grande escala ou alterar permissões (ACLs de NTFS). As alterações de ACL, especialmente, podem ter um alto impacto, porque elas têm em geral um efeito de alteração em cascata em arquivos inferiores na hierarquia de pastas. As consequências podem ser:

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

Outro aspecto importante é usar a ferramenta RoboCopy com eficiência. 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 vezes uma ferramenta de cópia, como o RoboCopy. Uma execução inicial, digamos de um NAS para o DataBox ou um servidor para um compartilhamento de arquivos do Azure. E uma ou mais execuções extras com o switch /MIR para capturar e tentar novamente os arquivos que não foram copiados.

Você deve estar preparado para executar várias vezes o RoboCopy em um determinado escopo de namespace. As execuções sucessivas terminarão mais rapidamente, pois elas têm menos a ser copiado, mas são restritas cada vez mais pela velocidade de processamento do namespace. Quando você executa várias vezes, é possível acelerar cada rodada fazendo com que o RoboCopy não tente copiar tudo em uma determinada execução. Essas opções do RoboCopy podem fazer uma diferença significativa:

• /R:n n = com que frequência você tenta copiar um arquivo com falha e
• /W:n n = quantos segundos aguardar entre repetições

/R:5 /W:5 é uma configuração razoável que você pode ajustar para sua preferência. Neste exemplo, um arquivo com falha será repetido cinco vezes, com tempo de espera de cinco segundos entre as repetições. Se o arquivo ainda não for copiado, o próximo trabalho do RoboCopy tentará novamente. Em geral, arquivos que falharam porque estão em uso ou devido a problemas de tempo limite podem eventualmente ser copiados com êxito dessa forma.

Windows Server 2022 e RoboCopy LFSM

A opção /LFSM do RoboCopy pode ser usada para evitar que um trabalho do RoboCopy falhe com um erro volume completo. O RoboCopy fará uma pausa sempre que uma cópia de arquivo causar uma redução do espaço livre do volume de destino abaixo de um valor base.

Use o RoboCopy com o Windows Server 2022. Somente essa versão do RoboCopy contém correções de bugs e recursos importantes que tornam a opção compatível com os sinalizadores adicionais necessários na maioria das migrações. Por exemplo, a compatibilidade com o sinalizador /B.

/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.

Normalmente, o RoboCopy pode ser executado em um computador de origem, de destino ou em um terceiro.

Importante

Se você pretende usar /LFSM, o RoboCopy precisa ser executado no servidor da Sincronização de Arquivos do Azure de destino do Windows Server 2022.

Observe também que com /LFSM, você também precisa usar um caminho local para o destino, não um caminho UNC. Por exemplo, como caminho de destino, você deve usar E:\Foldername em vez de um caminho UNC como \\ServerName\FolderName.

Cuidado

A versão do RoboCopy disponível no Windows Server 2022 no momento tem um bug que faz com que as pausas entrem na contagem de erros por arquivo. Aplique a solução alternativa a seguir.

Os sinalizadores /R:2 /W:1 recomendados aumentam a probabilidade de que um arquivo falhe devido a uma pausa induzida por /LFSM. Neste exemplo, um arquivo que não foi copiado após três pausas porque /LFSM causou a pausa, fará com que o arquivo falhe incorretamente no RoboCopy. A solução alternativa para isso é usar valores mais altos para /R:n e /W:n. Um bom exemplo é /R:10 /W:1800 (10 repetições de 30 minutos cada). Assim, o algoritmo de camadas da Sincronização de Arquivos do Azure tem tempo para criar espaço no volume de destino.

Esse bug foi corrigido, mas a correção ainda não está disponível publicamente. Confira este parágrafo para obter atualizações sobre a disponibilidade da correção e como implantá-la.

Migração do usuário

Se você usar a Sincronização de Arquivos do Azure, provavelmente precisará criar os compartilhamentos SMB nessa instância do Windows Server habilitada para a Sincronização de Arquivos do Azure que correspondam aos compartilhamentos que você tinha nos volumes do StorSimple. Você pode antecipar esta etapa e fazer isso mais cedo para não perder tempo aqui. Mas você deve garantir que antes desse ponto, ninguém tenha acesso para causar alterações na instância do Windows Server.

Se você tiver uma implantação DFS-N, poderá apontar os DFN-Namespaces para os locais da nova pasta do servidor. Se você não tiver uma implantação DFS-N e tiver antecipado o dispositivo 8100 ou 8600 localmente com uma instância do Windows Server, você poderá retirar esse servidor do domínio. Em seguida, ingresse no domínio que a nova instância do Windows Server habilitou para a Sincronização de Arquivos do Azure. Durante esse processo, dê ao servidor o mesmo nome de servidor e compartilhe nomes como o servidor antigo para que a migração permaneça transparente para os usuários, política de grupo e scripts.

Saiba mais sobre DFS-N.

Fase 6: desprovisionar

Ao desprovisionar um recurso, você perde o acesso à configuração desse recurso e a seus dados. O desprovisionamento não pode ser desfeito. Não continue até confirmar que:

• Sua migração foi concluída.
• Não exista nenhuma dependência em relação aos arquivos, pastas ou backups de volume do StorSimple que você está prestes a desprovisionar.

Antes de começar, é uma melhor prática observar sua nova implantação da Sincronização de Arquivos do Azure em produção por algum tempo. Esse tempo serve de oportunidade para corrigir todos os problemas que você pode encontrar. Depois de observar sua implantação da Sincronização de Arquivos do Azure por pelo menos alguns dias, você pode começar a desprovisionar recursos nesta ordem:

1. Desprovisione seu recurso de Gerenciador de Dados do StorSimple por meio do portal do Azure. Todos os trabalhos do DTS serão excluídos com ele. Você não poderá recuperar facilmente os logs de cópia. Se eles forem importantes para seus registros, recupere-os antes de desprovisionar.
2. Verifique se os dispositivos físicos do StorSimple foram migrados e cancele o registro deles. Se você não tiver certeza de que eles foram migrados, não continue. Se você desprovisionar esses recursos enquanto eles ainda são necessários, não será possível recuperar os dados ou a configuração deles.
   Opcionalmente, você pode primeiro desprovisionar o recurso de volume do StorSimple, que limpará os dados no dispositivo. Esse processo pode levar vários dias e não vai zerar os dados no dispositivo de forma forense. Se isso for importante para você, trate a anulação do disco separadamente do desprovisionamento de recursos e de acordo com suas políticas.
3. Se não existirem mais dispositivos registrados em um Gerenciador de Dispositivos do StorSimple, você poderá continuar a remover o próprio recurso de Gerenciador de Dispositivos.
4. Agora é hora de excluir a conta de armazenamento do StorSimple no Azure. Novamente, pare e confirme se a migração foi concluída e se nada e nem ninguém depende desses dados antes de continuar.
5. Desconecte o dispositivo físico do StorSimple do seu data center.
6. Se você possui o dispositivo do StorSimple, você está livre para fazer a reciclagem dele do PC. Se o dispositivo for concedido, informe o proprietário e devolva o dispositivo conforme apropriado.

Sua migração foi concluída.

---

Observação

Você ainda tem dúvidas ou encontrou algum problema?
Estamos aqui para ajudar:

Solução de problemas

Ao usar o serviço de migração do Gerenciador de Dados do StorSimple, um trabalho de migração inteiro ou arquivos individuais podem falhar por vários motivos. A seção de fidelidade de arquivo tem mais detalhes sobre cenários com suporte/sem suporte. As tabelas a seguir listam códigos de erro, detalhes de erro e, sempre que possível, opções de mitigação.

Erros no nível de trabalho

Fase	Erro	Detalhes/Mitigação
Backup	Não foi possível encontrar um backup para os parâmetros especificados	O backup selecionado para a execução do trabalho não é encontrado no momento de "Estimativa" ou "Cópia". Verifique se ainda há backup no catálogo de backup do StorSimple. Às vezes, as políticas de retenção de backup automático excluem backups entre selecioná-los para migração e, na verdade, executar o trabalho de migração para esse backup. Desabilite quaisquer agendas de retenção de backup antes de iniciar uma migração.
Estimativa Configurar computação	Falha na instalação de chaves de criptografia	Sua Chave de Criptografia de Dados de Serviço está incorreta. Revise a seção de chave de criptografia neste artigo para obter mais detalhes e ajudar a recuperar a chave correta.
	Erro no lote	É possível que iniciar toda a infraestrutura interna necessária para executar uma migração apresente um problema. Vários outros serviços estão envolvidos nesse processo. Esses problemas geralmente se resolvem quando você tenta executar o trabalho novamente.
	O StorSimple Manager detectou um erro interno. Aguarde alguns minutos e repita a operação. Se o problema persistir, contate o Suporte da Microsoft. (Código de erro: 1074161829)	Esse erro genérico tem várias causas, mas uma possibilidade é que o gerenciador de dispositivos StorSimple atingiu o limite de 50 dispositivos. Verifique se os trabalhos executados mais recentemente no gerenciador de dispositivos começaram a falhar repentinamente com esse erro, o que pode indicar que esse é o problema. A mitigação para esse problema específico é remover todos os dispositivos do StorSimple 8001 offline criados e usados pelo Serviço do Gerenciador de Dados. Você pode arquivar um tíquete de suporte ou excluí-los manualmente no portal. Exclua apenas dispositivos offline da série 8001.
Estimativa de Arquivos	Falha no trabalho de clonagem de volume	Esse erro provavelmente indica que você especificou um backup que foi corrompido de alguma forma. O serviço de migração não pode montá-lo, nem lê-lo. Você pode tentar fazer o backup manualmente ou abrir um tíquete de suporte.
	Não é possível continuar, pois o volume está no formato não NTFS	Somente volumes NTFS, não habilitados para dedupe, podem ser usados pelo serviço de migração. Se você tiver um volume formatado de maneira diferente, como o ReFS ou um formato de terceiros, o serviço de migração não poderá migrar esse volume. Confira a seção Limitações conhecidas.
	Entre em contato com o suporte. Nenhuma partição adequada encontrada no disco	O disco StorSimple que deveria ter o volume especificado para a migração parece que não tem uma partição para esse volume. Isso é incomum e pode indicar uma corrupção ou alinhamento incorreto de gerenciamento. Sua única opção para investigar esse problema com mais detalhes é registrar um tíquete de suporte.
	Tempo limite atingido	A fase de estimativa que falha com um tempo limite, normalmente é um problema com o dispositivo StorSimple ou com o Backup de Volume de origem lento e, às vezes, até corrompido. Se executar novamente o backup não funcionar, o arquivamento de um tíquete de suporte será o melhor curso de ação.
	Não foi possível localizar o <caminho do arquivo> Não foi possível encontrar uma parte do caminho	A definição de trabalho permite que você forneça um sub-caminho de origem. Esse erro é mostrado quando esse caminho não existe. Por exemplo: \Share1 > \Share\Share1 Neste exemplo, você especificou \Share1 como um sub-caminho na origem, mapeando para outro sub-caminho no destino. No entanto, o caminho de origem não existe (foi escrito incorretamente?). Observação: o Windows preserva maiúsculas e minúsculas, mas não dependente de maiúsculas e minúsculas. Ou seja, especificar \Share1 e \share1 é equivalente. Além disso: os caminhos de Destino que não existem serão criados automaticamente.
	Esta solicitação não está autorizada a executar esta operação	Esse erro é exibido quando a conta de armazenamento do StorSimple de origem ou a conta de armazenamento de destino com o compartilhamento de arquivo do Azure tem uma configuração de firewall habilitada. Você deve permitir o tráfego pelo ponto de extremidade público e não restringi-lo com regras de firewall adicionais. Caso contrário, o Serviço de Transformação de Dados não poderá acessar nenhuma das contas de armazenamento, mesmo que você tenha autorizado isso. Desabilite todas as regras de firewall e execute novamente o trabalho.
Copiando Arquivos	A conta que está sendo acessada não dá suporte a HTTP	Desabilite o roteamento da Internet na conta de armazenamento de destino ou use o ponto de extremidade de roteamento da Microsoft.
	O compartilhamento especificado está cheio	Se o destino for um compartilhamento de arquivo premium do Azure, verifique se você provisionou capacidade suficiente para o compartilhamento. O excesso de provisionamento temporário é uma prática comum. Se o destino for um compartilhamento de arquivo padrão do Azure, verifique se o compartilhamento de destino tem o recurso "compartilhamento de arquivos grande" habilitado. O armazenamento standard cresce à medida que você usa o compartilhamento. No entanto, se você usar uma conta de armazenamento herdada como destino, poderá encontrar um limite de compartilhamentos de 5 TiB. Você precisará habilitar manualmente o recurso "Compartilhamento de arquivo grande". Corrija os limites no destino e execute novamente o trabalho.

Erros no nível do item

Durante a fase de cópia de uma execução de trabalho de migração, itens de namespace individuais (arquivos e pastas) podem detectar erros. A tabela a seguir lista os erros mais comuns e sugere opções de mitigação quando possível.

Fase	Erro	Atenuação
Cópia	-2146233088 O servidor está ocupado.	Execute novamente o trabalho se houver muitas falhas. Se houver apenas poucos erros, você poderá tentar executar o trabalho novamente, mas muitas vezes uma cópia manual dos itens com falha poderá ser mais rápida. Em seguida, retome a migração ignorando o processamento do próximo backup.
	-2146233088 A operação não pôde ser concluída dentro do tempo permitido ou do número máximo de tentativas possível.	Execute novamente o trabalho se houver muitas falhas. Se houver apenas poucos erros, você poderá tentar executar o trabalho novamente, mas muitas vezes uma cópia manual dos itens com falha poderá ser mais rápida. Em seguida, retome a migração ignorando o processamento do próximo backup.
	Carregar tempo limite ou copiar não iniciado	Execute novamente o trabalho se houver muitas falhas. Se houver apenas poucos erros, você poderá tentar executar o trabalho novamente, mas muitas vezes uma cópia manual dos itens com falha poderá ser mais rápida. Em seguida, retome a migração ignorando o processamento do próximo backup.
	-2146233029 A operação foi cancelada.	Execute novamente o trabalho se houver muitas falhas. Se houver apenas poucos erros, você poderá tentar executar o trabalho novamente, mas muitas vezes uma cópia manual dos itens com falha poderá ser mais rápida. Em seguida, retome a migração ignorando o processamento do próximo backup.
	1920 O arquivo não pode ser acessado pelo sistema.	Esse é um erro comum quando o mecanismo de migração encontra um ponto de nova análise, um link ou uma junção. Elas não são compatíveis. Esses tipos de arquivos não podem ser copiados. Revise a seção Limitações conhecidas e a seção Fidelidade de arquivo neste artigo.
	-2147024891 Acesso negado	Esse é um erro para arquivos criptografados de uma forma que eles não podem ser acessados no disco. Arquivos que podem ser lidos do disco, mas simplesmente têm conteúdo criptografado, não são afetados e podem ser copiados. Sua única opção é copiá-los manualmente. Você pode encontrar esses itens montando o volume afetado e executando o seguinte comando: get-childitem <path> [-Recurse] -Force -ErrorAction SilentlyContinue | Where-Object {$_.Attributes -ge "Encrypted"} | format-list fullname, attributes
	Não é um FileTime Win32 válido. Nome do parâmetro: fileTime	Nesse caso, o arquivo pode ser acessado, mas não pode ser avaliado para cópia porque um carimbo de data/hora, do qual o mecanismo de migração depende, está corrompido ou foi gravado por um aplicativo em um formato incorreto. Não há muito que você possa fazer, pois não é possível alterar o carimbo de data/hora no backup. Se a retenção desse arquivo for importante, talvez na versão mais recente (último backup que contém esse arquivo) você copie manualmente o arquivo, corrija o carimbo de data/hora e, em seguida, mova-o para o compartilhamento de arquivo do Azure de destino. Essa opção não é muito bem dimensionada, mas é uma opção para arquivos de alto valor nos quais você deseja ter pelo menos uma versão retida em seu destino.
	-2146232798 SafeHandle foi fechado	Geralmente, um erro transitório. Execute novamente o trabalho se houver muitas falhas. Se houver apenas poucos erros, você poderá tentar executar o trabalho novamente, mas muitas vezes uma cópia manual dos itens com falha poderá ser mais rápida. Em seguida, retome a migração ignorando o processamento do próximo backup.
	-2147024413 Erro fatal de hardware do dispositivo	Esse é um erro raro e não é realmente relatado para um dispositivo físico, mas para os dispositivos virtualizados da série 8001 usados pelo serviço de migração. O dispositivo apresentou um problema. Os arquivos com esse erro não impedirão que a migração prossiga para o próximo backup. Isso dificulta a execução de uma cópia manual ou a repetição do backup que contém arquivos com esse erro. Se os arquivos deixados para trás forem muito importantes ou houver um grande número de arquivos, talvez seja necessário iniciar a migração de todos os backups novamente. Abrir um tíquete de suporte para obter uma análise mais detalhada.
Excluir (Limpeza de espelho)	O diretório especificado não está vazio.	Esse erro ocorre quando o modo de migração é definido como espelho e o processo que remove itens do compartilhamento de arquivo do Azure teve um problema que impediu a exclusão de itens. A exclusão ocorre apenas no compartilhamento dinâmico, não em instantâneos anteriores. A exclusão é necessária porque os arquivos afetados não estão no backup atual e, portanto, devem ser removidos do compartilhamento dinâmico antes do próximo instantâneo. Há duas opções: opção 1: montar o compartilhamento de arquivo do Azure de destino e excluir os arquivos com esse erro manualmente. Opção 2: você pode ignorar esses erros e continuar processando o próximo backup com a expectativa de que o destino não seja idêntico à origem e tenha alguns itens extras que não estavam no backup original do StorSimple.
	Solicitação incorreta	Esse erro indica que o arquivo de origem tem determinadas características que não puderam ser copiadas para o compartilhamento de arquivo do Azure. Mais especificamente, é possível que haja caracteres de controle invisíveis em um nome de arquivo ou 1 byte de um caractere de byte duplo no nome do arquivo ou caminho do arquivo. Você pode usar os logs de cópia para obter nomes de caminho, copiar os arquivos para um local temporário, renomear os caminhos para remover os caracteres sem suporte e, em seguida, executar robocopy novamente para o compartilhamento de arquivo do Azure. Em seguida, você pode retomar a migração pulando para o próximo backup a ser processado.

Próximas etapas

• Entenda a flexibilidade das políticas de camadas de nuvem.
• Habilite o Backup do Microsoft Azure nos compartilhamentos de arquivos do Azure para agendar instantâneos e definir agendamentos de retenção de backup.
• Se você observar no portal do Azure que alguns arquivos estão permanentemente sem sincronização, revise o Guia de solução de problemas para saber as etapas para resolver esses problemas.