StorSimple migração 8100 e 8600 para Azure File Sync

A série StorSimple 8000 é representada pelos aparelhos 8100 ou 8600 físicos e nos seus componentes de serviço de nuvem. Os aparelhos virtuais StorSimple 8010 e 8020 também estão abrangidos por este guia de migração. É possível migrar os dados de qualquer um destes aparelhos para ações de ficheiros Azure com Azure File Sync opcional. Azure File Sync é o serviço Azure de longo prazo padrão e estratégico que substitui a funcionalidade StorSimple no local.

A série StorSimple 8000 chegará ao seu fim de vida em dezembro de 2022. É importante começar a planear a sua migração o mais rápido possível. Este artigo fornece os conhecimentos de fundo necessários e passos de migração para uma migração bem sucedida para Azure File Sync.

Visão geral da migração - clique para jogar!

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

  • Ficheiros do Azure
  • Ficheiros do Azure Sync
  • Comparação de StorSimple & Ficheiros do Azure
  • Ferramenta de migração StorSimple Data Manager e visão geral do processo

Fase 1: Preparar para a migração

Esta secção contém os passos que deve tomar no início da sua migração de volumes StorSimple para ações de ficheiros Azure.

Prepare a sua migração - clique para jogar!

Este vídeo cobre:

  • Selecionando o nível de armazenamento
  • Selecionando opções de redundância de armazenamento
  • Selecionando acesso direto a partilha vs. Azure File Sync
  • Número de série da chave de encriptação & de dados de serviço StorSimple
  • Migração de backup de volume StorSimple
  • Mapeamento de ações de volume storSimple & para ações de ficheiros Azure
  • Ações de agrupamento dentro de ações de ficheiros Azure
  • Considerações de mapeamento
  • Folha de cálculo do planeamento migratório
  • Folha de cálculo de mapeamento de espaço de nome

Inventário

Quando começar a planear a sua migração, identifique primeiro todos os aparelhos e volumes StorSimple necessários para migrar. Depois de o fazeres, podes decidir qual é o melhor caminho de migração para ti.

Resumo dos custos de migração

As ações de ficheiros Azure de volumes StorSimple através de empregos de migração num recurso StorSimple Data Manager são gratuitas. Outros custos podem ser incorridos durante e após uma migração:

  • Saída de rede: Os seus ficheiros StorSimple vivem numa conta de armazenamento dentro de uma região específica de Azure. Se você fornecer as ações de arquivo Azure que você migra para uma conta de armazenamento que está localizada na mesma região de Azure, não haverá custo de saída. Pode mover os seus ficheiros para uma conta de armazenamento numa região diferente como parte desta migração. Nesse caso, os custos de saída aplicar-se-ão a si.
  • Transações de ações de ficheiros Azure: Quando os ficheiros são copiados para uma partilha de ficheiros Azure (como parte de uma migração ou fora de um), os custos de transação aplicam-se à medida que os ficheiros e metadados estão a ser escritos. Como uma boa prática, inicie a sua partilha de ficheiros Azure no nível otimizado de transação durante a migração. Mude para o nível desejado após a migração estar terminada. As fases seguintes irão chamar a atenção para o assunto no ponto apropriado.
  • Alterar um nível de partilha de ficheiros Azure: Alterar o nível de uma ação de ficheiro Azure operações de custos. Na maioria dos casos, será mais rentável seguir os conselhos do ponto anterior.
  • Custo de armazenamento: Quando esta migração começa a copiar ficheiros numa partilha de ficheiros Azure, o armazenamento é consumido e faturado. As cópias de segurança migradas tornar-se-ão imagens de partilha de ficheiros Azure. Os instantâneos de partilha de ficheiros só consomem capacidade de armazenamento para as diferenças que contêm.
  • StorSimple: Até ter a oportunidade de desprovisionar os dispositivos StorSimple e as contas de armazenamento, o custo StorSimple para armazenamento, cópias de segurança e aparelhos continuará a ocorrer.

Acesso direto a partilha vs. Azure File Sync

As ações de ficheiros Azure abrem um novo mundo de oportunidades para estruturar a implementação dos seus serviços de ficheiros. Uma partilha de ficheiros Azure é apenas uma partilha de SMB na nuvem que pode configurar para que os utilizadores tenham acesso diretamente ao protocolo SMB com a autenticação conhecida de Kerberos e permissões NTFS existentes (ACLs de ficheiros e pastas) que funcionam de forma nativa. Saiba mais sobre o acesso à identidade das ações de ficheiros Azure.

Uma alternativa ao acesso direto é Azure File Sync. Azure File Sync é um analógico direto para a capacidade da StorSimple de cache ficheiros frequentemente usados no local.

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

  • Sincronização de ficheiros e tiering de nuvem para criar uma cache de acesso ao desempenho em qualquer Servidor do Windows.
  • Ações de arquivo como armazenamento nativo em Azure que podem ser acedidas em vários protocolos como SMB e file REST.

As ações de ficheiros Azure retêm importantes aspetos de fidelidade de ficheiros em ficheiros armazenados, como atributos, permissões e timetamps. Com as partilhas de ficheiros Azure, já não há necessidade de uma aplicação ou serviço para interpretar os ficheiros e pastas armazenados na nuvem. Pode acessá-los de forma nativa sobre protocolos familiares e clientes como o Windows Explorador de Ficheiros. As ações de ficheiros Azure permitem armazenar dados de servidores de ficheiros de fim geral e dados de aplicação na nuvem. A cópia de segurança de uma partilha de ficheiros Azure é uma funcionalidade incorporada e pode ser melhorada Azure Backup.

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

Chave de encriptação de dados de serviço StorSimple

Quando montou o seu aparelho StorSimple pela primeira vez, gerou uma "chave de encriptação de dados de serviço" e instruiu-o a armazenar a chave de forma segura. Esta chave é utilizada para encriptar todos os dados na conta de armazenamento Azure associada onde o aparelho StorSimple armazena os seus ficheiros.

A "chave de encriptação de dados de serviço" é necessária para uma migração bem sucedida. Agora é uma boa hora para recuperar esta chave dos seus registos, uma para cada um dos aparelhos no seu inventário.

Se não encontrar as chaves nos registos, pode gerar uma nova chave do aparelho. Cada aparelho tem uma chave de encriptação única.

Alterar a chave de encriptação de dados de serviço

As chaves de encriptação de dados de serviço são usadas para encriptar dados confidenciais do cliente, tais como credenciais de conta de armazenamento, que são enviadas do seu serviço StorSimple Manager para o dispositivo StorSimple. Terá de alterar estas teclas periodicamente se a sua organização de TI tiver uma política de rotação chave nos dispositivos de armazenamento. O processo de alteração de chave pode ser ligeiramente diferente dependendo se existe um único dispositivo ou vários dispositivos geridos pelo serviço StorSimple Manager. Para mais informações, aceda à segurança e proteção de dados da StorSimple.

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

  1. Utilizando scripts Windows PowerShell para a Azure Resource Manager, autorize um dispositivo para alterar a chave de encriptação de dados de serviço.
  2. Utilizando Windows PowerShell para StorSimple, inicie a alteração da chave de encriptação de dados de serviço.
  3. Se tiver mais do que um dispositivo StorSimple, atualize a chave de encriptação de dados de serviço nos outros dispositivos.

Passo 1: Utilize Windows PowerShell script para autorizar um dispositivo a alterar a chave de encriptação de dados de serviço

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

Este passo é realizado utilizando o script baseado em Azure Resource Manager. O administrador de serviço pode selecionar um dispositivo que seja elegível para ser autorizado. O dispositivo é então autorizado a iniciar o processo de alteração da chave de encriptação de dados de serviço.

Para mais informações sobre a utilização do script, vá a Authorize-ServiceEncryptionRollover.ps1

Quais os dispositivos que podem ser autorizados a alterar chaves de encriptação de dados de serviço?

Um dispositivo deve cumprir os seguintes critérios antes de poder ser autorizado a iniciar alterações na chave de encriptação de dados de serviço:

  • O dispositivo deve estar online para ser elegível para a autorização de alteração da chave de encriptação de dados de serviço.
  • Pode autorizar o mesmo dispositivo novamente após 30 minutos se a alteração da chave não tiver sido iniciada.
  • Pode autorizar um dispositivo diferente, desde que a alteração da chave não tenha sido iniciada pelo dispositivo previamente autorizado. Depois de autorizado o novo dispositivo, o dispositivo antigo não pode iniciar a alteração.
  • Não é possível autorizar um dispositivo enquanto estiver em curso a capotamento da chave de encriptação de dados de serviço.
  • Pode autorizar um dispositivo quando alguns dos dispositivos registados no serviço tiverem revirado a encriptação enquanto outros não.

Passo 2: Utilize Windows PowerShell para storSimple iniciar a alteração da chave de encriptação de dados de serviço

Este passo é realizado no Windows PowerShell para interface StorSimple no dispositivo autorizado StorSimple.

Nota

Nenhuma operação pode ser realizada no portal do Azure do seu serviço StorSimple Manager até que a capotamento da chave esteja concluída.

Se estiver a utilizar a consola em série do dispositivo para ligar à interface Windows PowerShell, execute os seguintes passos.

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

  1. Selecione a opção 1 para iniciar sessão com acesso total.

  2. Na linha de comandos, escreva:

    Invoke-HcsmServiceDataEncryptionKeyChange

  3. Depois de o cmdlet ter sido concluído com sucesso, obterá uma nova chave de encriptação de dados de serviço. Copie e guarde esta chave para utilização no passo 3 deste processo. Esta chave será utilizada para atualizar todos os dispositivos restantes registados no serviço StorSimple Manager.

    Nota

    Este processo deve ser iniciado no prazo de quatro horas após a autorização de um dispositivo StorSimple.

    Esta nova chave é então enviada para o serviço para ser empurrada para todos os dispositivos que estão registados no serviço. Em seguida, aparecerá um alerta no painel de instrumentos de serviço. O serviço irá desativar todas as operações nos dispositivos registados, e o administrador do dispositivo terá então de atualizar a chave de encriptação de dados de serviço nos outros dispositivos. No entanto, o I/Os (anfitriões que enviam dados para a nuvem) não será interrompido.

    Se tiver um único dispositivo registado no seu serviço, o processo de capotamento está concluído e pode saltar o passo seguinte. Se tiver vários dispositivos registados no seu serviço, proceda ao passo 3.

Passo 3: Atualizar a chave de encriptação de dados de serviço em outros dispositivos StorSimple

Estes passos devem ser realizados na interface Windows PowerShell do seu dispositivo StorSimple se tiver vários dispositivos registados no seu serviço StorSimple Manager. A chave que obteve no Passo 2 deve ser utilizada para atualizar todo o restante dispositivo StorSimple registado no serviço StorSimple Manager.

Execute os seguintes passos para atualizar a encriptação de dados de serviço no seu dispositivo.

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

  1. Utilize Windows PowerShell para que o StorSimple se conecte à consola. Selecione a opção 1 para iniciar sessão com acesso total.
  2. Na linha de comandos, escreva: Invoke-HcsmServiceDataEncryptionKeyChange – ServiceDataEncryptionKey
  3. Forneça a chave de encriptação de dados de serviço que obteve no Passo 2: Utilize Windows PowerShell para storSimple iniciar a alteração da chave de encriptação de dados de serviço.

Para atualizar a chave de encriptação de dados de serviço em todos os aparelhos em nuvem 8010/8020

  1. Descarregue e configurar Update-CloudApplianceServiceEncryptionKey.ps1 script PowerShell.
  2. Open PowerShell e na solicitação de comando, escreva: Update-CloudApplianceServiceEncryptionKey.ps1 -SubscriptionId [subscription] -TenantId [tenantid] -ResourceGroupName [resource group] -ManagerName [device manager]

Este script garantirá que a chave de encriptação de dados de serviço está definida em todos os aparelhos em nuvem 8010/8020 sob o gestor do dispositivo.

Atenção

Quando estiver a decidir como ligar-se ao seu aparelho StorSimple, considere o seguinte:

  • A ligação através de uma sessão HTTPS é a opção mais segura e recomendada.
  • A ligação direta à consola em série do dispositivo é segura, mas a ligação à consola em série sobre os interruptores de rede não é.
  • As ligações de sessão HTTP são uma opção, mas não são encriptadas. Não são recomendados a menos que sejam usados numa rede fechada e de confiança.

Limitações conhecidas

