Migração do StorSimple 8100 e 8600 para o Azure File Sync

A série StorSimple 8000 inclui os dispositivos físicos locais 8100 ou 8600 e seus componentes de serviço de nuvem. Os dispositivos virtuais StorSimple 8010 e 8020 também são abordados neste guia de migração. É possível migrar os dados de qualquer um desses dispositivos para compartilhamentos de arquivos do Azure com a Sincronização de Arquivos do Azure opcional. O Azure File Sync é o serviço padrão e estratégico de longo prazo do Azure 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.

Nota

O Serviço StorSimple (incluindo o StorSimple Device Manager para as séries 8000 e 1200 e o StorSimple Data Manager) chegou ao fim do suporte. O fim do suporte para 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 publicadas no portal do Azure e na visão geral do StorSimple. Entre em contato com o Suporte da Microsoft para obter detalhes adicionais.

Este vídeo fornece uma visão geral de:

• Ficheiros do Azure
• Azure File Sync
• Comparação de arquivos StorSimple & Azure
• Visão geral da ferramenta de migração e do processo do StorSimple Data Manager

Fase 1: Preparar a migração

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

Este vídeo aborda o seguinte:

• Seleção do nível de armazenamento
• Seleção de opções de redundância de armazenamento
• Selecionando acesso direto de compartilhamento versus Sincronização de Arquivos do Azure
• Chave de criptografia de dados do serviço StorSimple e número de série
• Migração do StorSimple Volume Backup
• Mapeando volumes e compartilhamentos StorSimple para compartilhamentos de arquivos do Azure
• Agrupando compartilhamentos dentro de compartilhamentos de arquivos do Azure
• Considerações sobre mapeamento
• Planilha de planejamento de migração
• Planilha de mapeamento de namespace

Inventário

Quando você começar a planejar sua migração, primeiro identifique todos os dispositivos StorSimple e os volumes necessários para migrar. Depois, você pode decidir sobre o melhor caminho de migração.

• Os dispositivos físicos 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 dos custos de migração

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

• Saída de rede: seus arquivos StorSimple vivem em uma conta de armazenamento dentro de uma região específica do Azure. Se você provisionar os compartilhamentos de arquivos do Azure migrados para uma conta de armazenamento na mesma região do Azure, não ocorrerão custos 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, os custos de saída serão aplicados.
• 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 dela), os custos de transação se aplicam à medida que os arquivos e metadados estão sendo gravados. Como prática recomendada, inicie seu compartilhamento de arquivos do Azure na camada otimizada de transação durante a migração. Mude para a camada desejada após a conclusão da migração. As fases descritas neste artigo chamam isso a atenção 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, é mais eficiente em termos de custos seguir os conselhos do ponto anterior.
• Custo de armazenamento: quando essa migração começa a copiar arquivos para um compartilhamento de arquivos do Azure, o armazenamento é consumido e cobrado. Os backups migrados tornam-se instantâneos de compartilhamento de arquivos do Azure. Os instantâneos de compartilhamento de arquivos consomem apenas capacidade de armazenamento pelas diferenças que contêm.
• StorSimple: Até que você desprovisione os dispositivos StorSimple e as contas de armazenamento, o custo do StorSimple para armazenamento, backups e dispositivos continuará a ocorrer.

Acesso de compartilhamento direto vs. 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 arquivo. Um compartilhamento de arquivos do Azure é um compartilhamento SMB na nuvem que você pode configurar para que os usuários acessem diretamente pelo 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 é o Azure File Sync. O Azure File Sync é um análogo direto para a capacidade do StorSimple de armazenar em cache arquivos usados com freqüência no local.

O Azure File Sync é um serviço de nuvem da Microsoft, baseado em dois componentes principais:

• Sincronização de arquivos e hierarquização na nuvem para criar um cache de acesso de desempenho em qualquer Windows Server.
• Partilhas de ficheiros como armazenamento nativo no Azure que pode ser acedido através de vários protocolos, como SMB e REST de ficheiros.

Os compartilhamentos de arquivos do Azure retêm aspetos importantes de fidelidade de arquivos, como atributos, permissões e carimbos de data/hora. Com os compartilhamentos de arquivos do Azure, não há mais a necessidade de um aplicativo ou serviço para interpretar os arquivos e pastas armazenados na nuvem. Você pode acessá-los nativamente através de protocolos e clientes familiares. As partilhas de ficheiros do Azure permitem-lhe armazenar dados do servidor de ficheiros de uso geral e dados de aplicações na nuvem.

Este artigo se concentra nas etapas de migração. Se quiser saber mais sobre o Azure File Sync antes de migrar, consulte os seguintes artigos:

• Guia de planejamento do Azure File Sync
• Guia de implantação do Azure File Sync

Chave de criptografia de dados do serviço StorSimple

Quando você configurou seu 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 onde 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 aparelhos em seu inventário.

Se não conseguir encontrar as chaves nos seus registos, pode gerar uma nova chave a partir do aparelho. Cada dispositivo tem uma chave de encriptação exclusiva.

Alterar a chave de criptografia de dados de serviço

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

Alterar a chave de criptografia de dados de serviço é um processo de 3 etapas:

1. Usando scripts do Windows PowerShell para o Azure Resource Manager, autorize um dispositivo a alterar a chave de criptografia de dados do serviço.
2. Usando o Windows PowerShell para StorSimple, inicie a alteração da chave de criptografia de dados do 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: Usar o script do Windows PowerShell para autorizar um dispositivo a alterar a chave de criptografia de dados de serviço

Normalmente, o administrador do dispositivo solicitará que o administrador do serviço autorize um dispositivo a alterar as chaves de criptografia de dados do serviço. O administrador do serviço autorizará o dispositivo a alterar a chave.

Esta etapa é executada usando o script baseado no Azure Resource Manager. O administrador de serviço pode selecionar um dispositivo qualificado para ser autorizado. 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, vá para Authorize-ServiceEncryptionRollover.ps1

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

Um dispositivo deve atender aos seguintes critérios antes de poder ser autorizado a iniciar alterações na chave de criptografia de dados de serviço:

• O dispositivo deve estar online para ser elegível para autorização de alteração de chave de criptografia de dados de serviço.
• Você pode autorizar o mesmo dispositivo novamente após 30 minutos se a alteração de chave não tiver 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 rolado 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

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

Nota

Nenhuma operação pode ser executada no portal do Azure do seu serviço StorSimple Manager até que a substituição de chave seja 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 total.

2. Na linha de comandos, escreva:

   Invoke-HcsmServiceDataEncryptionKeyChange

3. Depois que o cmdlet for concluído com êxito, você receberá uma nova chave de criptografia de dados de serviço. Copie e guarde esta chave para utilização no passo 3 deste processo. Essa chave será usada para atualizar todos os dispositivos restantes registrados no serviço StorSimple Manager.

   Nota

   Esse processo deve ser iniciado dentro de quatro horas após a autorização de um dispositivo StorSimple.

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

   Se tiver um único dispositivo registado no seu serviço, o processo de substituição está concluído e pode ignorar o passo seguinte. Se tiver vários dispositivos registados no seu serviço, avance para o passo 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 do seu dispositivo StorSimple se você tiver vários dispositivos registrados no serviço StorSimple Manager. A chave obtida na Etapa 2 deve ser usada para atualizar todo o dispositivo StorSimple restante registrado no serviço StorSimple Manager.