As ações de ficheiro StorSimple Data Manager e Azure têm algumas limitações que deve considerar antes de iniciar a sua migração, pois podem impedir uma migração:

  • Apenas os volumes NTFS do seu aparelho StorSimple são suportados. Os volumes ReFS não são suportados.
  • Qualquer volume colocado nos Discos Dinâmicos do Servidor do Windows não é suportado. (precotado antes Windows Server 2012)
  • O serviço não funciona com volumes encriptados bitLocker ou habilitados a Deduplica de Dados .
  • Os reforços StorSimple corrompidos não podem ser migrados.
  • Opções especiais de networking, tais como firewalls ou comunicação privada apenas de ponto final não podem ser ativadas na conta de armazenamento de fonte onde estão armazenadas cópias de segurança StorSimple, nem na conta de armazenamento alvo que detém as suas ações de ficheiroS Azure.

Fidelidade de arquivo

Se nenhuma das limitações em limitações conhecidas impedir uma migração. Ainda existem limitações no que pode ser armazenado em ações de ficheiros Azure que precisa de estar ciente. A fidelidade de ficheiros refere-se à multiplicidade de atributos, timetamps e dados que compõem um ficheiro. Numa migração, a fidelidade de ficheiros é uma medida de quão bem a informação sobre a fonte (volume StorSimple) pode ser traduzida (migrada) para o alvo (ação de ficheiros Azure). Ficheiros do Azure suporta um subconjunto das propriedades de ficheiros NTFS. ACLs, metadados comuns, e alguns picos de tempo serão migrados. Os seguintes itens não impedirão uma migração, mas causarão problemas por item durante uma migração:

  • Prazos: O tempo de alteração do ficheiro não será definido - atualmente é apenas lido ao longo do protocolo REST. A última hora de acesso num ficheiro não será movida, não é atualmente um atributo suportado em ficheiros armazenados numa partilha de ficheiros Azure.
  • Os Fluxos de Dados Alternativos não podem ser armazenados em ações de ficheiros Azure. Os ficheiros que detenha fluxos de dados alternativos serão copiados, mas os Fluxos de Dados Alternativos serão retirados do ficheiro no processo.
  • Os laços simbólicos, as ligações duras, as junções e os pontos de reparse são ignorados durante uma migração. Os registos de cópias de migração listarão cada item ignorado e uma razão.
  • Os ficheiros encriptados do EFS não serão copiados. Os registos de cópia mostrarão que o item não copiou com "O acesso é negado".
  • Ficheiros corruptos são ignorados. Os registos de cópia podem enumerar erros diferentes para cada item que é corrupto no disco StorSimple: "O pedido falhou devido a um erro fatal de hardware do dispositivo" ou "O ficheiro ou diretório é corrompido ou ilegível" ou "A estrutura da lista de controlo de acesso (ACL) é inválida".
  • Os ficheiros individuais maiores do que 4 TiB são ignorados.
  • Os comprimentos dos caminhos de arquivo devem ser iguais ou inferiores a 2048 caracteres. Os ficheiros e pastas com caminhos mais longos serão ignorados.
  • Os pontos de reparse serão ignorados. Qualquer Microsoft Pontos de desaplicação de dados /SIS ou os de terceiros não podem ser resolvidos pelo motor de migração e impedir a migração dos ficheiros e pastas afetados.

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

Backups de volume StorSimple

A StorSimple oferece backups diferenciais ao nível do volume. As ações de ficheiros Azure também têm esta capacidade, chamadas snapshots de partilha. Os seus trabalhos de migração só podem mover backups, não dados do volume ao vivo. Assim, o mais recente backup deve estar sempre na lista de backups movidos numa migração.

Decida se precisa de mover quaisquer backups mais antigos durante a sua migração. A melhor prática é manter esta lista o mais pequena possível, para que os seus trabalhos de migração completem mais rapidamente.

Para identificar cópias de segurança críticas que devem ser migradas, faça uma lista de verificação das suas políticas de backup. Por exemplo:

  • O mais recente reforço. (Nota: A cópia de segurança mais recente deve sempre fazer parte desta lista.)
  • Um reforço por mês durante 12 meses.
  • Um reforço por ano durante três anos.

Mais tarde, quando criar os seus empregos de migração, pode utilizar esta lista para identificar as cópias de segurança exatas do volume StorSimple que devem ser migradas para satisfazer os requisitos da sua lista.

Atenção

Não é suportada a seleção de mais de 50 cópias de segurança de volume StorSimple. Os seus empregos de migração só podem mover backups, nunca dados do volume ao vivo. Portanto, o backup mais recente é o mais próximo dos dados ao vivo e, portanto, deve sempre fazer parte da lista de backups a serem movidos numa migração.

Atenção

É melhor suspender todas as políticas de retenção de backup StorSimple antes de selecionar um backup para migração.
Migrar os seus backups leva vários dias ou semanas. O StorSimple oferece políticas de retenção de backup que irão eliminar backups. As cópias de segurança selecionadas para esta migração podem ser eliminadas antes de terem a oportunidade de serem migradas.

Mapear os seus volumes StorSimple existentes para ações de ficheiros Azure

Neste passo, irá determinar quantas ações de arquivo Azure precisa. Uma única instância do Windows Server (ou cluster) pode sincronizar até 30 ações de ficheiros Azure.

Pode ter mais pastas nos seus volumes que partilha localmente como partilha sMB para os seus utilizadores e apps. A maneira mais fácil de imaginar este cenário é prever uma partilha no local que mapeia 1:1 para uma partilha de ficheiros Azure. Se tiver um número suficiente suficiente de ações, abaixo de 30 para uma única instância do Windows Server, recomendamos um mapeamento de 1:1.

Se tiver mais de 30 ações, mapear uma partilha no local 1:1 para uma partilha de ficheiros Azure é muitas vezes desnecessária. Considere as seguintes opções.

Agrupamento de partilha

Por exemplo, se o seu departamento de recursos humanos (RH) tiver 15 ações, poderá considerar armazenar todos os dados de RH numa única partilha de ficheiros Azure. Armazenar várias ações no local numa partilha de ficheiros Azure não o impede de criar as habituais 15 ações SMB na sua instância local do Windows Server. Significa apenas que organiza as pastas de raiz destas 15 ações como sub-dobradeiras sob uma pasta comum. Em seguida, sincroniza esta pasta comum a uma partilha de ficheiros Azure. Desta forma, apenas uma única partilha de ficheiros Azure na nuvem é necessária para este grupo de ações no local.

Sincronização de volume

Azure File Sync suporta sincronizar a raiz de um volume para uma partilha de ficheiros Azure. Se sincronizar a raiz do volume, todas as sub-dobradeiras e ficheiros irão para a mesma partilha de ficheiros Azure.

Sincronizar a raiz do volume nem sempre é a melhor opção. Há benefícios em sincronizar vários locais. Por exemplo, fazê-lo ajuda a manter o número de itens mais baixo por âmbito de sincronização. Testamos ações de ficheiros Azure e Azure File Sync com 100 milhões de itens (ficheiros e pastas) por ação. Mas uma boa prática é tentar manter o número abaixo dos 20 milhões ou 30 milhões numa única ação. Configurar Azure File Sync com um número mais baixo de itens não é benéfico apenas para a sincronização de ficheiros. Um número mais baixo 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 espaço de nome apareça num servidor ativado para Azure File Sync.
  • A restauração do lado da nuvem a partir de uma imagem de partilha de ficheiros Azure será mais rápida.
  • A recuperação de desastres de um servidor no local pode acelerar significativamente.
  • As alterações efetuadas diretamente numa partilha de ficheiros Azure (fora da sincronização) podem ser detetadas e sincronizadas mais rapidamente.

Dica

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

Uma abordagem estruturada de um mapa de implantação

Antes de implementar o armazenamento em nuvem num passo posterior, é importante criar um mapa entre as pastas no local e as partilhas de ficheiros Azure. Este mapeamento informará quantos e quais Azure File Sync sincronizar os recursos do grupo que irá providenciar. Um grupo de sincronização liga a partilha de ficheiros Azure e a pasta no seu servidor e estabelece uma ligação sincronizada.

Para decidir quantas ações de arquivo Azure precisa, reveja os seguintes limites e boas práticas. Ao fazê-lo, irá ajudá-lo a otimizar o seu mapa.

  • Um servidor no qual o agente Azure File Sync está instalado pode sincronizar-se com até 30 ações de ficheiros Azure.

  • Uma parte de ficheiro Azure é implantada numa conta de armazenamento. Este arranjo faz da conta de armazenamento um alvo de escala para números de desempenho como IOPS e produção.

    Uma partilha de ficheiros padrão da Azure pode teoricamente saturar o desempenho máximo que uma conta de armazenamento pode fornecer. Se você colocar várias ações numa única conta de armazenamento, você está criando um conjunto compartilhado de IOPS e produção para estas ações. Se pretender anexar apenas Azure File Sync a estas ações de ficheiros, agrupar várias ações de ficheiros Azure na mesma conta de armazenamento não criará problemas. Reveja os alvos de desempenho da partilha de ficheiros Azure para obter uma visão mais profunda das métricas relevantes. Estas limitações não se aplicam ao armazenamento premium, onde o desempenho é explicitamente previsto e garantido para cada ação.

    Se planeia levantar uma aplicação para o Azure que utilizará a partilha de ficheiros Azure de forma nativa, poderá precisar de mais desempenho da sua partilha de ficheiros Azure. Se este tipo de utilização é uma possibilidade, mesmo no futuro, o melhor é criar uma única quota de ficheiros Azure padrão na sua própria conta de armazenamento.

  • Há um limite de 250 contas de armazenamento por subscrição por região de Azure.

Dica

Tendo em conta estas informações, torna-se frequentemente necessário agrupar várias pastas de alto nível nos seus volumes num novo diretório de raiz comum. Em seguida, sincroniza este novo diretório de raiz, e todas as pastas que agrupou nele, para uma única partilha de ficheiros Azure. Esta técnica permite-lhe permanecer dentro do limite de 30 sincronizações de partilha de ficheiros Azure por servidor.

Este agrupamento sob uma raiz comum não afeta o acesso aos seus dados. Os vossos ACLs ficam como estão. Só precisa de ajustar quaisquer caminhos de partilha (como ações SMB ou NFS) que possa ter nas pastas do servidor local que agora se transformou numa raiz comum. Nada mais muda.

Importante

O vetor de escala mais importante para Azure File Sync é o número de itens (ficheiros e pastas) que precisam de ser sincronizados. Reveja os alvos de escala Azure File Sync para mais detalhes.

É uma boa prática manter o número de itens por sincronização baixo. É um fator importante a ter em conta no seu mapeamento de pastas para ações de ficheiros Azure. Azure File Sync é testada com 100 milhões de itens (ficheiros e pastas) por ação. Mas muitas vezes é melhor manter o número de itens abaixo de 20 milhões ou 30 milhões numa única parte. Divida o seu espaço de nome em várias ações se começar a exceder estes números. Pode continuar a agrupar várias ações no local na mesma partilha de ficheiros Azure se ficar aproximadamente abaixo destes números. Esta prática vai dar-lhe espaço para crescer.

É possível que, na sua situação, um conjunto de pastas possa logicamente sincronizar-se com a mesma partilha de ficheiros Azure (utilizando a nova abordagem comum da pasta raiz mencionada anteriormente). Mas ainda pode ser melhor reagrupar pastas para que se sincronizem a duas em vez de uma partilha de ficheiros Azure. Pode utilizar esta abordagem para manter o número de ficheiros e pastas por partilha de ficheiros equilibrado em todo o servidor. Também pode dividir as suas ações no local e sincronizar-se com mais servidores no local, adicionando a capacidade de sincronizar com mais 30 ações de ficheiros Azure por servidor extra.

Criar uma mesa de mapeamento

Diagrama que mostra um exemplo de uma tabela de mapeamento. Descarregue o seguinte ficheiro para experimentar e utilizar o conteúdo desta imagem.

Utilize as informações anteriores para determinar quantas ações de ficheiroS Azure necessita e quais as partes dos seus dados existentes que acabarão na qual a ação de ficheiroS Azure.

Crie uma tabela que grava os seus pensamentos para que possa encaminhá-la quando for necessário. Manter-se organizado é importante porque pode ser fácil perder detalhes do seu plano de mapeamento quando está a auser muitos recursos Azure ao mesmo tempo. Descarregue o seguinte ficheiro Excel para usar como modelo para ajudar a criar o seu mapeamento.


Ícone de excel que define o contexto para o download. Descarregue um modelo de mapeamento de espaço de nome.

Número de contas de armazenamento

A sua migração provavelmente beneficiará de uma implementação de várias contas de armazenamento que cada uma detém um número menor de ações de ficheiros Azure.

Se as suas ações de ficheiros forem altamente ativas (utilizadas por muitos utilizadores ou aplicações), duas ações de ficheiros Azure poderão atingir o limite de desempenho da sua conta de armazenamento. Por isso, a melhor prática é migrar para múltiplas contas de armazenamento, cada uma com as suas próprias ações individuais de ficheiros, e normalmente não mais do que duas ou três ações por conta de armazenamento.