Execute as etapas a seguir para atualizar a criptografia de dados de serviço em 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 total.
2. Na linha de comandos, escreva: Invoke-HcsmServiceDataEncryptionKeyChange – ServiceDataEncryptionKey
3. Forneça a chave de criptografia de dados de serviço obtida 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 configure 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 a chave de criptografia de dados de serviço seja definida em todos os dispositivos de nuvem 8010/8020 no gerenciador de dispositivos.

Atenção

Ao decidir como se conectar ao seu dispositivo StorSimple, considere o seguinte:

• Conectar-se através de uma sessão HTTPS é a opção mais segura e recomendada.
• A ligação direta à consola série do dispositivo é segura, mas a ligação à consola série através de comutadores de rede não é.
• As conexões de sessão HTTP são uma opção, mas não são criptografadas. Eles não são recomendados, a menos que sejam usados em uma rede fechada e confiável.

Limitações conhecidas

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

• Somente volumes NTFS do dispositivo StorSimple são suportados. Não há suporte para volumes ReFS.
• Não há suporte para qualquer volume colocado em Discos Dinâmicos do Windows Server.
• O serviço não funciona com volumes criptografados pelo BitLocker ou com a Desduplicação de Dados habilitada .
• Os backups corrompidos do StorSimple não podem ser migrados.
• Opções 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 onde os backups do StorSimple são armazenados, nem na conta de armazenamento de destino que contém seus compartilhamentos de arquivos do Azure.

Fidelidade de ficheiros

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

A fidelidade de arquivo refere-se à infinidade de atributos, carimbos de data/hora e dados que compõem um arquivo. Em uma migração, a fidelidade de arquivo é uma medida de quão bem as informações na origem (volume StorSimple) podem ser traduzidas (migradas) para o compartilhamento de arquivos do Azure de destino.

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

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

• Carimbos de data/hora: A hora de alteração do arquivo não será definida. Atualmente, é somente leitura sobre o protocolo REST. O carimbo de data/hora do último acesso em um arquivo não será movido, pois não é um atributo com suporte em arquivos armazenados em um compartilhamento de arquivos do Azure.
• Fluxos de Dados Alternativos não podem ser armazenados em compartilhamentos de arquivos do Azure. Os arquivos que contêm Fluxos de Dados Alternativos serão copiados, mas os Fluxos de Dados Alternativos serão removidos do arquivo no processo.
• Links simbólicos, links físicos, junções e pontos de reparo são ignorados durante uma migração. Os logs de cópia de migração listam cada item ignorado e um motivo.
• Os ficheiros encriptados EFS não conseguem copiar. Os logs de cópia mostram que o item falhou ao copiar com "Acesso negado".
• Arquivos corrompidos são ignorados. Os logs de cópia podem listar erros diferentes para cada item corrompido no disco 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 lista de controle de acesso (ACL) é inválida".
• Arquivos individuais maiores que 4 TiB são ignorados.
• Os comprimentos do caminho do arquivo devem ser iguais ou inferiores a 2048 caracteres. Arquivos e pastas com caminhos mais longos são ignorados.
• Os pontos de análise são ignorados. Quaisquer pontos de análise do Microsoft Data Deduplication / SIS ou de terceiros não podem ser resolvidos pelo mecanismo de migração e impedirão uma 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 de nível de item e de trabalho de migração e, quando possível, suas opções de mitigação.

Backups de volume StorSimple

O StorSimple oferece backups diferenciais no nível de volume. Os compartilhamentos de arquivos do Azure também têm essa capacidade, chamados 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 em tempo real e, portanto, deve sempre fazer parte da lista de backups a serem movidos em uma migração.

Decida se você precisa mover backups mais antigos durante a migração. É uma prática recomendada manter essa lista o menor possível para que seus trabalhos de migração sejam concluídos mais rapidamente.

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

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

Ao criar seus trabalhos de migração, você pode usar essa lista para identificar os backups de volume StorSimple exatos que devem ser migrados para atender às suas necessidades.

É 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 backups pode levar vários dias ou semanas. O StorSimple oferece políticas de retenção de backup que excluem backups. Os backups selecionados para essa migração podem ser excluídos antes de terem a chance de serem migrados.

Atenção

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

Mapeie seus volumes existentes do StorSimple para compartilhamentos de arquivos do Azure

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

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

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

Agrupamento de compartilhamentos

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

Sincronização de volume

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

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

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

Gorjeta

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

Uma abordagem estruturada para um mapa de implantação

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

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

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

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

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

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

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

Gorjeta

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

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

Importante

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

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

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

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

#	Cenário de sincronização	Suportado	Considerações (ou limitações)	Solução (ou solução alternativa)
1	Servidor de ficheiros com vários discos/volumes e várias partilhas para o mesmo compartilhamento de arquivos do Azure de destino (consolidação)	Não	Um compartilhamento de arquivos do Azure de destino (ponto de extremidade na nuvem) só dá suporte à sincronização com um grupo de sincronização. Um grupo de sincronização suporta apenas um ponto de extremidade de servidor por servidor registrado.	1) Comece com a sincronização de um disco (seu volume raiz) para o compartilhamento de arquivos do Azure de destino. Começar com o maior disco/volume ajudará com os requisitos de armazenamento no local. Configure a hierarquização da nuvem para hierarquizar todos os dados na nuvem, liberando espaço no disco do servidor de arquivos. Mova dados de outros volumes/compartilhamentos para o volume atual que está sincronizando. Continue as etapas, uma a uma, até que todos os dados sejam hierarquizados para a nuvem/migrados. 2) Segmente um volume raiz (disco) de cada vez. Use a hierarquização na nuvem para hierarquizar todos os dados para o compartilhamento de arquivos do Azure de destino. Remova o ponto de extremidade do servidor do grupo de sincronização, recrie o ponto de extremidade com o próximo volume/disco raiz, sincronize e repita o processo. Nota: A reinstalação do agente pode ser necessária. 3) Recomende o uso de vários compartilhamentos de arquivos do Azure de destino (conta de armazenamento igual ou diferente com base nos requisitos de desempenho)
2	Servidor de ficheiros com volume único e várias partilhas para o mesmo compartilhamento de arquivos do Azure de destino (consolidação)	Sim	Não é possível ter vários pontos de extremidade de servidor por servidor registrado sincronizando com o mesmo compartilhamento de arquivos do Azure de destino (o mesmo que acima)	Sincronize a raiz do volume que contém vários compartilhamentos ou pastas de nível superior. Consulte Conceito de agrupamento de compartilhamento e Sincronização de volume para obter mais informações.
3	Servidor de ficheiros com várias partilhas e/ou volumes para várias partilhas de ficheiros do Azure numa única conta de armazenamento (mapeamento de partilha 1:1)	Sim	Uma única instância (ou cluster) do Windows Server pode sincronizar até 30 compartilhamentos de arquivos do Azure. Uma conta de armazenamento é um destino de escala para desempenho. IOPS e taxa de transferência são compartilhadas entre compartilhamentos de arquivos. Mantenha o número de itens por grupo de sincronização dentro de 100 milhões de itens (arquivos e pastas) por compartilhamento. O ideal é ficar abaixo de 20 ou 30 milhões por ação.	1) Use vários grupos de sincronização (número de grupos de sincronização = número de compartilhamentos de arquivos do Azure para sincronizar). 2) Apenas 30 compartilhamentos podem ser sincronizados neste cenário de cada vez. Se você tiver mais de 30 compartilhamentos nesse servidor de arquivos, use o conceito de agrupamento de compartilhamento e a sincronização de volume para reduzir o número de pastas raiz ou de nível superior na origem. 3) Use servidores de sincronização de arquivos adicionais no local e divida / mova dados para esses servidores para contornar as limitações no servidor Windows de origem.
4	Servidor de arquivos com vários compartilhamentos e/ou volumes para vários compartilhamentos de arquivos do Azure em conta de armazenamento diferente (mapeamento de compartilhamento 1:1)	Sim	Uma única instância (ou cluster) do Windows Server pode sincronizar até 30 compartilhamentos de arquivos do Azure (conta de armazenamento igual ou diferente). Mantenha o número de itens por grupo de sincronização dentro de 100 milhões de itens (arquivos e pastas) por compartilhamento. O ideal é ficar abaixo de 20 ou 30 milhões por ação.	Mesma abordagem que acima
5	Vários servidores de arquivos com um único (volume raiz ou compartilhamento) para o mesmo compartilhamento de arquivos do Azure de destino (consolidação)	Não	Um grupo de sincronização não pode usar o ponto de extremidade de nuvem (compartilhamento de arquivos do Azure) já configurado em outro grupo de sincronização. Embora um grupo de sincronização possa ter pontos de extremidade de servidor em servidores de arquivos diferentes, os arquivos não podem ser distintos.	Siga as orientações no Cenário # 1 acima com consideração adicional de segmentar um servidor de arquivos de cada vez.

Criar uma tabela de mapeamento

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

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

Baixe um modelo de mapeamento de namespace.

Número de contas de armazenamento

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

Se seus compartilhamentos de arquivos estiverem altamente ativos (utilizados por muitos usuários ou aplicativos), dois compartilhamentos de arquivos do Azure poderão atingir o limite de desempenho da sua conta de armazenamento. Por isso, geralmente é melhor 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 à Sincronização de Arquivos do Azure. Se você planeja usar exclusivamente o Azure File Sync nesses compartilhamentos, agrupar vários em uma única conta de armazenamento do Azure é bom. No futuro, você pode querer elevar e mudar um aplicativo para a nuvem que, em seguida, acessaria diretamente um compartilhamento de arquivos, pois esse cenário se beneficiaria de ter IOPS e taxa de transferência mais altas. Ou você pode começar a usar um serviço no Azure que também se beneficiaria de ter IOPS e taxa de transferência mais altas.

Depois de fazer uma lista de seus compartilhamentos, mapeie cada compartilhamento para a conta de armazenamento onde residirá. Decida sobre uma região do Azure e verifique se cada conta de armazenamento e recurso do Azure File Sync 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 momento tornaria uma migração impossível. Configure essas configurações de armazenamento do Azure após a conclusão da migração.

Definiçõ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 de rede após a conclusão da migração.

• Compartilhamentos de arquivos grandes: habilitados - Compartilhamentos de arquivos grandes melhoram o desempenho e permitem armazenar até 100 TiB em um compartilhamento. Essa configuração se aplica a contas de armazenamento de destino com compartilhamentos de arquivos do Azure.
• Firewall e redes virtuais: Desativado - não configure nenhuma restrição de IP ou limite o acesso da 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 das VMs do Azure devem ser permitidos. É melhor configurar quaisquer 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: suportados - Você pode habilitar pontos de extremidade privados, mas o ponto de extremidade público é usado para a migração e deve permanecer disponível. Isso se aplica às suas 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 StorSimple.
• O serviço Gerenciador de Dados está pronto para acessar seus volumes 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, além dos mais recentes) precisam ser migrados.
• Você sabe como mapear seus volumes para o número apropriado de compartilhamentos de arquivos e contas de armazenamento do Azure.

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

Esta seção discute considerações sobre a implantação dos diferentes tipos de recursos necessários no Azure. Alguns manterão seus dados após a migração, e alguns são necessários exclusivamente para a migração. Não comece a implantar recursos até finalizar seu plano de implantação. É difícil, às vezes impossível, alterar certos aspetos dos recursos do Azure depois que eles forem implantados.

Este vídeo aborda a implantação de:

• Contas de armazenamento
• Assinatura(s) e grupos de recursos
• Contas de armazenamento
• Tipos e nome(s)
• Desempenho e tamanho do compartilhamento
• Localização e tipos de replicação
• Compartilhamentos de arquivos do Azure
• Serviço StorSimple Data Manager

Implantar contas de armazenamento

Você provavelmente precisará implantar várias contas de armazenamento do Azure. Cada um 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 aderir às seguintes configurações básicas para qualquer nova conta 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 impossível uma migração. Configure essas configurações de armazenamento do Azure após a conclusão da migração.

Subscrição

Você pode usar a mesma assinatura usada para sua implantação do StorSimple ou pode usar 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 os 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 administrador. Mais informações.

Nome da conta de armazenamento

O nome da sua conta de armazenamento passará a fazer parte de um URL utilizado para aceder à partilha de ficheiros e tem determinadas limitações de caracteres. Na convenção de nomenclatura, considere que os nomes das contas 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 hífenes ou sublinhados. Consulte Regras de nomenclatura de recursos de armazenamento do Azure.

Localização

A região do Azure de uma conta de armazenamento é importante. Se você usar o Azure File Sync, 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 escolhida deve estar próxima ou central para seus servidores e usuários locais. Depois de implantar seu recurso, não é possível alterar sua região.

Você pode escolher uma região diferente de onde seus dados StorSimple (conta de armazenamento) residem atualmente, no entanto, se o fizer, serão aplicadas taxas de saída durante a migração. Os dados sairão da região StorSimple e entrarão na nova região da conta de armazenamento. Não se aplicam taxas de largura de banda se você permanecer na mesma região do Azure.

Desempenho

Você tem a opção de escolher armazenamento premium (SSD) para compartilhamentos de arquivos do Azure ou armazenamento padrão. O armazenamento padrão inclui vários níveis para um compartilhamento de arquivos. O armazenamento padrão é a opção certa para a maioria dos clientes que migram do StorSimple.

• Escolha o armazenamento premium se 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 ativos e dados de arquivamento. 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 apenas entre as duas opções seguintes:

• Armazenamento localmente redundante (LRS).
• Armazenamento redundante de zona (ZRS), que não está disponível em todas as regiões do Azure.

Nota

O armazenamento com redundância geográfica (GRS) e o armazenamento redundante por zona geográfica não são suportados.

Habilitar compartilhamentos de arquivos de capacidade de 100 TiB

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

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

• O desempenho é muito maior em comparação com os compartilhamentos de arquivos menores de 5 TiB (por exemplo, 10 vezes o IOPS).
• Sua migração será concluída mais rapidamente.
• Você garante que um compartilhamento de arquivos tenha capacidade suficiente para armazenar todos os dados que migrará para ele, incluindo a capacidade de armazenamento exigida pelos backups diferenciais.
• O crescimento futuro está coberto.

Importante

Não aplique redes especiais à sua 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 limitação a intervalos de IP específicos ou redes virtuais. Você pode alterar as configurações de rede da conta de armazenamento após a migração.

Compartilhamentos de arquivos do Azure