Uma boa prática é implementar contas de armazenamento com uma partilha de ficheiros cada. Você pode juntar várias ações de arquivo Azure na mesma conta de armazenamento, se tiver ações de arquivo nelas.

Estas considerações aplicam-se mais ao acesso direto à nuvem (através de um VM ou serviço Azure) do que a Azure File Sync. Se planeia utilizar exclusivamente Azure File Sync nestas ações, agrupar várias numa única conta de armazenamento Azure está bem. No futuro, poderá querer levantar e transferir uma app para a nuvem que teria acesso direto a uma partilha de ficheiros, este cenário beneficiaria de ter IOPS mais elevado e produção. Ou pode começar a usar um serviço em Azure que também beneficiaria de ter IOPS mais elevado e produção.

Se fez uma lista das suas ações, mapeeeia cada ação para a conta de armazenamento onde ela irá residir.

Importante

Decida sobre uma região de Azure e certifique-se de que cada conta de armazenamento e Azure File Sync recursos correspondem à região que selecionou. Não configuure as definições de rede e firewall para as contas de armazenamento agora. Fazer estas configurações neste momento tornaria impossível uma migração. Configure estas definições de armazenamento Azure após a migração estar completa.

Definições da conta de armazenamento

Há muitas configurações que pode fazer numa conta de armazenamento. A seguinte lista de verificação deve ser utilizada para confirmar as configurações da sua conta de armazenamento. Pode alterar, por exemplo, a configuração de rede após a conclusão da migração.

  • Grandes ações de ficheiros: Ativadas - Grandes ações de ficheiros melhoram o desempenho e permitem armazenar até 100TiB numa ação. Esta definição aplica-se às contas de armazenamento-alvo com ações de ficheiros Azure.
  • Firewall e redes virtuais: Desativado - não configuure quaisquer restrições DE IP ou limite o acesso da conta de armazenamento a um VNET específico. O ponto final público da conta de armazenamento é usado durante a migração. Todos os endereços IP dos VMs Azure devem ser permitidos. É melhor configurar quaisquer regras de firewall na conta de armazenamento após a migração. Configure as contas de armazenamento da sua fonte e alvo desta forma.
  • Pontos Finais Privados: Suportado - Pode permitir pontos finais privados, mas o ponto final público é utilizado para a migração e deve permanecer disponível. Esta consideração aplica-se a ambas, as suas contas de armazenamento de origem e alvo.

Resumo da fase 1

No final da Fase 1:

  • Tem uma boa visão geral dos seus dispositivos e volumes StorSimple.
  • O serviço Data Manager está pronto para aceder aos seus volumes StorSimple na nuvem porque recuperou a sua "chave de encriptação de dados de serviço" para cada dispositivo StorSimple.
  • Tem um plano para o qual os volumes e backups (se forem os mais recentes) precisam de ser migrados.
  • Sabe como mapear os seus volumes para o número apropriado de ações de ficheiros Azure e contas de armazenamento.

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

Esta secção discute considerações em torno da implantação dos diferentes tipos de recursos que são necessários em Azure. Alguns irão deter os seus dados após a migração, e alguns são necessários apenas para a migração. Não comeces a mobilizar recursos até teres finalizado o teu plano de implantação. É difícil, às vezes impossível, mudar certos aspetos dos seus recursos Azure depois de terem sido implantados.

Implementar recursos necessários - clique para jogar!

Este vídeo cobre a implementação de:

  • Contas de armazenamento
  • Grupos de subscrição e recursos
  • Contas de armazenamento
  • Tipos e nomes
  • Desempenho e tamanho de partilha
  • Tipos de localização e replicação
  • Ações de arquivo Azure
  • Serviço StorSimple Data Manager

Implementar contas de armazenamento

Provavelmente terá de implementar várias contas de armazenamento da Azure. Cada um deles irá deter um número menor de ações de ficheiros Azure, de acordo com o seu plano de implantação, concluído na secção anterior deste artigo. Vá ao portal do Azure para implementar as suas contas de armazenamento planeadas. Considere aderir às seguintes definições básicas para qualquer nova conta de armazenamento.

Importante

Não configuure as definições de rede e firewall para as suas contas de armazenamento agora. Fazer essas configurações neste momento tornaria impossível uma migração. Configure estas definições de armazenamento Azure após a migração estar completa.

Subscrição

Pode utilizar a mesma subscrição que utilizou para a sua implementação StorSimple ou outra. A única limitação é que a sua subscrição deve estar no mesmo inquilino do Azure Ative Directory que a subscrição StorSimple. Considere mover a assinatura StorSimple para o inquilino apropriado antes de iniciar uma migração. Você só pode mover toda a subscrição, recursos StorSimple individuais não podem ser transferidos para um inquilino ou subscrição diferente.

Grupo de recursos

Os grupos de recursos estão a ajudar na organização de recursos e permissões de gestão de administração. Saiba mais sobre grupos de recursos em Azure.

Nome da conta de armazenamento

O nome da sua conta de armazenamento passará a fazer parte de um URL e tem determinadas limitações de caracteres. Na sua convenção de nomeação, considere que os nomes das contas de armazenamento têm de ser únicos no mundo, permitem apenas letras e números minúsculos, requerem entre 3 a 24 caracteres, e não permitem caracteres especiais como hífenes ou sublinhados. Para mais informações, consulte as regras de nomeação de recursos de armazenamento Azure.

Localização

A localização ou região de Azure de uma conta de armazenamento é muito importante. Se utilizar Azure File Sync, todas as suas contas de armazenamento devem estar na mesma região que o seu recurso de Serviço de Sincronização de Armazenamento. A região Azure que escolher deve ser próxima ou central para os seus servidores e utilizadores locais. Depois de o seu recurso ter sido implantado, não pode mudar a sua região.

Pode escolher uma região diferente de onde reside atualmente os seus dados StorSimple (conta de armazenamento).

Importante

Se escolher uma região diferente da sua localização atual da conta de armazenamento StorSimple, os encargos de saída serão aplicados durante a migração. Os dados deixarão a região StorSimple e entrarão na sua nova região de conta de armazenamento. Não se aplicam taxas de largura de banda se permanecer na mesma região de Azure.

Desempenho

Tem a opção de escolher armazenamento premium (SSD) para ações de ficheiros Azure ou armazenamento padrão. O armazenamento padrão inclui vários níveis para uma partilha de ficheiros. O armazenamento padrão é a opção certa para a maioria dos clientes que migram da StorSimple.

Ainda não tem certeza?

  • Escolha o armazenamento premium se precisar do desempenho de uma parte de arquivo Premium Azure.
  • Escolha o armazenamento padrão para as cargas de trabalho do servidor de ficheiros de uso geral, que inclui dados quentes e dados de arquivo. Escolha também o armazenamento padrão se a única carga de trabalho na parte da nuvem for Azure File Sync.
  • Para ações de ficheiros premium, escolha ações de arquivo no assistente de conta de armazenamento de criar.

Replicação

Existem várias definições de replicação disponíveis. Saiba mais sobre os diferentes tipos de replicação.

Escolha apenas entre uma das duas opções seguintes:

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

Nota

Apenas os tipos de redundância LRS e ZRS são compatíveis com as grandes 100 ações de ficheiros Azure de capacidade 100 TiB.

O armazenamento geo redundante (GRS) em todas as variações não é suportado atualmente. Pode mudar o seu tipo de redundância mais tarde e mudar para GRS quando o suporte chegar a Azure.

Ativar 100 ações de ficheiros de capacidade tiB

Uma imagem que mostra o separador Advanced no portal do Azure para a criação de uma conta de armazenamento.

Sob a secção Avançada do novo assistente de conta de armazenamento no portal do Azure, pode ativar o suporte de grandes ações de ficheiros nesta conta de armazenamento. Se esta opção não estiver disponível para si, é provável que tenha selecionado o tipo de redundância errado. Certifique-se de que seleciona apenas LRS ou ZRS para que esta opção fique disponível.

Optar pelas grandes ações de ficheiros de capacidade de 100 TiB tem vários benefícios:

  • O seu desempenho é muito aumentado em comparação com as ações de ficheiros de 5 tiB mais pequenas (por exemplo, 10 vezes o IOPS).
  • Sua migração terminará significativamente mais rápido.
  • Certifique-se de que uma partilha de ficheiros terá capacidade suficiente para reter todos os dados que irá migrar para ele, incluindo as cópias de segurança diferenciais de capacidade de armazenamento necessárias.
  • O crescimento futuro está coberto.

Importante

Não aplique rede especial na sua conta de armazenamento antes ou durante a sua migração. O ponto final público deve estar acessível nas contas de origem e de armazenamento de destino. Não é suportado qualquer limitação a intervalos ip específicos ou VNETs. Pode alterar as configurações de rede de conta de armazenamento após a migração.

Ações de arquivo Azure

Após a criação das suas contas de armazenamento, vá à secção de partilha de ficheiros da conta de armazenamento e implemente o número adequado de ações de ficheiros Azure de acordo com o seu plano de migração a partir da Fase 1. Considere aderir às seguintes definições básicas para as suas novas ações de ficheiros no Azure.

Uma imagem portal do Azure que mostra a nova UI partilhada por ficheiros.


Nome
Letras minúsculas, números e hífenes são apoiados.

Quota
A quota aqui é comparável a uma quota rígida SMB numa instância do Windows Server. A melhor prática é não definir uma quota aqui porque a sua migração e outros serviços falharão quando a quota for atingida.


Níveis Selecione Transação otimizada para a sua nova partilha de ficheiros. Durante a migração, muitas transações ocorrerão. É mais eficiente em termos de custos mudar o seu nível mais tarde para o nível mais adequado à sua carga de trabalho.

StorSimple Data Manager

O recurso Azure que irá manter os seus empregos de migração chama-se StorSimple Data Manager. Selecione Novo recurso e procure-o. Em seguida, selecione Criar.

Este recurso temporário é utilizado para orquestração. Desprovisioná-lo depois da sua migração terminar. Deve ser implantado na mesma subscrição, grupo de recursos e região que a sua conta de armazenamento StorSimple.

Azure File Sync

Com Azure File Sync, pode adicionar no local os ficheiros mais acedidos. Semelhante às habilidades de cache do StorSimple, a funcionalidade de tiering em nuvem Azure File Sync oferece latência de acesso local em combinação com um controlo melhorado sobre a capacidade de cache disponível na instância do Windows Server e sincronização de vários locais. Se ter uma cache no local é o seu objetivo, então na sua rede local, prepare um VM do Windows Server (servidores físicos e clusters de failover também são suportados) com capacidade de armazenamento direta suficiente.

Importante

Não faça Azure File Sync ainda. É melhor configurar Azure File Sync depois da migração da sua parte estar completa. A implantação 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, terá implantado as suas contas de armazenamento e todas as ações de ficheiros Azure através delas. Também terá um recurso StorSimple Data Manager. Usará este último na fase 3 quando configurar os seus trabalhos de migração.

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

Esta secção descreve como configurar um trabalho de migração e mapear cuidadosamente os diretórios num volume StorSimple que deve ser copiado para o ficheiro target Azure que seleciona.

Crie e executar empregos de migração - clique para jogar!

Este vídeo cobre:

  • Criar um emprego de migração
  • Resumo
  • Origem
  • Selecionando backups de volume para migrar
  • Destino
  • Mapeamento de diretório
  • Regras semânticas
  • Executar um trabalho de migração
  • Executar definição de trabalho
  • Vendo o estado do trabalho
  • Trabalhos em paralelo
  • Interpretação dos ficheiros de registo

Para começar, vá ao seu Gestor de Dados StorSimple, encontre definições de Job no menu e selecione + Definição de trabalho. O tipo de armazenamento de alvo correto é o padrão: partilha de ficheiros Azure.

StorSimple 8000 série de trabalho de migração.

Screenshot do novo formulário de criação de emprego para um emprego migratório.

Nome da definição de emprego
Este nome deve indicar o conjunto de ficheiros que está a mover. Dar-lhe um nome semelhante ao da sua partilha de ficheiros Azure é uma boa prática.

Local onde o trabalho funciona
Ao selecionar uma região, deve selecionar a mesma região que a sua conta de armazenamento StorSimple ou, se isso não estiver disponível, então uma região próxima dela.

Origem

Assinatura de origem
Selecione a subscrição na qual armazena o seu recurso StorSimple Gestor de Dispositivos.

Recurso StorSimple
Selecione o seu StorSimple Gestor de Dispositivos o seu aparelho está registado.

Chave de encriptação de dados de serviço
Consulte esta secção anterior neste artigo caso não consiga localizar a chave nos seus registos.

Dispositivo
Selecione o seu dispositivo StorSimple que detém o volume onde pretende migrar.

Volume
Selecione o volume de origem. Mais tarde, decidirá se pretende migrar todo o volume ou subdiretórios para a partilha de ficheiros target Azure.