Depois de criar suas contas de armazenamento, vá para a seção Compartilhamento de arquivos da(s) conta(s) 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 aderir às seguintes configurações básicas para seus novos compartilhamentos de arquivos no Azure.

Nome
Há suporte para

letras minúsculas, números e hífenes.A
cota aqui é comparável a uma cota rígida SMB em uma instância do Windows Server. A prática recomendada é não definir uma cota aqui porque sua migração e outros serviços falharão quando a cota for atingida.

Camadas
Selecione Transação otimizada para seu novo compartilhamento de arquivos. Durante a migração, muitas transações ocorrerão. É mais econômico alterar seu nível posteriormente para o nível mais adequado à sua carga de trabalho.

StorSimple Data Manager

O recurso do Azure que contém seus trabalhos de migração é chamado StorSimple Data Manager. Selecione Novo recurso e pesquise-o. Depois, selecione Criar.

Este recurso temporário é usado para orquestração. Você pode desprovisioná-lo 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 StorSimple.

Azure File Sync

Com a Sincronização de Arquivos do Azure, você pode adicionar cache local dos arquivos acessados com mais frequência. Semelhante às capacidades de cache do StorSimple, o recurso de hierarquização na nuvem do Azure File Sync oferece latência de acesso local em combinação com controle aprimorado sobre a capacidade de cache disponível na instância do Windows Server e sincronização multissite. Se o seu objetivo for ter um cache local, prepare uma VM do Windows Server (servidores físicos e clusters de failover também são suportados) com capacidade de armazenamento de conexão direta suficiente.

Importante

Ainda não configure o Azure File Sync. A implantação do Azure File Sync não deve começar antes da Fase 4 de uma migração.

Resumo da fase 2

No final da Fase 2, você terá implantado suas contas de armazenamento e todos os compartilhamentos de arquivos do Azure entre elas. Você também terá um recurso StorSimple Data Manager. Você usará este último na Fase 3 ao 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 StorSimple que devem ser copiados para o compartilhamento de arquivos do Azure de destino selecionado.

Este vídeo aborda o seguinte:

• Criando um trabalho de migração
• Resumo
• Source
• Seleção de backups de volume para migrar
• Destino
• Mapeamento de diretórios
• Regras semânticas
• Executando um trabalho de migração
• Executar definição de trabalho
• Visualizando o estado do trabalho
• Executando trabalhos em paralelo
• Interpretando os arquivos de log

Para começar, vá para o StorSimple Data Manager, encontre Definições de trabalho no menu e selecione + Definição de tarefa. O tipo de armazenamento de destino correto é o padrão: compartilhamento de arquivos do Azure.

Nome da definição
de trabalho Este nome deve indicar o conjunto de arquivos que você está movendo. Dar a ele um nome semelhante ao seu compartilhamento de arquivos do Azure é uma boa prática.

Local onde o trabalho é executado
Ao selecionar uma região, você deve selecionar a mesma região da sua conta de armazenamento StorSimple ou, se ela não estiver disponível, uma região próxima a ela.

Source

Assinatura
de origem Selecione a assinatura na qual você armazena o recurso StorSimple Device Manager.

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

Chave
de criptografia de dados de serviço Verifique esta seção anterior neste artigo caso não consiga localizar a chave em seus registros.

Dispositivo
Selecione o dispositivo StorSimple que contém o volume para o qual você deseja migrar.

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

Backups
de volume Você pode selecionar Selecionar backups de volume para escolher backups específicos para mover como parte deste trabalho. Uma próxima seção dedicada neste artigo aborda o processo em detalhes.

Destino

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

Mapeamento de diretórios

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

Seleção de backups de volume para migrar

Há aspetos importantes na escolha de backups que precisam ser migrados:

• Seus trabalhos de migração só podem mover backups, não dados de volume em tempo real. Portanto, o backup mais recente está mais próximo dos dados em tempo real e deve estar sempre na lista de backups movidos em uma migração. Quando você abre a caixa de diálogo Seleção de backup, ela é selecionada por padrão.
• Certifique-se de que seu backup mais recente seja recente para manter o delta para o compartilhamento ao vivo o menor possível. Pode valer a pena acionar manualmente e concluir outro backup de volume antes de criar um trabalho de migração. Um pequeno delta para o compartilhamento ao vivo melhora sua experiência de migração. Se esse delta puder ser zero, o que significa que não houve mais alterações no volume StorSimple depois que o backup mais recente foi feito em sua lista, o corte de usuário será drasticamente simplificado e acelerado.
• 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 arquivos do Azure depois de executar um trabalho de migração. Portanto, você deve garantir que sua lista de backups esteja completa 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 StorSimple que você deseja migrar deve estar online.

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

Quando a folha de seleção de backup é aberta, ela é separada em duas listas. Na primeira lista, todos os backups disponíveis são exibidos. Você pode expandir e restringir o conjunto de resultados filtrando para um intervalo de tempo específico. (ver secção seguinte)

Um backup selecionado será exibido como acinzentado e será adicionado a uma segunda lista na metade inferior da lâmina. A segunda lista exibe todos os backups selecionados para migração. Um backup selecionado por erro também pode ser removido novamente.

Atenção

Você deve selecionar todos os backups que deseja migrar. Não é possível adicionar backups mais antigos posteriormente. Não é possível modificar o trabalho para alterar sua seleção depois que ele for 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 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 a partir de um filtro existente ou definir um intervalo de tempo personalizado para filtrar apenas os backups feitos durante esse período.

Atenção

Não há suporte para a seleção de mais de 50 backups de volume StorSimple. Trabalhos com um grande número de backups podem falhar. Certifique-se de que suas políticas de retenção de backup não excluam um backup selecionado antes que ele tenha a chance de ser migrado!

Mapeamento de diretórios

O mapeamento de diretórios é opcional para seu trabalho de migração. Se você deixar a seção vazia, todos os arquivos e pastas na raiz do volume StorSimple serão movidos para a raiz do compartilhamento de arquivos do Azure de destino. 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 tiver feito um plano, consulte Mapear seu volume StorSimple para compartilhamentos de arquivos do Azure primeiro.

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

1. Definição de vários trabalhos para migrar as pastas em um volume. Cada um terá a mesma origem de volume StorSimple, mas um compartilhamento de arquivos do Azure diferente como destino.
2. Especificar precisamente quais pastas do volume StorSimple precisam ser migradas para o compartilhamento de arquivos especificado usando a seção Directory-mapping do formulário de criação de trabalho e seguindo a semântica de mapeamento específica.

Importante

Os caminhos e expressões de mapeamento neste formulário não podem ser validados quando o formulário é 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 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 fixas pode corrigir pastas omitidas e trazê-las para o compartilhamento existente. No entanto, apenas as pastas que foram omitidas devido a erros ortográficos de caminho podem ser resolvidas desta forma.

Elementos semânticos

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

Caráter semântico	Significado
\	Indicador de nível de raiz.
>	Operador [Source] e [target-mapping].
| ou RETURN (nova linha)	Separador de duas instruções de mapeamento de pastas. Como alternativa, você pode omitir esse caractere e selecionar Enter para obter a próxima expressão de mapeamento em sua própria linha.

Exemplos

Move o conteúdo da pasta Dados do usuário 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órios:

\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 caminhos de pasta relativos ao nível raiz.
• Comece cada caminho de pasta com um indicador de nível raiz "\".
• Não inclua letras de 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:
  \folder\1 > \folder
  \folder\1\2 > \folder2
  Exemplo de sobreposição de caminho de destino inválido:
  \folder > \
  \folder2 \>
  
• 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 preservam maiúsculas e minúsculas.

Nota

O conteúdo da pasta \System Volume Information e do $Recycle.Bin no volume StorSimple não será copiado pelo trabalho de migração.

Executar um trabalho de migração

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

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

Inicialmente, o trabalho de migração terá o status: Nunca executado.
Quando estiver pronto, inicie o trabalho de migração. Selecione a imagem para uma versão com maior resolução.
Quando um backup é migrado com êxito, um instantâneo automático de compartilhamento de arquivos do Azure será tirado. A data de backup original do backup do StorSimple é colocada na seção Comentários do instantâneo de compartilhamento de arquivos do Azure. A utilização deste campo permite que você veja quando os dados foram originalmente copiados em comparação com o tempo em que o instantâneo de compartilhamento de arquivos foi tirado.

Atenção

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 suas agendas de retenção. Os backups podem ser excluídos por uma ou mais de suas políticas de retenção antes 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 quaisquer problemas que possam ter ocorrido durante a cópia:

• Erros
  de cópia Esta coluna lista arquivos ou pastas que deveriam ter sido copiados, mas não foram. Estes erros são frequentemente recuperáveis. Quando um backup listar problemas de item nesta coluna, revise os logs de cópia. Se precisar migrar esses arquivos, selecione Repetir backup. Essa opção fica disponível assim que o backup terminar o processamento. A seção Gerenciando um trabalho de migração explica suas opções com mais detalhes.
• Arquivos sem suporte
  Esta coluna lista os arquivos ou pastas que não podem ser migrados. O Armazenamento do Azure tem 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 itens nesta coluna, revise os logs de cópia e tome nota. Se esses problemas surgirem em seu último backup e você descobrir no log de cópia que a falha foi devido a um nome de arquivo, comprimento de caminho ou outro problema sobre o qual você tenha influência, convém corrigir o problema no volume StorSimple ativo, fazer um backup de volume StorSimple e criar um novo trabalho de migração apenas com esse backup. Em seguida, você pode migrar esse namespace corrigido e ele se tornará a versão mais recente/ao vivo do compartilhamento de arquivos do Azure. Este é um processo manual e demorado. Revise os logs de cópia cuidadosamente e avalie se vale a pena.

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

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

Gerenciar um trabalho de migração

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

• Nunca executou
  Um novo trabalho que foi definido, mas nunca executado.
• Aguardando
  Um trabalho nesse estado está aguardando o provisionamento de recursos no serviço de migração. Ele mudará automaticamente para um estado diferente quando estiver pronto.
• Falha
  Um trabalho com falha atingiu um erro fatal que o impede de processar mais backups. Não se espera que um emprego entre neste estado. Um pedido de apoio é o melhor curso de ação.
• Cancelamento Cancelado /
  E todo o trabalho de migração ou backups individuais dentro do trabalho podem ser cancelados. Os backups cancelados não serão processados, pois um trabalho de migração cancelado interromperá o processamento de backups. Espere que cancelar um trabalho demore muito tempo. Isso não impede que você crie um novo emprego. O melhor curso de ação é deixar um trabalho chegar totalmente no estado Cancelado . Você pode ignorar trabalhos com falha/cancelados ou excluí-los mais tarde. Você não precisará excluir trabalhos antes de poder excluir o recurso do Gerenciador de Dados no final da migração do StorSimple.

Executando

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

Pausado

Um trabalho de migração é pausado quando há uma decisão necessária. Essa condição habilita dois botões de comando na parte superior da folha:
Escolha Repetir backup quando o backup mostrar arquivos que deveriam ser movidos, mas não foram movidos (coluna de erro Copiar).
Escolha Ignorar backup 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 detalhadas de erro na folha que é aberta quando você clica no backup com falha.

Quando você ignora ou tenta novamente o backup atual, o serviço de migração criará um novo instantâneo em seu compartilhamento de arquivos do Azure de destino. Talvez você queira excluir o anterior mais tarde, pois ele provavelmente está incompleto.

Concluir e Concluir com avisos

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

• Um backup teve um problema recuperável. Esse backup é marcado como êxito parcial ou falha.
• Você decidiu continuar no trabalho pausado 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 deve revisar o log de cópia para os backups relevantes.

Executar trabalhos em paralelo

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

Não há limites na definição de trabalhos de migração. Você pode definir o mesmo volume de origem do StorSimple, o mesmo compartilhamento de arquivos do Azure, entre os mesmos ou diferentes dispositivos StorSimple. No entanto, executá-los tem limitações:

• Apenas um trabalho de migração com o mesmo volume de origem StorSimple pode ser executado ao mesmo tempo.
• Apenas 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, certifique-se de que qualquer um dos trabalhos anteriores esteja no e mostre o copy stage 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 StorSimple, desde que 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 não seja possível iniciar um novo trabalho. Você receberá um alerta que lista o nome do(s) trabalho(s) em execução no momento que deve ser concluído antes de poder iniciar o novo trabalho.

Gorjeta

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

Resumo da fase 3

No final da Fase 3, você terá executado pelo menos um dos seus trabalhos de migração dos volumes StorSimple para o(s) compartilhamento(s) de arquivos do Azure. Com sua execução, você terá migrado seus backups especificados para instantâneos de compartilhamento de arquivos do Azure. Agora você pode se concentrar na configuração do Azure File Sync para o compartilhamento (assim que os trabalhos de migração para um compartilhamento forem concluídos) ou no acesso direto de compartilhamento para seus operadores 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:

• Azure File Sync: implante o Azure File Sync em uma instância local do Windows Server. O Azure File Sync tem todas as vantagens de um cache local, assim como o StorSimple.
• Direct-share-access: implante o direct-share-access. Use essa estratégia se seu cenário de acesso para um determinado compartilhamento de arquivos do Azure não se beneficiar do cache local ou se você não tiver mais a capacidade de hospedar uma instância local do Windows Server. Aqui, os seus utilizadores e aplicações continuarão a aceder a partilhas SMB através do 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 em instruções de implantação.

Este vídeo aborda o seguinte:

• Abordagens para acessar compartilhamentos de arquivos do Azure
• Azure File Sync
• Acesso direto ao compartilhamento
• Implantando o Azure File Sync
• Implantar o recurso de nuvem do Azure File Sync
• Implantar uma instância local do Windows Server
• Preparando a instância do Windows Server para o Azure File Sync
• Configurando a Sincronização de Arquivos do Azure na instância do Windows Server
• Monitorando a sincronização inicial
• Testando o Azure File Sync
• Criando os compartilhamentos SMB

Implementar o Azure File Sync

É hora de implantar uma parte do Azure File Sync.

1. Crie o recurso de nuvem do Azure File Sync.
2. Implante o agente do Azure File Sync em seu servidor local.
3. Registre o servidor com o recurso de nuvem.

Não crie nenhum grupo de sincronização ainda. A configuração da sincronização com um compartilhamento de arquivos do Azure só deve ocorrer após a conclusão dos trabalhos de migração para um compartilhamento de arquivos do Azure. Se você começar a usar a Sincronização de Arquivos do Azure antes da conclusão da migração, isso dificultará desnecessariamente a migração, pois você não poderá saber facilmente quando foi a hora de iniciar uma transferência.