Backups de volume
Pode selecionar cópias de segurança de volume selecionadas para escolher cópias de segurança específicas para se mover como parte deste trabalho. Uma próxima secção dedicada neste artigo cobre o processo em detalhe.

Destino

Selecione a subscrição, a conta de armazenamento e a partilha de ficheiros Azure como alvo deste trabalho de migração.

Mapeamento de diretório

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

Selecionando backups de volume para migrar

Há aspetos importantes em torno da escolha de backups que precisam de ser migrados:

  • Os seus trabalhos de migração só podem mover backups, não dados de volume vivo. Assim, a cópia de segurança mais recente está mais próxima dos dados ao vivo e deve estar sempre na lista de backups movidos numa migração. Quando abre o diálogo de seleção de backup, é selecionado por predefinição.
  • Certifique-se de que a sua última cópia de segurança é recente para manter o delta na parte ao vivo o mais pequeno possível. Pode valer a pena ativar manualmente e completar outra cópia de segurança de volume antes de criar um trabalho de migração. Um pequeno delta para a parte ao vivo vai melhorar a sua experiência de migração. Se este delta pode ser zero = não mais alterações no volume StorSimple ocorreram depois de a cópia de segurança mais recente ter sido tomada na sua lista - então a Fase 5: O corte do utilizador será drasticamente simplificado e acelerado.
  • Os backups devem ser reproduzidos na partilha de ficheiros Azure do mais antigo ao mais recente. Um backup mais antigo não pode ser "classificado" na lista de backups na partilha de ficheiros Azure após a execução de um trabalho de migração. Por isso, deve certificar-se de que a sua lista de backups está completa antes de criar um emprego.
  • Esta lista de backups num trabalho não pode ser modificada uma vez que o trabalho é criado - mesmo que o trabalho nunca tenha sido feito.
  • Para selecionar backups, o volume StorSimple que pretende migrar tem de estar online.

Uma imagem do novo formulário de criação de emprego que detalha a parte onde são selecionadas cópias de segurança StorSimple para migração.

Para selecionar cópias de segurança do seu volume StorSimple para o seu trabalho de migração, selecione as cópias de segurança de volume Selecione no formulário de criação de emprego.

Uma imagem que mostra que a metade superior da lâmina para selecionar cópias de segurança lista todas as cópias de segurança disponíveis. Uma cópia de segurança selecionada será acinzentada nesta lista e adicionada a uma segunda lista na metade inferior da lâmina. Aí também pode ser apagado novamente.

Quando a lâmina de seleção de reserva abre, é separada em duas listas. Na primeira lista, todas as cópias de segurança disponíveis são apresentadas. Pode expandir e reduzir o resultado, filtrando para um intervalo de tempo específico. (ver secção seguinte)

Uma cópia de segurança selecionada será exibida como cinza-out e é adicionada a uma segunda lista na metade inferior da lâmina. A segunda lista apresenta todas as cópias de segurança selecionadas para migração. Uma cópia de segurança selecionada por erro também pode ser removida novamente.

Atenção

Tem de selecionar todas as cópias de segurança que pretende migrar. Não é possível adicionar cópias de segurança mais antigas mais tarde. Não é possível modificar o trabalho para alterar a sua seleção uma vez que o trabalho é criado.

Uma imagem mostrando a seleção de um intervalo de tempo da lâmina de seleção de backup.

Por predefinição, a lista é filtrada para mostrar as cópias de segurança de volume StorSimple nos últimos sete dias. A cópia de segurança mais recente é selecionada por padrão, mesmo que não tenha ocorrido nos últimos sete dias. Para cópias de segurança mais antigas, utilize o filtro de intervalo de tempo na parte superior da lâmina. Pode selecionar a partir de um filtro existente ou definir um intervalo de tempo personalizado para filtrar apenas para as cópias de segurança tomadas durante este período.

Atenção

Não é suportada a seleção de mais de 50 cópias de segurança de volume StorSimple. Empregos com um grande número de reforços podem falhar. Certifique-se de que as suas políticas de retenção de backup não apagam uma cópia de segurança selecionada antes de ter a oportunidade de ser migrada!

Mapeamento de diretório

O mapeamento de diretórios é opcional para o seu trabalho de migração. Se deixar a secção vazia, todos os ficheiros e pastas na raiz do seu volume StorSimple serão movidos para a raiz da sua partilha de ficheiros Target Azure. Na maioria dos casos, armazenar um conteúdo inteiro de volume numa partilha de ficheiros Azure não é a melhor abordagem. Muitas vezes é melhor dividir o conteúdo de um volume através de várias ações de ficheiros em Azure. Se ainda não fez um plano, consulte o seu volume StorSimple para ações de ficheiros Azure primeiro.

Como parte do seu plano de migração, pode ter decidido que as pastas de um volume StorSimple precisam de ser divididas em várias ações de ficheiros Azure. Se for esse o caso, podes conseguir essa divisão por:

  1. Definindo vários trabalhos para migrar as pastas num só volume. Cada um terá a mesma fonte de volume StorSimple, mas uma parte de ficheiro Azure diferente como o alvo.
  2. Especificando com precisão quais as pastas do volume StorSimple que devem ser migradas para a parte de ficheiros especificada, utilizando a secção de mapeamento do diretório do formulário de criação de emprego e seguindo a semântica de mapeamento específica.

Importante

Os caminhos e expressões de mapeamento desta forma não podem ser validados quando o formulário é submetido. Se os mapeamentos forem especificados incorretamente, um trabalho pode falhar completamente ou produzir um resultado indesejável. Nesse caso, normalmente é melhor apagar a partilha de ficheiros Azure, reutilá-la e, em seguida, corrigir as declarações de mapeamento num novo trabalho de migração para a parte. Executar um novo trabalho com declarações de mapeamento fixo pode corrigir pastas omitidas e trazê-las para a parte existente. No entanto, apenas as pastas que foram omitidas devido a erros ortográficos do caminho podem ser abordadas desta forma.

Elementos semânticos

Um mapeamento é expresso da esquerda para a direita: [\caminho de origem] > [\caminho alvo].

Caráter semântico Significado
\ Indicador de nível de raiz.
> [Operador de origem] e [target-mapping].
| ou RETURN (nova linha) Separador de duas instruções de mapeamento de pasta.
Em alternativa, pode omitir este personagem e selecionar Enter para obter a próxima expressão de mapeamento na sua própria linha.

Exemplos

Move o conteúdo da pasta Os dados do Utilizador para a raiz da partilha de ficheiros-alvo:

\User data > \

Move todo o conteúdo do volume para um novo caminho na partilha de ficheiros-alvo:

\ > \Apps\HR tracker

Move o conteúdo da pasta de origem para um novo caminho na partilha de ficheiros-alvo:

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

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

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

Regras semânticas

  • Especifique sempre os caminhos das pastas em relação ao nível da raiz.
  • Inicie cada caminho da pasta com um indicador de nível de raiz "\".
  • Não inclua cartas de condução.
  • Ao especificar vários caminhos, os caminhos de origem ou alvo não podem sobrepor-se:
    Exemplo de sobreposição do caminho de origem inválida:\pasta\1 > \pasta
    \1\2 \pasta 2 >
    Exemplo de sobreposição do caminho alvo inválido:
    \pasta > \pasta \
    pasta2 > \

  • As pastas de origem que não existem serão ignoradas.
  • Serão criadas estruturas de pasta que não existam no alvo.
  • Tal como o Windows, os nomes das pastas são casos insensíveis, mas preservam casos.

Nota

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

Executar um trabalho de migração

Os seus trabalhos de migração estão listados de acordo com definições de Job no recurso Data Manager que implementou para um grupo de recursos. Na lista de definições de emprego, selecione o trabalho que pretende executar.

Na lâmina de trabalho que abre, pode ver o estado atual do seu trabalho e uma lista de backups que selecionou. A lista de backups é classificada pela mais antiga para a mais recente e será migrada para a sua parte de ficheiroS Azure nesta ordem.

Screenshot da lâmina de trabalho de migração com um destaque em torno do comando para iniciar o trabalho. Também apresenta as cópias de segurança selecionadas agendadas para a migração.

Inicialmente, o trabalho de migração terá o estatuto: Nunca correu.
Quando estiver pronto, pode começar este trabalho de migração. (Selecione a imagem para uma versão com resolução mais elevada.)
Quando uma cópia de segurança foi migrada com sucesso, será tirada uma imagem automática da partilha de ficheiros Azure. A data de cópia de segurança original da sua cópia de segurança StorSimple será colocada na secção comentários do instantâneo de partilha de ficheiros Azure. A utilização deste campo permitir-lhe-á ver quando os dados foram originalmente apoiados em comparação com o tempo em que a fotografia de partilha de ficheiros foi tirada.

Atenção

Os backups devem ser processados do mais antigo ao mais novo. Uma vez criado um trabalho de migração, não é possível alterar a lista de backups de volume StorSimple selecionados. Não inicie o trabalho se a lista de backups estiver incorreta ou incompleta. Elimine o trabalho e faça um novo com as cópias de segurança corretas selecionadas. Para cada cópia de segurança selecionada, verifique os seus horários de retenção. As cópias de segurança podem ser eliminadas por uma ou mais das suas políticas de retenção antes de terem a oportunidade de serem migradas!

Erros por artigo

Os postos de trabalho em 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 ficheiros ou pastas que deveriam ter sido copiados mas não foram. Estes erros são muitas vezes recuperáveis. Quando uma cópia de segurança lista problemas de itens nesta coluna, reveja os registos de cópias. Se precisar de migrar estes ficheiros, selecione Retry backup. Esta opção ficará disponível assim que o processamento de cópia de segurança terminar. A secção de Gestão de um trabalho de migração explica mais detalhadamente as suas opções.
  • Ficheiros não suportados
    Esta coluna lista ficheiros ou pastas que não podem ser migrados. O Azure Storage tem limitações em nomes de ficheiros, comprimentos de caminho e tipos de ficheiros que atualmente ou logicamente não podem ser armazenados numa partilha de ficheiros Azure. Um trabalho de migração não para para este tipo de erros. Tentar a migração do backup não vai mudar o resultado. Quando uma cópia de segurança lista problemas de itens nesta coluna, reveja os registos de cópias e tome nota. Se tais problemas surgirem na sua última cópia de segurança e descobrir no registo de cópias que a falha se deveu a um nome de ficheiro, comprimento do caminho ou outro problema sobre o qual tenha influência, talvez queira remediar o problema no volume StorSImple ao vivo, fazer uma cópia de segurança de volume StorSimple e criar um novo trabalho de migração com apenas essa cópia de segurança. Em seguida, migrará este espaço de nome corrigido e tornar-se-á a versão mais recente/ao vivo da partilha de ficheiros Azure. Este é um processo manual e demorado. Reveja cuidadosamente os registos de cópias e avalie se vale a pena.

Estes registos de cópias são *.csv ficheiros que listam itens de espaço de nome bem sucedidos e itens que não foram copiados. Os erros dividem-se ainda mais nas categorias previamente discutidas. A partir da localização do ficheiro de registo, pode encontrar registos de ficheiros falhados procurando por "falhados". O resultado deve ser um conjunto de registos para ficheiros que não copiaram. Serdene estes troncos por tamanho. Pode haver registos extras produzidos a 17 bytes de tamanho. Estão vazios e podem ser ignorados. Com algum tipo, pode focar-se nos registos com conteúdo.

O mesmo processo aplica-se para ficheiros de registo que registam cópias bem sucedidas.

Gerir um trabalho de migração

Os postos de trabalho em migração têm os seguintes Estados:

  • Nunca correu
    Um novo emprego, que foi definido mas nunca correu antes.
  • Esperando
    Um emprego neste Estado está à espera que os recursos sejam adsteidos no serviço de migração. Mudará automaticamente para um estado diferente quando estiver pronto.
  • Falhou
    Um trabalho falhado atingiu um erro fatal que o impede de processar mais backups. Não se espera que um trabalho entre neste estado. Um pedido de apoio é o melhor caminho a seguir.
  • Cancelado /
    Cancelamento Tanto o trabalho de migração inteiro como os backups individuais dentro do trabalho podem ser cancelados. Os backups cancelados não serão processados, um trabalho de migração cancelado deixará de processar mais backups. Espere que cancelar um emprego leve muito tempo. Isto não te impede de criar um novo emprego. O melhor caminho é a paciência para deixar um trabalho chegar completamente ao estado cancelado . Pode ignorar trabalhos falhados /cancelados ou eliminá-los mais tarde. Não terá de eliminar postos de trabalho antes de poder eliminar o recurso Data Manager no final da sua migração StorSimple.

Screenshot da lâmina de trabalho de migração com um grande ícone de estado no topo no estado de execução.

Correndo

Um trabalho de corrida está atualmente a processar uma cópia de segurança. Consulte a tabela na metade inferior da lâmina para ver qual a cópia de segurança que está a ser processada e quais as que podem já ter sido migradas.
As cópias de segurança já migradas têm uma coluna com ligação a um registo de cópias. Se houver algum erro relatado para uma cópia de segurança, deverá rever o seu registo de cópia.

Screenshot da lâmina de trabalho de migração com um grande ícone de estado no topo no estado de pausa.



Pausa Um trabalho de migração é interrompido quando é necessária uma decisão. Esta condição permite dois botões de comando na parte superior da lâmina:
Escolha a cópia de segurança quando a cópia de segurança mostrar ficheiros que deveriam mover-se mas não (copiar coluna de erro ).
Escolha o backup Skip quando a cópia de segurança estiver em falta (foi eliminada pela política desde que criou o trabalho de migração) ou quando a cópia de segurança é corrupta. Pode encontrar informações detalhadas sobre erros na lâmina que se abrem quando clica na cópia de segurança falhada.

Quando saltar ou voltar a tentar a cópia de segurança atual, o serviço de migração criará uma nova imagem na partilha de ficheiros Azure do seu alvo. É possível que queira eliminar o anterior mais tarde, provavelmente está incompleto.

Uma imagem mostrando a lâmina de trabalho de migração com um grande ícone de estado no topo em todo o estado.

Completo e completo com avisos

Um trabalho de migração é listado como Completo quando todos os backups no trabalho foram processados com sucesso.
Completo com avisos é um estado que ocorre quando:

  • Um reforço teve um problema recuperável. Este backup é marcado como sucesso parcial ou falhado.
  • Decidiu continuar no trabalho de pausa, ignorando os apoios com os referidos problemas. (Escolheu o backup Skip em vez de retry backup)
Se o trabalho de migração estiver completo com avisos, deve sempre rever o registo de cópias para as cópias de segurança relevantes.

Executar empregos em paralelo

Provavelmente terá vários volumes StorSimple, cada um com as suas próprias ações que precisam de ser migradas para uma partilha de ficheiros Azure. É importante que compreenda o que se pode fazer em paralelo. Existem limitações que não são aplicadas na experiência do utilizador e que irão degradar ou inibir uma migração completa se os trabalhos forem executados ao mesmo tempo.

Não há limites para a definição de postos de trabalho na migração. Pode definir o mesmo volume de origem StorSimple, a mesma partilha de ficheiros Azure, através dos mesmos ou diferentes aparelhos 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 alvo Azure pode executar ao mesmo tempo.
  • Antes de iniciar o próximo trabalho, assegurou-se de que qualquer um dos trabalhos anteriores está no copy stage esto desatreimento dos ficheiros por pelo menos 30 minutos.
  • Pode executar até quatro postos de trabalho de migração em paralelo por gestor de dispositivos StorSimple, desde que também cumpra as regras anteriores.

Quando se tenta iniciar um trabalho de migração, as regras anteriores são verificadas. Se houver empregos a decorrer, pode não ser capaz de iniciar o trabalho atual. Receberá um alerta que lista o nome do(s) atualmente em execução que deve terminar antes de poder iniciar o novo trabalho.

Dica

É uma boa ideia verificar regularmente os seus trabalhos de migração no separador de definição de Emprego do seu recurso Data Manager , para ver se algum deles fez uma pausa e precisa da sua entrada para completar.

Resumo da fase 3

No final da Fase 3, você terá executado pelo menos um dos seus trabalhos de migração de volumes StorSimple para a ações de ficheiros Azure. Com a sua execução, terá migrado as suas cópias de segurança especificadas para as imagens de partilha de ficheiros Azure. Pode agora concentrar-se na criação de Azure File Sync para a parte (uma vez que os empregos de migração para uma parte tenham terminado) ou o acesso direto a partilhas para os seus trabalhadores de informação e apps para a partilha de ficheiros Azure.

Fase 4: Aceda às suas ações de ficheiros Azure

Existem duas estratégias principais para aceder às suas partilhas de ficheiros Azure:

  • Azure File Sync: Implementar Azure File Sync para uma instância do Windows Server no local. Azure File Sync tem todas as vantagens de uma cache local, assim como storSimple.
  • Acesso direto a partilha: Implementar acesso direto a partilha. Utilize esta estratégia se o seu cenário de acesso a uma determinada partilha de ficheiros Azure não beneficiar do caching local, ou deixar de ter a capacidade de hospedar uma instância do Windows Server no local. Aqui, os seus utilizadores e aplicações continuarão a aceder a ações SMB ao longo do protocolo SMB. Estas ações já não se encontram num servidor no local, mas diretamente na nuvem.

Já devia ter decidido qual a melhor opção para si na Fase 1 deste guia.

O restante desta secção centra-se nas instruções de implantação.

Opções de acesso para ações de ficheiros Azure - clique para jogar!

Este vídeo cobre:

  • Abordagens para aceder a ações de ficheiros Azure
  • Azure File Sync
  • Acesso direto a partilhas
  • Implantação de Azure File Sync
  • Implementar o recurso Azure File Sync nuvem
  • Implementar uma instância do Windows Server no local
  • Preparar a instância do Servidor do Windows para sincronização de ficheiros
  • Configurar Azure File Sync na instância do Windows Server
  • Monitorização da sincronização inicial
  • Teste Azure File Sync
  • Criação das ações SMB

Implementar Azure File Sync

É hora de colocar uma parte de Azure File Sync.

  1. Crie o recurso Azure File Sync nuvem.
  2. Coloque o agente Azure File Sync no seu servidor no local.
  3. Registe o servidor com o recurso cloud.

Não crie grupos de sincronização ainda. A configuração de sincronização com uma partilha de ficheiros Azure só deverá ocorrer após os seus trabalhos de migração para uma partilha de ficheiros Azure terem terminado. Se começasse a usar Azure File Sync antes da sua migração estar concluída, tornaria a sua migração desnecessariamente difícil, uma vez que não poderia facilmente dizer quando era a hora de iniciar um corte.

Implementar o recurso Azure File Sync nuvem

Para completar este passo, precisa das suas credenciais de subscrição Azure.

O recurso principal para configurar para Azure File Sync é chamado de Serviço de Sincronização de Armazenamento. Recomendamos que implemente apenas um para todos os servidores que estejam a sincronizar o mesmo conjunto de ficheiros agora ou no futuro. Crie vários Serviços de Sincronização de Armazenamento apenas se tiver conjuntos distintos de servidores que nunca devem trocar dados. Por exemplo, pode ter servidores que nunca devem sincronizar a mesma partilha de ficheiros Azure. Caso contrário, utilizar um único Serviço de Sincronização de Armazenamento é a melhor prática.

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

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

Dica

Se quiser alterar a região Azure em que os seus dados residem após o fim da migração, implante o Serviço de Sincronização de Armazenamento na mesma região que as contas de armazenamento-alvo para esta migração.

Implementar uma instância do Windows Server no local

  • Crie o Windows Server 2019 (no mínimo 2012R2) como uma máquina virtual ou servidor físico. Um cluster de falha do Windows Server também é suportado. Não reutilizar o servidor na frente do StorSimple 8100 ou 8600.
  • Provisão ou adicionar armazenamento direto. O armazenamento ligado à rede não é suportado.

É melhor dar ao seu novo Windows Server uma quantidade igual ou maior de armazenamento do que o seu aparelho StorSimple 8100 ou 8600 tem disponível localmente para caching. Utilizará a instância do Windows Server da mesma forma que utilizou o aparelho StorSimple. Se tiver a mesma quantidade de armazenamento que o aparelho, a experiência de caching deve ser semelhante, se não a mesma. Pode adicionar ou remover o armazenamento da sua instância do Windows Server à vontade. Esta capacidade permite-lhe escalar o tamanho do volume local e a quantidade de armazenamento local disponível para o caching.

Prepare a instância do Servidor do Windows para sincronização de ficheiros

Nesta secção, instale o agente Azure File Sync na sua instância do Windows Server.

O guia de implementação explica que é necessário desligar a configuração de segurança melhorada do Internet Explorer. Esta medida de segurança não é aplicável com Azure File Sync. Desligá-lo permite-lhe autenticar para Azure sem qualquer problema.

Abra o PowerShell. Instale os módulos PowerShell necessários utilizando os seguintes comandos. Certifique-se de que instala o módulo completo e o fornecedor NuGet quando for solicitado a fazê-lo.

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

Se tiver algum problema em chegar à internet a partir do seu servidor, agora é a altura de os resolver. Azure File Sync utiliza qualquer ligação de rede disponível à internet. Exigir um servidor proxy para chegar à internet também é suportado. Pode configurar agora um representante de uma máquina ou, durante a instalação do agente, especificar um representante que apenas Azure File Sync utilizará.

Se configurar um representante significa que precisa de abrir as firewalls para o servidor, essa abordagem pode ser aceitável para si. No final da instalação do servidor, depois de ter concluído o registo do servidor, um relatório de conectividade de rede irá mostrar-lhe os URLs de ponto final exatos em Azure que Azure File Sync precisa de comunicar com a região que selecionou. O relatório também lhe diz por que razão a comunicação é necessária. Pode utilizar o relatório para bloquear as firewalls em torno do servidor para URLs específicos.

Também pode ter uma abordagem mais conservadora na qual não abra as firewalls. Em vez disso, pode limitar o servidor a comunicar com espaços de nome DNS de nível superior. Para obter mais informações, consulte Azure File Sync configurações de procuração e firewall. Siga as suas próprias práticas de networking.

No final do assistente de instalação do servidor, será aberto um assistente de registo do servidor. Registe o servidor no recurso Azure do Seu Serviço de Sincronização de Armazenamento a partir de anteriormente.

Estes passos são descritos com mais detalhe no guia de implantação, que inclui os módulos PowerShell que deve instalar primeiro: Azure File Sync instalação do agente.

Usa o último agente. Você pode descarregá-lo a partir do Microsoft Download Center: Azure File Sync Agent.

Após uma instalação e registo de servidor bem sucedidos, pode confirmar que completou este passo com sucesso. Aceda ao recurso de Serviço de Sincronização de Armazenamento no portal do Azure. No menu esquerdo, aceda aos servidores registados. Verá o seu servidor listado lá.

Configurar Azure File Sync na instância do Servidor do Windows

A sua instância registada no Windows Server deve estar pronta e ligada à internet para este processo.

Importante

A sua migração StorSimple de ficheiros e pastas para a partilha de ficheiros Azure tem de estar completa antes de prosseguir. Certifique-se de que não há mais alterações na partilha de ficheiros.

Este passo une todos os recursos e pastas que definiu na sua instância do Windows Server durante os passos anteriores.

  1. Inicie sessão no portal do Azure.
  2. Localize o seu recurso de Serviço de Sincronização de Armazenamento.
  3. Crie um novo grupo de sincronização dentro do recurso Storage Sync Service para cada partilha de ficheiros Azure. Em Azure File Sync terminologia, a partilha de ficheiros Azure tornar-se-á um ponto final em nuvem na topologia sincronizada que está descrevendo com a criação de um grupo de sincronização. Quando criar o grupo de sincronização, dê-lhe um nome familiar para que reconheça qual o conjunto de ficheiros que sincroniza. Certifique-se de que faz referência à partilha de ficheiros Azure com um nome correspondente.
  4. Depois de criar o grupo de sincronização, aparecerá uma linha para que ele apareça na lista de grupos de sincronização. Selecione o nome (um link) para visualizar o conteúdo do grupo de sincronização. Verá a sua parte do ficheiro Azure nos pontos finais da Cloud.
  5. Localize o botão 'Adicionar ponto final do servidor '. A pasta no servidor local que a provisionou passará a ser o caminho para este ponto final do servidor.

Importante

Certifique-se de ligar o nível da nuvem. O tiering em nuvem é a funcionalidade Azure File Sync que permite ao servidor local ter menos capacidade de armazenamento do que é armazenado na nuvem, mas tem o espaço de nome completo disponível. Os dados locais interessantes também são cached localmente para um desempenho rápido e local de acesso. Outra razão para ligar o nível da nuvem neste passo é que não queremos sincronizar o conteúdo do ficheiro nesta fase. Só o espaço de nomes deve estar em movimento neste momento.

Implementar acesso direto a partilhas

Este vídeo é um guia e demonstração para como expor de forma segura as partilhas de ficheiros Azure diretamente a trabalhadores de informação e apps em cinco passos simples.
O vídeo refere documentação dedicada a alguns tópicos:

Resumo da fase 4

No final desta fase, criou e executou vários trabalhos de migração no seu StorSimple Data Manager. Esses trabalhos migraram os seus ficheiros e pastas e as suas cópias de segurança para as ações de ficheiros do Azure. Também implementou Azure File Sync ou preparou as suas contas de rede e armazenamento para acesso direto a partilha.