Implantar o recurso de nuvem do Azure File Sync

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

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

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

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

Gorjeta

Se você quiser alterar a região do Azure em que seus dados residem após a conclusão da migração, implante o Serviço de 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

• Crie o Windows Server 2019 (no mínimo 2012R2) como uma máquina virtual ou servidor físico. Um cluster de failover do Windows Server também é suportado. Não reutilize o servidor que está à frente do StorSimple 8100 ou 8600.
• Provisione ou adicione armazenamento com conexão direta. Não há suporte para armazenamento conectado à rede.

É uma prática recomendada dar à nova instância do Windows Server uma quantidade de armazenamento igual ou maior do que a do dispositivo StorSimple 8100 ou 8600 disponível localmente para cache. Você usará a instância do Windows Server da mesma forma que usou o dispositivo StorSimple. Se ele tiver a mesma quantidade de armazenamento que o dispositivo, a experiência de cache deve ser semelhante, se não a mesma. Você pode adicionar ou remover armazenamento da instância do Windows Server à vontade. Esse recurso permite dimensionar 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ê instala o agente do Azure File Sync em sua instância do Windows Server.

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

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

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

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

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

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

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

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

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

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

Configurar a Sincronização de Arquivos do Azure na instância do Windows Server

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

Importante

Sua migração StorSimple de arquivos e pastas para o compartilhamento de arquivos do Azure deve ser concluída antes de prosseguir. Certifique-se de que não há mais alterações feitas no compartilhamento de arquivos.

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

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

Importante

Certifique-se de ativar a hierarquização na nuvem. A hierarquização na nuvem é o recurso de Sincronização de Arquivos do Azure que permite que o servidor local tenha menos capacidade de armazenamento do que a armazenada na nuvem, mas tenha o namespace completo disponível. Dados localmente interessantes também são armazenados em cache localmente para um desempenho rápido. Outro motivo para ativar a hierarquização na nuvem nesta etapa é que não queremos sincronizar o conteúdo do arquivo neste estágio. Somente o namespace deve estar se movendo neste momento.

Implantar acesso direto ao compartilhamento

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

• Visão geral da identidade
• Como ingressar em uma conta de armazenamento no domínio
• 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 do Windows
• Como configurar uma VPN Linux P2S
• Como configurar o encaminhamento DNS
• Configurar o DFS-N

Resumo da fase 4

No final desta fase, você criou e executou vários trabalhos de migração no StorSimple Data Manager. Esses trabalhos migraram seus arquivos e pastas e seus backups para compartilhamentos de arquivos do Azure. Você também implantou o Azure File Sync ou preparou suas contas de rede e armazenamento para acesso direto de compartilhamento.

Fase 5: Transferência de utilizadores

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

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

Este vídeo aborda o seguinte:

• Etapas a serem seguidas antes da redução da carga de trabalho
• Executar o seu cut-over
• Pós-etapas de corte

Planeje seu tempo de inatividade

Essa abordagem de migração requer algum tempo de inatividade para seus usuários e aplicativos. O objetivo é reduzir ao mínimo o tempo de inatividade. As seguintes considerações podem ajudar:

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

Para dados de arquivamento, é uma abordagem totalmente viável reduzir o tempo de inatividade do volume (ou subpasta) do StorSimple, fazer mais um backup de volume do StorSimple, migrar e abrir o destino da migração para acesso de usuários e aplicativos. Isto irá poupar-lhe a necessidade de um RoboCopy de recuperação. No entanto, essa abordagem tem o custo de uma janela de tempo de inatividade prolongada que pode se estender por 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 podem dispensar acesso de gravação por longos períodos de tempo.

Determinar quando o namespace foi totalmente sincronizado com o servidor

Quando você usa a Sincronização de Arquivos do Azure para um compartilhamento de arquivos do Azure, é importante determinar se todo o seu namespace terminou de baixar para o servidor antes de iniciar qualquer 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 seu namespace chegou totalmente ao servidor.

Portal do Azure

Você pode usar o portal do Azure para ver quando seu namespace chegou totalmente.

• Entre no portal do Azure e vá para seu grupo de sincronização. Verifique o status de sincronização do grupo de sincronização e do ponto de extremidade do servidor.
• A direção interessante é o download. Se o ponto de extremidade do servidor for recém-provisionado, ele mostrará Sincronização inicial, o que indica que o namespace ainda está descendo. Depois que esse estado for alterado para qualquer coisa, exceto Sincronização inicial, seu 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 chegou totalmente.

1. Abra o Visualizador de Eventos e vá para Aplicativos e Serviços.
2. Vá para Microsoft\FileSync\Agent\Telemetry e abra-o.
3. Procure o evento mais recente 9102, que corresponde a uma sessão de sincronização concluída.
4. Selecione Detalhes e confirme que está a ver um evento em que o valor SyncDirection é Download.
5. Durante o tempo em que o download do namespace for concluído para o servidor, haverá um único evento com Scenario, o valor FullGhostedSync e HResult = 0.
6. Se você perder esse evento, você também pode procurar outros eventos 9102 com SyncDirection = Download e Scenario = "RegularSync". Encontrar um desses eventos também indica que o namespace terminou de baixar e a sincronização progrediu para sessões de sincronização regulares, independentemente de haver algo para sincronizar ou não no momento.

Um RoboCopy final

Neste ponto, há diferenças entre sua instância local do Windows Server e o dispositivo 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 StorSimple tem um cache preenchido versus a instância do Windows Server com apenas um namespace sem conteúdo de arquivo armazenado localmente no momento. O RoboCopy final pode ajudar a iniciar o cache local do Azure File Sync extraindo o conteúdo do arquivo armazenado em cache localmente tanto quanto estiver disponível e puder caber no servidor de 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. Em caso afirmativo, copie-os para a instância do Windows Server habilitada para Sincronização de Arquivos do Azure. Mais tarde, você pode ajustá-los para que eles sejam sincronizados. Se você não usar o Azure File Sync para um compartilhamento específico, é melhor renomear os arquivos com caracteres inválidos no volume StorSimple. Em seguida, execute o RoboCopy diretamente no compartilhamento de arquivos do Azure.

Aviso

O Robocopy no Windows Server 2019 teve um problema que fez com que os arquivos hierarquizados pela Sincronização de Arquivos do Azure no servidor de destino fossem recopiados da origem e recarregados no Azure ao usar a /MIR função. Recomendamos executar o Robocopy em um Windows Server diferente de 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 completamente. Para obter mais informações, consulte Determinar quando o namespace foi totalmente baixado para o servidor.

Você só deseja copiar arquivos que foram alterados após a última execução do trabalho de migração e arquivos que não foram movidos por esses trabalhos antes. Você pode resolver o problema sobre por que eles não foram movidos mais tarde no servidor, depois que a migração for concluída. Para obter mais informações, consulte Solução de problemas do Azure File Sync.

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

Importante

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

Ao configurar os locais de origem e destino do comando RoboCopy, certifique-se de revisar a estrutura da origem e do destino para garantir que eles correspondam. Se você usou o recurso de mapeamento de diretório do trabalho de migração, sua estrutura de diretório raiz pode ser diferente da estrutura do volume StorSimple. Se esse for o caso, você pode precisar de vários trabalhos do RoboCopy, um para cada subdiretório. Se você não tiver certeza se o comando terá o desempenho esperado, você pode usar o parâmetro /L , que simulará o comando sem realmente fazer alterações.