Fase 5: Corte do utilizador

Esta fase tem tudo a ver com o final da sua migração:

  • Planeie o seu tempo de descanso.
  • Acompanhe quaisquer alterações que os seus utilizadores e aplicações tenham produzido no lado StorSimple enquanto os trabalhos de migração na Fase 3 estão em execução.
  • Falhe em relação aos seus utilizadores na nova instância do Windows Server com Azure File Sync ou nas ações de ficheiros Azure através de acesso direto à partilha.

Passos para cortar uma carga de trabalho para ações de ficheiros Azure - clique para jogar!

Este vídeo cobre:

  • Passos a tomar antes do corte da sua carga de trabalho
  • Executando o seu corte
  • Passos de corte pós-corte

Planeie o seu tempo de inatividade

Esta abordagem de migração requer algum tempo de inatividade para os seus utilizadores e aplicações. O objetivo é manter o tempo de inatividade ao mínimo. As seguintes considerações podem ajudar:

  • Mantenha os seus volumes StorSimple disponíveis enquanto executa os seus trabalhos de migração.
  • Quando terminar de executar os seus trabalhos de migração de dados por uma parte, é hora de remover o acesso do utilizador (pelo menos escrever acesso) dos volumes ou partilhas StorSimple. Um RoboCopy final irá apanhar a sua parte de ficheiros Azure. Depois pode cortar os seus utilizadores. Onde você dirige RoboCopy depende se você escolheu usar Azure File Sync ou acesso direto a partilha. A próxima secção do RoboCopy cobre este assunto.
  • Depois de ter concluído a atualização do RoboCopy, está pronto para expor a nova localização aos seus utilizadores através da partilha de ficheiros Azure diretamente ou de uma partilha SMB numa instância do Windows Server com Azure File Sync. Muitas vezes, uma implementação DFS-N ajudará a realizar um corte de forma rápida e eficiente. Manterá os seus endereços de ações existentes consistentes e repontará para um novo local que contenha os seus ficheiros e pastas migrados.

Para os dados de arquivo, é uma abordagem totalmente viável para tirar tempo de inatividade no seu volume StorSimple (ou subclasse), fazer mais uma cópia de segurança do volume StorSimple, migrar e, em seguida, abrir o destino de migração para acesso por utilizadores e apps. Isto irá poupar-lhe a necessidade de um RoboCopy de recuperação, conforme descrito nesta secção. No entanto, esta abordagem tem o custo de uma janela de tempo de inatividade prolongada que pode estender-se por vários dias ou mais, dependendo do número de ficheiros e cópias de segurança que precisa para migrar. Esta é provavelmente apenas uma opção para cargas de trabalho de arquivo que podem passar sem escrever acesso por longos períodos de tempo.

Determine quando o seu espaço de nome está totalmente sincronizado com o seu servidor

Quando utiliza Azure File Sync para uma partilha de ficheiros Azure, é importante que determine que todo o seu espaço de nome terminou de descarregar para o servidor antes de iniciar qualquer RoboCopy local. O tempo que leva para descarregar o seu espaço de nome depende do número de itens na sua partilha de ficheiros Azure. Existem dois métodos para determinar se o seu espaço de nome chegou completamente ao servidor.

Portal do Azure

Você pode usar o portal do Azure para ver quando o seu espaço de nome chegou completamente.

  • Inscreva-se no portal do Azure e vá para o seu grupo de sincronização. Verifique o estado de sincronização do seu grupo de sincronização e ponto final do servidor.
  • A direção interessante é o download. Se o ponto final do servidor for recentemente provisionado, mostrará a sincronização inicial, o que indica que o espaço de nome ainda está a descer. Depois de este estado mudar para qualquer coisa menos sincronização inicial, o seu espaço de nome será totalmente povoado no servidor. Agora pode prosseguir com um RoboCopy local.

Visualizador de Eventos do servidor do Windows

Também pode utilizar o Visualizador de Eventos na sua instância do Windows Server para saber quando o espaço de nome chegou completamente.

  1. Abra o Visualizador de Eventos e vá a Aplicações e Serviços.
  2. Vá e abra Microsoft\FileSync\Agente\Telemetria.
  3. Procure o mais recente evento 9102, que corresponde a uma sessão de sincronização completa.
  4. Selecione Detalhes e confirme que está a olhar para um evento onde o valor SyncDirection é Download.
  5. Para o momento em que o seu espaço de nome tiver concluído o download para o servidor, haverá um único evento com Scenario, o valor FullGhostedSync e HResult = 0.
  6. Se perder esse evento, também pode procurar outros eventos 9102 com SyncDirection = Download e Scenario = "RegularSync". Encontrar um destes eventos também indica que o espaço de nomes terminou o download e a sincronização progrediu para sessões regulares de sincronização, quer haja algo para sincronizar ou não neste momento.

Um RoboCopy final

Neste momento, existem diferenças entre a sua instância do Windows Server no local e o aparelho StorSimple 8100 ou 8600.

  1. É necessário acompanhar as alterações que os utilizadores ou apps produziram no lado StorSimple enquanto a migração estava em curso.
  2. Para os casos em que utiliza Azure File Sync: O aparelho StorSimple tem uma cache povoada contra a instância do Windows Server com apenas um espaço de nome sem nenhum conteúdo de ficheiro armazenado localmente neste momento. O RoboCopy final pode ajudar a iniciar o seu cache de Azure File Sync local, puxando o conteúdo de ficheiros em cache local tanto quanto está disponível e pode caber no servidor Azure File Sync.
  3. Alguns ficheiros podem ter sido deixados para trás pelo trabalho de migração por causa de personagens inválidos. Em caso afirmativo, copie-os para a instância do Windows Server ativada pelo Azure File Sync. Mais tarde, podes ajustá-los para que se sincronizem. Se não utilizar Azure File Sync para uma determinada parte, é melhor renomear os ficheiros com caracteres inválidos no volume StorSimple. Em seguida, executar o RoboCopy diretamente contra a partilha de ficheiros Azure.

Aviso

Robocopia no Windows Server 2019 vive atualmente um problema que fará com que os ficheiros de Azure File Sync no servidor alvo sejam recopiados a partir da fonte e re-carregados para Azure ao utilizar a função /MIR de robocopia. É imperativo que utilize robocopia num Servidor windows diferente de 2019. Uma escolha preferida é Windows Server 2016. Esta nota será atualizada caso a questão seja resolvida através de Windows Update.

Aviso

Não deve iniciar o RoboCopy antes que o servidor tenha o espaço de nome para uma partilha de ficheiros Azure descarregada na totalidade. Para mais informações, consulte Determine quando o seu espaço de nome foi totalmente descarregado para o seu servidor.

Só queres copiar ficheiros que foram alterados depois do trabalho de migração ter sido feito pela última vez e ficheiros que nunca tinham passado por estes empregos. Pode resolver o problema por que não se moveram mais tarde no servidor, depois de a migração estar completa. Para mais informações, consulte Azure File Sync resolução de problemas.

RoboCopy tem vários parâmetros. O exemplo a seguir mostra um comando acabado e uma lista de razões para escolher estes 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 n é 8. O máximo é de 128 threads. Embora uma contagem de fios elevados ajude a saturar a largura de banda disponível, não significa que a sua migração será sempre mais rápida com mais fios. Os testes com Ficheiros do Azure indicam que entre 8 e 20 mostram um desempenho equilibrado para uma primeira execução de cópia. As execuções subsequentes /MIR são progressivamente afetadas pelo cálculo disponível vs largura de banda 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. Os testes com Ficheiros do Azure mostraram que até 64 fios produzem um bom desempenho, mas onl se os seus processadores podem mantê-los vivos ao mesmo tempo.
/R:n Contagem máxima de novas tentativas para um ficheiro cuja cópia falhou na primeira tentativa. A Robocopia tentará n os tempos antes que o ficheiro falhe permanentemente na execução. Pode otimizar o desempenho da sua execução: Escolha um valor de dois ou três se acreditar que problemas de tempo limite causaram falhas no passado. Isto pode ser mais comum sobre as ligações WAN. Escolha não tentar novamente ou um valor de um se acreditar que o ficheiro não copiou porque estava ativamente a ser utilizado. Tentar novamente alguns segundos depois pode não ser tempo suficiente para o estado de utilização do ficheiro mudar. Os utilizadores ou aplicações que mantêm o ficheiro aberto podem precisar de mais horas de tempo. Neste caso, aceitar o ficheiro não foi copiado e apanhá-lo numa das suas execuções planeadas e subsequentes de Robocopia, pode eventualmente conseguir copiar o ficheiro com sucesso. Isso ajuda a corrente a terminar mais rapidamente sem ser prolongada por muitas retrações que acabam por acabar na maioria das falhas de cópia devido a ficheiros ainda abertos após o tempo limite de retençã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 para esperar entre as retrósries. /W:n é frequentemente usado juntamente 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. O interruptor de reserva depende da execução do comando Robocopy numa consola elevada de administrador ou na janela PowerShell. Se utilizar robocopia para Ficheiros do Azure, certifique-se de que monta a partilha de ficheiros Azure utilizando a chave de acesso à conta de armazenamento vs. uma identidade de domínio. Se não o fizer, as mensagens de erro podem 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. A correspondência significa copiar do nível de origem e pasta correto para o nível de pasta correspondente no alvo. Só, assim, é que uma cópia “atualizada” pode ter êxito. Quando a fonte e o alvo são desajustados, a utilização /MIR levará a supressões e recopies em larga escala.
/IT Garante que a fidelidade é preservada em determinados cenários de espelhamento.
Por exemplo, se um ficheiro registar uma alteração da ACL e uma atualização de atributos entre duas execuções do Robocopy, será marcado como oculto. Sem /IT, a alteração da ACL pode ser perdida pela Robocopy e não transferida para o local alvo.
/COPY:[copyflags] A fidelidade da cópia do ficheiro. Predefinição: /COPY:DAT. Bandeiras de cópia: D= Dados, A= Atributos, T= Selos temporais, S= Segurança = NTFS ACLs, O= Informação do proprietário, U= Auditing informações. As informações de auditoria não podem ser armazenadas numa partilha de ficheiros do Azure.
/DCOPY:[copyflags] Fidelidade para a cópia dos diretórios. Predefinição: /DCOPY:DA. Copiar bandeiras: D= Dados, A= Atributos, T= Timetamps.
/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 diretórios a excluir. Ao executar robocopia na raiz de um volume, considere excluir a pasta escondida System Volume Information . Se for utilizada como concebida, todas as informações aí são específicas do volume exato deste sistema exato e podem ser reconstruídas a pedido. Copiar estas informações não será útil na nuvem ou quando os dados são 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> Escreve o estado no ficheiro de registo como Unicode. (Substitui o diário de bordo existente.)
/L Apenas para um teste
Os ficheiros só devem ser listados. Não serão copiados, nem eliminados e não terão nenhum carimbo de data/hora. Frequentemente usado para /TEE a saída da consola. As bandeiras do guião da amostra, como /NP, /NFLe /NDL, podem precisar de ser removidas para obter os resultados dos testes devidamente documentados.
/LFSM Só para destinos com armazenamento escalonado. Não suportado quando o destino é uma participação remota da SMB.
Especifica que a Robocopy funciona em "modo de espaço livre baixo". Este interruptor é útil apenas para alvos com armazenamento hierárquico que pode ficar sem capacidade local antes de Robocopy terminar. 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, nMBou nGB. Se /LFSM for especificado sem valor explícito do piso, o piso é definido para 10% do tamanho do volume de destino. O modo de espaço livre de baixa escasseia não é compatível com /MT, /EFSRAWou /ZB. /B O suporte foi adicionado no Windows Server 2022. Consulte a secção Windows Server 2022 e RoboCopy LFSM abaixo para obter mais informações, incluindo detalhes sobre um bug e solução alternativa.
/Z Use cautelosamente
Copia ficheiros no modo de reinício. Esta opção só é recomendada num ambiente de rede instável. Reduz significativamente o desempenho da cópia devido ao registo extra.
/ZB Use cautelosamente
Utiliza o modo de reinício. 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 a utilização de um Windows Server 2022. Ao utilizar um Windows Server 2019, certifique-se de que está instalado o mais recente nível de correção ou, pelo menos, a atualização de SISTEMA KB5005103 . Contém correções importantes para certos cenários de Robocopia.

Ao configurar as localizações de origem e alvo do comando RoboCopy, certifique-se de que revê a estrutura da fonte e do alvo para garantir que correspondem. Se usou a característica de mapeamento de diretórios do trabalho de migração, a sua estrutura de diretório de raiz pode ser diferente da estrutura do seu volume StorSimple. Se for esse o caso, podes precisar de vários empregos da RoboCopy, um para cada subdiretração. Se não tiver a certeza se o comando funcionará como esperado, pode utilizar o parâmetro /L , que simulará o comando sem realmente efetuar quaisquer alterações.

Este comando RoboCopy utiliza /MIR, por isso não move ficheiros que são os mesmos (ficheiros hierárquicos, por exemplo). Mas se errar na origem e no caminho-alvo, o /MIR também purga estruturas de diretório na sua instância do Windows Server ou na partilha de ficheiros Azure que não estão presentes no caminho de origem StorSimple. Eles devem corresponder exatamente ao trabalho roboCopy para alcançar o objetivo pretendido de atualizar o seu conteúdo migrado com as últimas alterações feitas enquanto a migração está em curso.

Consulte o ficheiro de registo roboCopy para ver se os ficheiros foram deixados para trás. Se existirem problemas, corrija-os e reexecute o comando RoboCopy. Não desprovisione quaisquer recursos StorSimple antes de corrigir problemas pendentes para ficheiros ou pastas que lhe interessam.

Se não utilizar Azure File Sync para cache a partilha de ficheiros Azure em questão, mas optou pelo acesso direto à partilha:

  1. Monte a sua partilha de ficheiros Azure como uma unidade de rede para uma máquina local do Windows.
  2. Execute o RoboCopy entre o seu StorSimple e a partilha de ficheiros Azure montado. Se os ficheiros não copiarem, corrija os seus nomes no lado StorSimple para remover caracteres inválidos. Em seguida, re-tentar RoboCopy. O comando RoboCopy anteriormente listado pode ser executado várias vezes sem causar uma retirada desnecessária ao StorSimple.

Resolução de problemas e otimização

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

  • IOPS na origem e armazenamento de alvos
  • a largura de banda disponível entre a fonte e o alvo
  • a capacidade de processar rapidamente ficheiros e pastas num espaço de nome
  • o número de alterações entre RoboCopy corre
  • o tamanho e número de ficheiros que precisa de copiar

IOPS e considerações de largura de banda

Nesta categoria, você precisa considerar as habilidades do armazenamento de origem, o armazenamento do alvo e a rede que os liga. A produção máxima possível é determinada 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 a cópia o mais rápido possível seja muitas vezes mais desejada, considere a utilização da sua rede local e do aparelho NAS para outras tarefas, muitas vezes críticas ao negócio.

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

  • Considere quando é melhor no seu ambiente executar migrações: durante o dia, fora de horas ou durante os fins de semana.
  • Considere também o QoS de rede num Servidor do Windows para acelerar a velocidade do RoboCopy.
  • Evite trabalhos desnecessários para as ferramentas de migração.

A RoboCopy pode inserir atrasos inter-pacotes especificando o /IPG:n interruptor onde n é medido em milissegundos entre pacotes RoboCopy. A utilização deste interruptor pode ajudar a evitar a monopolização de recursos em dispositivos constrangidos da IO e em ligações de rede lotadas.

/IPG:n não pode ser usado para um estrangulamento preciso da rede a um certo Mbps. Utilize o QoS da Rede de Servidor do Windows. A RoboCopy baseia-se inteiramente no protocolo SMB para todas as necessidades de networking. A utilização do SMB é a razão pela qual o RoboCopy não pode influenciar a própria produção da rede, mas pode abrandar o seu uso.

Uma linha de pensamento semelhante aplica-se ao IOPS observado no NAS. O tamanho do cluster no volume NAS, tamanhos de pacotes e uma variedade de outros fatores influenciam o IOPS observado. Introduzir atrasos inter-pacotes é muitas vezes a forma mais fácil de controlar a carga no NAS. Teste vários valores, por exemplo, de cerca de 20 milissegundos (n=20) a múltiplos desse número. Uma vez que introduza um atraso, pode avaliar se as suas outras aplicações podem agora funcionar como esperado. Esta estratégia de otimização permitir-lhe-á encontrar a velocidade ideal do RoboCopy no seu ambiente.

Velocidade de processamento

O RoboCopy vai atravessar o espaço de nome a que está apontado e avaliar cada ficheiro e pasta para cópia. Cada ficheiro será avaliado durante uma cópia inicial e durante as cópias de atualização. Por exemplo, repetições de RoboCopy /MIR contra os mesmos locais de armazenamento de fonte e alvo. Estas repetições são úteis para minimizar o tempo de inatividade para utilizadores e apps, e para melhorar a taxa de sucesso geral dos ficheiros migrados.

Muitas vezes, não consideramos a largura de banda como o fator mais limitativo numa migração - o que pode ser verdade. Mas a capacidade de enumerar um espaço de nome pode influenciar o tempo total de cópia ainda mais para espaços de nome maiores com ficheiros menores. Considere que copiar 1 TiB de pequenos ficheiros levará consideravelmente mais tempo do que copiar 1 TiB de menos, mas maiores ficheiros, assumindo que todas as outras variáveis permanecem as mesmas. Portanto, pode sofrer uma transferência lenta se estiver a migrar um grande número de pequenos ficheiros. Este é um comportamento esperado.

A causa para esta diferença é o poder de processamento necessário para andar por um espaço de nome. O RoboCopy suporta cópias com vários fios através do /MT:n parâmetro onde n significa o número de fios a utilizar. Assim, ao fornecer uma máquina especificamente para roboCopy, considere o número de núcleos de processador e a sua relação com a contagem de fios que eles fornecem. Mais comum são dois fios por núcleo. A contagem de núcleo e de rosca de uma máquina é um ponto de dados importante para decidir que valores /MT:n multi-thread deve especificar. Considere também quantos empregos robocopia você pretende executar em paralelo numa determinada máquina.

Mais fios copiarão o nosso exemplo 1-TiB de pequenos ficheiros consideravelmente mais rápidos do que menos fios. Ao mesmo tempo, o investimento extra de recursos no nosso 1 TiB de ficheiros maiores pode não trazer benefícios proporcionais. Uma contagem de fios elevados tentará copiar mais dos grandes ficheiros em simultâneo na rede. Esta atividade extra de rede aumenta a probabilidade de ser constrangido por IOPS de produção ou armazenamento.

Durante um primeiro RoboCopy num alvo vazio ou numa execução diferencial com muitos ficheiros alterados, é provável que esteja limitado pela sua produção de rede. Comece com uma contagem de threads elevada na execução inicial. Uma contagem elevada de fios, mesmo para além dos fios atualmente disponíveis na máquina, ajuda a saturar a largura de banda disponível. As execuções subsequentes /MIR são progressivamente impactadas pelo processamento de itens. Menos alterações numa execução diferencial significam menos transporte de dados sobre a rede. A sua velocidade está agora mais dependente da sua capacidade de processar itens de espaço de nome do que movê-los para a ligação de rede. Para execuções posteriores, combine o valor da contagem de fios com a contagem do núcleo do processador e a contagem de roscas por núcleo. Considere se os núcleos precisam de ser reservados para outras tarefas que um servidor de produção pode ter.

Dica

Regra do polegar: A primeira execução do RoboCopy, que irá mover muitos dados de uma rede de latência superior, beneficia do excesso de aprovisionamento da contagem de fios (/MT:n). As execuções subsequentes copiarão menos diferenças e é mais provável que se desloque da produção de rede limitada para computação limitada. Nestas circunstâncias, é frequentemente melhor combinar a contagem de fios RoboCopy com os fios realmente disponíveis na máquina. O excesso de provisão nesse cenário pode levar a mais mudanças de contexto no processador, possivelmente abrandando a sua cópia.

Evitar trabalhos desnecessários

Evite alterações em larga escala no seu espaço de nome. Por exemplo, mover ficheiros entre diretórios, alterar propriedades em larga escala ou alterar permissões (NTFS ACLs). Especialmente as alterações da ACL podem ter um impacto elevado porque muitas vezes têm um efeito de mudança em cascata em ficheiros mais baixos na hierarquia da pasta. As consequências podem ser:

  • tempo de funcionamento de trabalho prolongado roboCopy porque cada ficheiro e pasta afetados por uma alteração ACL precisa de ser atualizado
  • reutilização de dados movidos mais cedo pode ter de ser recopitado. Por exemplo, mais dados terão de ser copiados quando as estruturas das pastas mudarem depois de os ficheiros já terem sido copiados anteriormente. Um trabalho de RoboCopy não pode "reproduzir" uma mudança no espaço de nome. O próximo trabalho deve purgar os ficheiros previamente transportados para a estrutura da pasta antiga e carregar novamente os ficheiros na nova estrutura da pasta.

Outro aspeto importante é utilizar eficazmente a ferramenta RoboCopy. Com o script RoboCopy recomendado, irá criar e guardar um ficheiro de registo para erros. Podem ocorrer erros de cópia - isto é normal. Estes erros muitas vezes tornam necessário executar várias rondas de uma ferramenta de cópia como roboCopy. Uma execução inicial, por exemplo, de um NAS para o DataBox ou de um servidor para uma partilha de ficheiros Azure. E uma ou mais corridas extra com o interruptor /MIR para capturar e revassar ficheiros que não foram copiados.

Você deve estar preparado para executar várias rondas de RoboCopy contra um determinado âmbito de espaço de nome. As sucessivas corridas terminarão mais rapidamente, uma vez que têm menos para copiar, mas são cada vez mais limitadas pela velocidade de processamento do espaço de nome. Quando fizer várias rondas, pode acelerar cada ronda sem que o RoboCopy tente de forma irracional para copiar tudo numa determinada corrida. Estes interruptores RoboCopy podem fazer uma diferença significativa:

  • /R:n n = quantas vezes se recandid copiar um ficheiro falhado e
  • /W:n n = quantos segundos para esperar entre retróstas

/R:5 /W:5 é uma definição razoável que pode ajustar ao seu gosto. Neste exemplo, um ficheiro falhado será novamente julgado cinco vezes, com um tempo de espera de cinco segundos entre as recaídas. Se o ficheiro 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 sucesso desta forma.

Windows Server 2022 e RoboCopy LFSM

O interruptor /LFSM RoboCopy pode ser utilizado para evitar que um trabalho roboCopy falhe com um erro total de volume . A RoboCopy fará uma pausa sempre que uma cópia de ficheiro faria com que o espaço livre do volume de destino passasse abaixo de um valor de "piso".

Utilize roboCopy com o Windows Server 2022. Apenas esta versão do RoboCopy contém importantes correções de bugs e funcionalidades que tornam o interruptor compatível com bandeiras adicionais necessárias na maioria das migrações. Por exemplo, compatibilidade com a /B bandeira.

/B executa roboCopy no mesmo modo que uma aplicação de backup usaria. Este switch permite ao RoboCopy mover ficheiros para os para os qual o utilizador atual não tem permissões.

Normalmente, o RoboCopy pode ser executado na Fonte, Destino ou numa terceira máquina.

Importante

Se pretender utilizar/LFSM, o RoboCopy tem de ser executado no Azure File Sync-alvo do Windows Server 2022.

Note também que com /LFSM você também deve usar um caminho local para o destino, e não um caminho UNC. Por exemplo, como caminho de destino deve utilizar E:\Nome de pasta 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 com a contagem de erros por ficheiro. Aplicar a seguinte solução.

As bandeiras recomendadas /R:2 /W:1 aumentam a probabilidade de um ficheiro falhar devido a uma /LFSM pausa induzida. Neste exemplo, um ficheiro que não foi copiado após 3 pausas porque /LFSM causou a pausa, fará com que o RoboCopy falhe incorretamente no ficheiro. A solução para isto é usar valores mais elevados para /R:n e /W:n. Um bom exemplo é /R:10 /W:1800 (10 retríssis de 30 minutos cada). Isto deve dar ao Azure File Sync tempo de algoritmo de tiering para criar espaço no volume de destino.

Este bug foi corrigido mas a correção ainda não está disponível ao público. Consulte este parágrafo para obter atualizações sobre a disponibilidade da correção e como implementá-la.

Corte de utilizador

Se utilizar Azure File Sync, é provável que tenha de criar as ações SMB nessa instância do Windows Server ativada por Azure File Sync que correspondam às ações que tinha nos volumes StorSimple. Pode carregar este passo e fazê-lo mais cedo para não perder tempo aqui. Mas tem de garantir que antes deste ponto, ninguém tem acesso para causar alterações na instância do Windows Server.

Se tiver uma implementação DFS-N, pode apontar o DFN-Namespaces para as novas localizações da pasta do servidor. Se não tiver uma implementação DFS-N e tiver frontal o seu aparelho 8100 ou 8600 localmente com uma instância do Windows Server, pode retirar esse servidor do domínio. Em seguida, junte-se ao seu novo Azure File Sync-activado exemplo do Windows Server. Durante esse processo, dê ao servidor o mesmo nome do servidor e partilhe nomes como o servidor antigo para que o cut-over se mantenha transparente para os seus utilizadores, política de grupo e scripts.