Este comando RoboCopy usa /MIRo , portanto, ele não moverá arquivos iguais (arquivos em camadas, por exemplo). Mas se você errar o caminho de origem e de destino, /MIR também limpe as estruturas de diretório na instância do Windows Server ou no compartilhamento de arquivos do Azure que não estão presentes no caminho de origem do StorSimple. Eles devem corresponder exatamente para que o trabalho do RoboCopy atinja o objetivo pretendido de atualizar o conteúdo migrado com as alterações mais recentes feitas enquanto a migração está em andamento.

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

Se você não usar o Azure File Sync para armazenar em cache o compartilhamento de arquivos específico do Azure em questão, mas optou pelo acesso direto ao compartilhamento:

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

Solucionar problemas e otimizar

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

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

Considerações sobre IOPS e largura de banda

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

Atenção

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

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

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

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

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

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

Velocidade de processamento

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

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

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

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

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

Gorjeta

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

Evite trabalho desnecessário

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

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

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

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

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

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

Windows Server 2022 e RoboCopy LFSM

A opção /LFSM RoboCopy pode ser usada para evitar que um trabalho RoboCopy falhe com um erro de volume cheio . O RoboCopy pausará sempre que uma cópia de arquivo fizer com que o espaço livre do volume de destino fique abaixo de um valor "chão".

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

/B executa o RoboCopy no mesmo modo que um aplicativo de backup usaria. 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 na Origem, no Destino ou em uma terceira máquina.

Importante

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

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

Atenção

A versão atualmente disponível do RoboCopy no Windows Server 2022 tem um bug que faz com que as pausas contem em relação à contagem de erros por arquivo. Aplique a seguinte solução alternativa.

Os sinalizadores recomendados /R:2 /W:1 aumentam a probabilidade de um arquivo falhar devido a uma /LFSM pausa induzida. Neste exemplo, um arquivo que não foi copiado após 3 pausas porque /LFSM causou a pausa, fará com que o RoboCopy falhe incorretamente no arquivo. 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). Isso deve dar ao algoritmo de hierarquização do Azure File Sync tempo para criar espaço no volume de destino.

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

Transferência de utilizadores

Se você usar a Sincronização de Arquivos do Azure, provavelmente precisará criar os compartilhamentos SMB nessa instância do Windows Server habilitada para Sincronização de Arquivos do Azure que correspondam aos compartilhamentos que você tinha nos volumes StorSimple. Você pode pré-carregar esta etapa e fazê-lo 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 tiver uma implementação DFS-N, pode apontar os DFN-Namespaces para as novas localizações de pastas do servidor. Se você não tiver uma implantação do DFS-N e tiver frontado seu dispositivo 8100 ou 8600 localmente com uma instância do Windows Server, poderá retirar esse servidor do domínio. Em seguida, ingresse no domínio de sua nova instância do Windows Server habilitada para Sincronização de Arquivos do Azure. Durante esse processo, dê ao servidor o mesmo nome de servidor e nomes de compartilhamento que o servidor antigo para que a transferência permaneça transparente para seus usuários, política de grupo e scripts.

Saiba mais sobre o DFS-N.

Fase 6: Desprovisionamento

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

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

Antes de começar, é uma prática recomendada observar sua nova implantação do Azure File Sync em produção por um tempo. Esse tempo dá-lhe a oportunidade de corrigir quaisquer problemas que possa encontrar. Depois de observar sua implantação do Azure File Sync por pelo menos alguns dias, você pode começar a desprovisionar recursos nesta ordem:

1. Desprovisione seu recurso StorSimple Data Manager por meio do portal do Azure. Todos os seus trabalhos DTS serão excluídos com ele. Você não poderá recuperar facilmente os logs de cópia. Se forem importantes para seus registros, recupere-os antes de desprovisioná-los.
2. Verifique se os dispositivos físicos StorSimple foram migrados e, em seguida, cancele o registro. Se você não tiver certeza de que eles foram migrados, não prossiga. Se você desprovisionar esses recursos enquanto eles ainda são necessários, não poderá recuperar os dados ou sua configuração.
   Opcionalmente, você pode primeiro desprovisionar o recurso de volume StorSimple, que limpará os dados no dispositivo. Este processo pode demorar vários dias e não elimina forensemente os dados no aparelho. Se isso for importante para você, manipule a zeragem de disco separadamente do desprovisionamento de recursos e de acordo com suas políticas.
3. Se não houver mais dispositivos registrados em um Gerenciador de Dispositivos StorSimple, você poderá continuar a remover o próprio recurso do Gerenciador de Dispositivos.
4. Agora é hora de excluir a conta de armazenamento StorSimple no Azure. Novamente, pare e confirme que sua migração está concluída e que nada nem ninguém depende desses dados antes de prosseguir.
5. Desconecte o dispositivo físico StorSimple do seu data center.
6. Se você possui o dispositivo StorSimple, você está livre para PC Reciclá-lo. Se o seu dispositivo estiver alugado, informe o locador e devolva-o conforme apropriado.

Sua migração está concluída.

---

Nota

Ainda tem dúvidas ou encontrou algum problema?
Estamos aqui para ajudar:

Resolução de Problemas

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

Erros de nível de trabalho

Fase	Erro	Detalhes / Mitigação
Cópia de segurança	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 o backup ainda está presente no catálogo de backup do StorSimple. Às vezes, as políticas automáticas de retenção de backup excluem backups entre selecioná-los para migração e realmente executar o trabalho de migração para esse backup. Considere desativar quaisquer agendamentos 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. Consulte a seção de chave de criptografia neste artigo para obter mais detalhes e ajudar a recuperar a chave correta.
	Erro de lote	É possível que a inicialização de toda a infraestrutura interna necessária para realizar uma migração tenha um problema. Vários outros serviços estão envolvidos neste processo. Esses problemas geralmente se resolvem quando você tenta executar o trabalho novamente.
	O StorSimple Manager encontrou um erro interno. aguarde uns minutos e tente a operação novamente. Se o problema persistir, contacte o Suporte da Microsoft. (Código de erro: 1074161829)	Esse erro genérico tem várias causas, mas uma possibilidade encontrada é que o gerenciador de dispositivos StorSimple atingiu o limite de 50 dispositivos. Verifique se os trabalhos executados mais recentemente no gerenciador de dispositivos de repente começaram a falhar com esse erro, o que sugere que esse é o problema. A atenuação para esse problema específico é remover todos os dispositivos StorSimple 8001 offline criados e usados pelo Serviço Gerenciador de Dados. Você pode arquivar um tíquete de suporte ou excluí-los manualmente no portal. Certifique-se de excluir apenas os dispositivos offline da série 8001.