Saiba mais sobre o DFS-N.

Fase 6: Deprovisionamento

Ao desprovisionar um recurso, perde-se o acesso à configuração desse recurso e aos seus dados. A desprovisionamento não pode ser desfeita. Não prossiga até confirmar que:

  • A sua migração está completa.
  • Não existem dependências nos ficheiros, pastas ou cópias de segurança de volume StorSimple que está prestes a desprovisionar.

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

  1. Desprovisionar o seu recurso StorSimple Data Manager através do portal do Azure. Todos os seus trabalhos de DTS serão apagados com ele. Não conseguirá recuperar facilmente os registos de cópias. Se forem importantes para os seus registos, recupere-os antes de desprovisionar.
  2. Certifique-se de que os seus aparelhos físicos StorSimple foram migrados e, em seguida, não os registre. Se não tens a certeza de que foram migrados, não prossigas. Se desprovisionar estes recursos enquanto ainda forem necessários, não conseguirá recuperar os dados ou a sua configuração.
    Opcionalmente, pode primeiro desprovisionar o recurso de volume StorSimple, que irá limpar os dados do aparelho. Este processo pode demorar vários dias e não vai eliminar os dados do aparelho. Se isto for importante para si, manuseie o disco a zeros separadamente da desprovisionamento de recursos e de acordo com as suas políticas.
  3. Se não houver mais dispositivos registados num Gestor de Dispositivos StorSimple, pode proceder à remoção desse Gestor de Dispositivos próprio recurso.
  4. Está na hora de apagar a conta de armazenamento StorSimple em Azure. Mais uma vez, pare e confirme que a sua migração está completa e que nada e ninguém depende destes dados antes de prosseguir.
  5. Desligue o aparelho físico StorSimple do seu centro de dados.
  6. Se possuir o aparelho StorSimple, é livre de o reciclar para PC. Se o seu dispositivo for alugado, informe o locador e devolva o dispositivo conforme apropriado.

A sua migração está completa.


Nota

Ainda tem perguntas ou encontrou algum problema?
Estamos aqui para ajudar: Email endereço numa palavra: Ficheiros do Azure migração no microsoft dot com

Resolução de problemas

Ao utilizar o serviço de migração StorSimple Data Manager, um trabalho de migração inteiro ou ficheiros individuais podem falhar por várias razões. A secção de fidelidade de ficheiros 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 consegui encontrar uma cópia de segurança para os parâmetros especificados A cópia de segurança selecionada para o trabalho não é encontrada no momento da "Estimativa" ou "Cópia". Certifique-se de que a cópia de segurança ainda está presente no catálogo de backup StorSimple. Por vezes, as políticas automáticas de retenção de backups eliminam backups entre selecioná-los para migração e, na verdade, executar o trabalho de migração para este backup. Considere desativar quaisquer horários de retenção de reserva antes de iniciar uma migração.

Estimativa Configure computação
Instalação de chaves de encriptação falhou A sua chave de encriptação de dados de serviço está incorreta. Reveja a secção chave de encriptação neste artigo para obter mais detalhes e ajude a recuperar a chave correta.
Erro do lote É possível que o arranque de todas as infraestruturas internas necessárias para a realização de uma migração se desmente. Vários outros serviços estão envolvidos neste processo. Estes problemas resolvem-se geralmente quando se tenta voltar a gerir o trabalho.
O Gerente StorSimple encontrou um erro interno. Aguarde alguns minutos e tente a operação novamente. Se o problema persistir, contacte Suporte da Microsoft. (Código de erro: 1074161829) Este erro genérico tem múltiplas causas, mas uma possibilidade encontrada é que o gestor de dispositivos StorSimple atingiu o limite de 50 aparelhos. Verifique se os trabalhos mais recentemente executados no gestor de dispositivos começaram subitamente a falhar com este erro, o que sugere que este é o problema. A mitigação para esta questão em particular é remover quaisquer aparelhos StorSimple 8001 offline criados e utilizados pelo Serviço de Gestor de Dados. Pode arquivar um bilhete de suporte ou eliminá-lo manualmente no portal. Certifique-se de que só apaga os aparelhos da série 8001 offline.
Estimativa de Ficheiros Trabalho de volume de clone falhou Este erro indica que especificou uma cópia de segurança que foi de alguma forma corrompida. O serviço de migração não pode montar ou ler. Pode experimentar a cópia de segurança manualmente ou abrir um bilhete de apoio.
Não pode prosseguir como o volume está no formato não-NTFS Apenas os volumes NTFS, não ativados, podem ser utilizados pelo serviço de migração. Se tiver um volume formatado de forma diferente, como o ReFS ou um formato de terceiros, o serviço de migração não será capaz de migrar este volume. Consulte a secção de limitações conhecidas .
Contacte o suporte. Nenhuma divisória adequada encontrada no disco O disco StorSimple que supostamente tem o volume especificado para a migração não parece ter uma partição para o dito volume. Isso é invulgar e pode indicar uma corrupção ou um mau alinhamento da gestão. A sua única opção para investigar mais aprofundadamente este assunto é arquivar um bilhete de apoio.
Esgotado A fase de estimativa que falha com um tempo limite é normalmente um problema quer com o aparelho StorSimple, quer com a fonte Volume Backup a ser lenta e às vezes até mesmo corrupta. Se a ree executá-lo não funcionar, então arquivar um bilhete de apoio é o seu melhor curso de ação.
Não consegui encontrar o caminho>
do arquivo <não conseguiu encontrar uma parte do caminho
A definição de trabalho permite-lhe fornecer um sub-caminho de origem. Este erro é mostrado quando esse caminho não existe. Por exemplo: \Share1 > \Share\Share1
Neste exemplo, especificou \Share1 como um sub-caminho na fonte, mapeando para outro sub-caminho no alvo. No entanto, o caminho de origem não existe (foi mal escrito?). Nota: O Windows está a preservar o caso, mas não é dependente de casos. O que significa que especificar \Share1 e \share1 é equivalente. Além disso, os caminhos-alvo que não existem serão automaticamente criados.
Este pedido não está autorizado a realizar esta operação Este erro mostra quando a conta de armazenamento StorSimple de origem ou a conta de armazenamento alvo com a partilha de ficheiros Azure tem uma definição de firewall ativada. Deve permitir o tráfego sobre o ponto final público e não restringi-lo com novas regras de firewall. Caso contrário, o Serviço de Transformação de Dados não poderá aceder a qualquer conta de armazenamento, mesmo que a tenha autorizado. Desative quaisquer regras de firewall e re-executar o trabalho.
Ficheiros de cópia A conta que está a ser acedida não suporta HTTP Este é um Ficheiros do Azure inseto que está a ser corrigido. A mitigação temporária consiste em desativar o encaminhamento de internet na conta de armazenamento do alvo ou utilizar o ponto final de encaminhamento Microsoft.
A parte especificada é completa Se o alvo for uma parte de ficheiro premium Azure, certifique-se de que advionou capacidade suficiente para a parte. O excesso de provisão temporária é uma prática comum. Se o alvo for uma partilha de ficheiros Azure padrão, verifique se a parte alvo tem a funcionalidade "grande partilha de ficheiros" ativada. O armazenamento padrão está a crescer à medida que se usa a parte. No entanto, se utilizar uma conta de armazenamento como alvo, poderá encontrar um limite de 5 000% de partilha tiB. Terá de ativar manualmente a função "Grande partilha de ficheiros ". Fixe os limites do alvo e re-executar o trabalho.

Erros de nível de item

Durante a fase de cópia de uma execução de trabalho de migração, os itens individuais do espaço de nome (ficheiros e pastas) podem encontrar erros. A tabela que se segue enumera os erros mais comuns e sugere opções de mitigação quando possível.

Fase Erro Mitigação
Copiar - 2146233088
o servidor está ocupado.
Recandidatura ao trabalho se houver muitos fracassos. Se houver apenas muito poucos erros, pode tentar executar o trabalho novamente, mas muitas vezes uma cópia manual dos itens falhados pode ser mais rápida. Em seguida, retomar a migração saltando para processar o próximo backup.
-2146233088
operação não pôde ser concluída dentro do prazo especificado.
Recandidatura ao trabalho se houver muitos fracassos. Se houver apenas muito poucos erros, pode tentar executar o trabalho novamente, mas muitas vezes uma cópia manual dos itens falhados pode ser mais rápida. Em seguida, retomar a migração saltando para processar o próximo backup.
Upload cronometrado ou cópia não iniciada Recandidatura ao trabalho se houver muitos fracassos. Se houver apenas muito poucos erros, pode tentar executar o trabalho novamente, mas muitas vezes uma cópia manual dos itens falhados pode ser mais rápida. Em seguida, retomar a migração saltando para processar o próximo backup.
- 2146233029
a operação foi cancelada.
Recandidatura ao trabalho se houver muitos fracassos. Se houver apenas muito poucos erros, pode tentar executar o trabalho novamente, mas muitas vezes uma cópia manual dos itens falhados pode ser mais rápida. Em seguida, retomar a migração saltando para processar o próximo backup.
1920
O ficheiro não pode ser acedido pelo sistema.
Trata-se de um erro comum quando o motor de migração encontra um ponto de reparse, ligação ou junção. Não são suportadas. Este tipo de ficheiros não podem ser copiados. Reveja a secção de limitações conhecida e a secção de fidelidade de ficheiros neste artigo.
-2147024891
Acesso é negado
Trata-se de um erro para ficheiros que são encriptados de uma forma que não podem ser acedidos no disco. Os ficheiros que podem ser lidos a partir de disco, mas que simplesmente têm conteúdo encriptado, não são afetados e podem ser copiados. A sua única opção é copiá-los manualmente. Pode encontrar tais 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 Neste caso, o ficheiro pode ser acedido mas não pode ser avaliado para cópia porque um tempotamp do qual o motor de migração depende é corrompido ou foi escrito por uma aplicação num formato incorreto. Não há muito que possa fazer, porque não pode mudar o tempo no backup. Se a conservação deste ficheiro for importante, talvez na versão mais recente (última cópia de segurança que contenha este ficheiro) copie manualmente o ficheiro, corrija a etiqueta de tempo e, em seguida, mova-o para a partilha de ficheiros target Azure. Esta opção não escala muito bem, mas é uma opção para ficheiros de alto valor onde pretende ter pelo menos uma versão retida no seu alvo.
-2146232798
Cabo seguro foi fechado
Muitas vezes um erro transitório. Recandidatura ao trabalho se houver muitos fracassos. Se houver apenas muito poucos erros, pode tentar executar o trabalho novamente, mas muitas vezes uma cópia manual dos itens falhados pode ser mais rápida. Em seguida, retomar a migração saltando para processar o próximo backup.
-2147024413
Erro de hardware do dispositivo fatal
Trata-se de um erro raro e não reportado para um dispositivo físico, mas sim para os aparelhos virtualizados da série 8001 utilizados pelo serviço de migração. O aparelho teve um problema. Os ficheiros com este erro não impedirão a migração de prosseguir para a próxima cópia de segurança. Isto dificulta-lhe a realização de uma cópia manual ou a repetição da cópia de segurança que contém ficheiros com este erro. Se os ficheiros deixados para trás forem muito importantes ou se houver um grande número de ficheiros, poderá ter de recomeçar a migração de todas as cópias de segurança. Abra um bilhete de apoio para mais investigação.
Excluir
(purga de espelhos)
O diretório especificado não está vazio. Este erro ocorre quando o modo de migração está definido para espelhar e o processo que remove os itens da partilha de ficheiros Azure deparou-se com um problema que o impedia de eliminar itens. A eliminação só acontece na parte ao vivo, não em fotografias anteriores. A supressão é necessária porque os ficheiros afetados não estão na cópia de segurança atual e, portanto, devem ser removidos da parte ao vivo antes do próximo instantâneo. Existem duas opções: Opção 1: montar a partilha de ficheiros target Azure e eliminar os ficheiros com este erro manualmente. Opção 2: pode ignorar estes erros e continuar a processar a próxima cópia de segurança com a expectativa de que o alvo não seja idêntico à fonte e tenha alguns itens extra que não estavam na cópia de segurança original do StorSimple.
Mau pedido Este erro indica que o ficheiro de origem tem certas características que não puderam ser copiadas para a partilha de ficheiros Azure. Mais notavelmente, poderia haver caracteres de controlo invisível em um nome de ficheiro ou 1 byte de um personagem de byte duplo no nome do ficheiro ou no caminho do arquivo. Pode utilizar os registos de cópias para obter nomes de caminhos, copiar os ficheiros para um local temporário, renomear os caminhos para remover os caracteres não suportados e, em seguida, robocopia novamente para a partilha de ficheiros Azure. Em seguida, pode retomar a migração saltando para o próximo backup a ser processado.

Passos seguintes