Estimando arquivos	Falha no trabalho de volume de clonagem	Esse erro provavelmente indica que você especificou um backup que estava corrompido de alguma forma. O serviço de migração não pode montá-lo ou lê-lo. Você pode experimentar o backup manualmente ou abrir um tíquete de suporte.
	Não é possível prosseguir porque o volume está no formato não-NTFS	Somente volumes NTFS, não habilitados para ddupe, podem ser usados pelo serviço de migração. Se você tiver um volume formatado de forma diferente, como ReFS ou um formato de terceiros, o serviço de migração não poderá migrar esse volume. Consulte a secção Limitações conhecidas .
	Contacte o suporte. Nenhuma partição adequada encontrada no disco	O disco StorSimple que deve ter o volume especificado para migração não parece ter uma partição para esse volume. Isso é incomum e pode indicar uma corrupção ou um desalinhamento de gestão. Sua única opção para investigar melhor esse problema é registrar um tíquete de suporte.
	Tempo limite esgotado	A fase de estimativa falhando com um tempo limite normalmente é um problema com o dispositivo StorSimple ou com o backup de volume de origem sendo lento e, às vezes, até corrompido. Se a nova execução do backup não funcionar, preencher um tíquete de suporte é o melhor curso de ação.
	Não foi possível encontrar o caminho> do arquivo <Não foi possível encontrar uma parte do caminho	A definição de tarefa permite fornecer um subcaminho de origem. Este erro é mostrado quando esse caminho não existe. Por exemplo: \Share1 > \Share\Share1 Neste exemplo, você especificou \Share1 como um subcaminho na origem, mapeando para outro subcaminho no destino. No entanto, o caminho de origem não existe (foi escrito incorretamente?). Nota: O Windows preserva maiúsculas e minúsculas, mas não depende de maiúsculas e minúsculas. Ou seja, especificar \Share1 e \share1 é equivalente. Também: Os caminhos de destino que não existem serão criados automaticamente.
	Esta solicitação não está autorizada a executar esta operação	Este erro mostra quando a conta de armazenamento StorSimple de origem ou a conta de armazenamento de destino com o compartilhamento de arquivos do Azure tem uma configuração de firewall habilitada. Você deve permitir o tráfego no ponto de extremidade público e não restringi-lo com outras regras de firewall. 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. Desative todas as regras de firewall e execute novamente o trabalho.
Copiando arquivos	A conta que está sendo acessada não suporta HTTP	Desative o roteamento da Internet na conta de armazenamento de destino ou use o ponto de extremidade de roteamento da Microsoft.
	A parte especificada está cheia	Se o destino for um compartilhamento de arquivos 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 arquivos padrão do Azure, verifique se o compartilhamento de destino tem o recurso "compartilhamento de arquivos grandes" habilitado. O armazenamento padrão está crescendo à medida que você usa o compartilhamento. No entanto, se você usar uma conta de armazenamento herdada como destino, poderá encontrar um limite de compartilhamento de 5 TiB. Você terá que ativar manualmente o recurso "Compartilhamento de arquivos grandes". Corrija os limites no destino e execute novamente o trabalho.

Erros de nível de item

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

Fase	Erro	Mitigação
Copiar	-2146233088 O servidor está ocupado.	Execute novamente o trabalho se houver muitas falhas. Se houver apenas alguns erros, você pode tentar executar o trabalho novamente, mas muitas vezes uma cópia manual dos itens com falha pode ser mais rápida. Em seguida, retome a migração pulando para o processamento do próximo backup.
	-2146233088 A operação não pôde ser concluída dentro do tempo especificado.	Execute novamente o trabalho se houver muitas falhas. Se houver apenas alguns erros, você pode tentar executar o trabalho novamente, mas muitas vezes uma cópia manual dos itens com falha pode ser mais rápida. Em seguida, retome a migração pulando para o processamento do próximo backup.
	O carregamento expirou ou a cópia não foi iniciada	Execute novamente o trabalho se houver muitas falhas. Se houver apenas alguns erros, você pode tentar executar o trabalho novamente, mas muitas vezes uma cópia manual dos itens com falha pode ser mais rápida. Em seguida, retome a migração pulando para o processamento do próximo backup.
	-2146233029 A operação foi cancelada.	Execute novamente o trabalho se houver muitas falhas. Se houver apenas alguns erros, você pode tentar executar o trabalho novamente, mas muitas vezes uma cópia manual dos itens com falha pode ser mais rápida. Em seguida, retome a migração pulando para o processamento do próximo backup.
	1920 O arquivo não pode ser acessado pelo sistema.	Este é um erro comum quando o mecanismo de migração encontra um ponto de análise, link ou junção. Não são suportadas. Esses tipos de arquivos não podem ser copiados. Analise a seção Limitações conhecidas e a seção Fidelidade de arquivo neste artigo.
	-2147024891 Acesso negado	Este é um erro para ficheiros encriptados de uma forma que não podem ser acedidos no disco. Os ficheiros que podem ser lidos a partir do disco, mas simplesmente têm conteúdo encriptado, 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 Win32 FileTime 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 escrito por um aplicativo em um formato incorreto. Não há muito que você possa fazer, porque você não pode alterar o carimbo de data/hora no backup. Se a retenção desse arquivo for importante, talvez na versão mais recente (último backup contendo esse arquivo) você copie manualmente o arquivo, corrija o carimbo de data/hora e mova-o para o compartilhamento de arquivos do Azure de destino. Esta opção não é muito bem dimensionada, mas é uma opção para arquivos de alto valor onde você deseja ter pelo menos uma versão retida em seu destino.
	-2146232798 manípulo seguro foi fechado	Muitas vezes um erro transitório. Execute novamente o trabalho se houver muitas falhas. Se houver apenas alguns erros, você pode tentar executar o trabalho novamente, mas muitas vezes uma cópia manual dos itens com falha pode ser mais rápida. Em seguida, retome a migração pulando para o processamento do próximo backup.
	-2147024413 Erro fatal de hardware do dispositivo	Este é um erro raro e não é realmente relatado para um dispositivo físico, mas sim para os dispositivos virtualizados da série 8001 usados pelo serviço de migração. O aparelho teve um problema. Os ficheiros com este erro não impedirão que a migração prossiga para a próxima cópia de segurança. Isso torna difícil para você executar uma cópia manual ou tentar novamente o backup que contém arquivos com esse erro. Se os arquivos deixados para trás são muito importantes ou há um grande número de arquivos, talvez seja necessário iniciar a migração de todos os backups novamente. Abra um ticket de suporte para investigação adicional.
Excluir (limpeza de espelho)	O diretório especificado não está vazio.	Este erro ocorre quando o modo de migração está definido como espelhado e o processo que remove itens da partilha de ficheiros do Azure deparou-se com um problema que o impediu de eliminar itens. A exclusão acontece apenas no compartilhamento ao vivo, 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 ao vivo antes do próximo instantâneo. Há duas opções: Opção 1: montar o compartilhamento de arquivos 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 ao de origem e tenha alguns itens extras que não estavam no backup StorSimple original.
	Mau pedido	Esse erro indica que o arquivo de origem tem determinadas características que não puderam ser copiadas para o compartilhamento de arquivos do Azure. Mais notavelmente, pode haver 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, robocopy novamente para o compartilhamento de arquivos do Azure. Em seguida, você pode retomar a migração pulando para o próximo backup a ser processado.

Próximos passos

• Compreenda a flexibilidade das políticas de hierarquização na nuvem.
• Habilite o Backup do Azure em seus compartilhamentos de arquivos do Azure para agendar instantâneos e definir agendamentos de retenção de backup.
• Se vir no portal do Azure que alguns ficheiros não estão permanentemente a sincronizar, consulte o Guia de Resolução de Problemas para obter passos para resolver estes problemas.