Repositório de migração de link físico

Um repositório de migração de link rígido permite que uma migração in-loco seja executada em que todo o estado do usuário é mantido no computador enquanto o sistema operacional antigo é removido e o novo sistema operacional é instalado. Essa funcionalidade é o que torna o repositório de migração de link rígido mais adequado para o cenário de atualização do computador. O uso de um repositório de migração de link rígido para um cenário de atualização de computador melhora drasticamente o desempenho da migração e reduz significativamente a utilização do disco rígido, reduz os custos de implantação e permite cenários de migração totalmente novos.

Um repositório de migração de link rígido pode ser usado quando a migração planejada atende a ambos os seguintes critérios:

  • O sistema operacional está sendo atualizado no hardware existente em vez de migrar para novos computadores.

  • O sistema operacional está sendo atualizado no mesmo volume do computador.

Um repositório de migração de link rígido não poderá ser usado se a migração planejada incluir qualquer uma das seguintes tarefas:

  • Os dados estão sendo migrados de um computador para outro.

  • Os dados estão sendo migrados de um volume em um computador para outro volume no mesmo computador, por exemplo, de C: para D:.

  • O disco que contém o repositório de migração está sendo formatado ou reparticionado fora da Instalação do Windows ou durante a Instalação do Windows.

O repositório de migração de link rígido é criado usando a opção de linha de comando, /hardlink, e é equivalente a outros tipos de repositório de migração. No entanto, ele difere porque os links físicos são utilizados para manter os arquivos armazenados no computador de origem durante a migração. Manter os arquivos no local no computador de origem elimina o trabalho redundante de duplicar arquivos. Ele também permite os benefícios de desempenho e a redução na utilização do disco que definem esse cenário.

Quando um link físico é criado, um arquivo existente recebe mais um caminho. Por exemplo, um link físico para c:\file1.txt pode ser criado chamado c:\hard link\myFile.txt. Esses dois caminhos estão relacionados ao mesmo arquivo. Se c:\file1.txt for aberto, as alterações feitas no arquivo seguido pelo arquivo que está sendo salvo, essas alterações serão vistas quando c:\hard link\myFile.txt for aberto. Se c:\file1.txt for excluído, o arquivo ainda existirá no computador como c:\hardlink\myFile.txt. Ambas as referências ao arquivo devem ser excluídas para excluir o arquivo.

Observação

Um link físico só pode ser criado para um arquivo no mesmo volume. Se um repositório de migração de link rígido for copiado para outra unidade ou dispositivo externo, os arquivos, e não os links, serão copiados, como em um cenário de repositório de migração não compactado.

Para obter mais informações sobre links físicos, consulte Links físicos e junções

Na maioria dos aspectos, um repositório de migração de link rígido é idêntico a um repositório de migração descompactado. O repositório de migração de link rígido está localizado conforme especificado pela ferramenta de linha de comandoScanState.exe. O conteúdo do repositório pode ser visualizado usando o Windows Explorer. Depois de criado, ele pode ser excluído ou copiado para outro local sem alterar o estado do usuário. A restauração de um repositório de migração de link rígido é semelhante à restauração de qualquer outro repositório de migração. No entanto, assim como na criação do repositório, a mesma funcionalidade de link físico é usada para manter os arquivos no local.

Como prática recomendada, exclua o repositório de migração de link rígido depois de confirmar que os arquivos foram migrados com êxito por meio da ferramenta LoadState . Como o LoadState cria novos caminhos para os arquivos na nova instalação de um sistema operacional Windows, a exclusão dos links físicos no repositório de migração exclui apenas um caminho para os arquivos. Ele não exclui os arquivos reais ou os caminhos para eles do novo sistema operacional.

Importante

O uso da /c opção força a ferramenta LoadState a continuar aplicando arquivos quando ocorrerem erros não fatais. Se a /c opção for usada, verifique se nenhum erro é relatado nos logs antes de excluir o repositório de migração de link rígido para evitar a perda de dados.

Manter o repositório de migração de link rígido pode resultar em consumo de espaço extra em disco ou problemas com alguns aplicativos pelos seguintes motivos:

  • Aplicativos que relatam estatísticas do sistema de arquivos, por exemplo, espaço usado e espaço livre, podem relatar incorretamente essas estatísticas enquanto o repositório de migração de link rígido estiver presente. O arquivo pode ser relatado duas vezes devido aos dois caminhos que fazem referência a esse arquivo.

  • Um vínculo físico pode perder a conexão com o arquivo original. Alguns aplicativos salvam alterações em um arquivo criando um arquivo temporário e, em seguida, renomeando o original para um nome de arquivo de backup. O caminho que não foi usado para abrir o arquivo neste aplicativo continua a se referir ao arquivo não modificado. O arquivo não modificado que não está em uso está ocupando mais espaço em disco. O repositório de migração de link rígido deve ser criado logo antes da migração ser executada. Depois que o repositório é criado, os aplicativos não devem ser usados para garantir que as versões mais recentes de todos os arquivos estejam sendo migradas.

  • Editar o arquivo usando caminhos diferentes simultaneamente pode resultar em corrupção de dados.

Importante

O atributo de arquivo somente leitura em arquivos migrados é perdido quando o repositório de migração de link rígido é excluído. Isso ocorre devido a uma limitação nos links físicos do sistema de arquivos NTFS.

Por exemplo, uma organização decide implantar a última versão com suporte do Windows em todos os seus computadores. Cada funcionário mantém o mesmo computador, mas o sistema operacional de cada computador será atualizado.

  1. Um administrador executa a ferramenta de linha de comando ScanState em cada computador, especificando a /hardlink opção de linha de comando. A ferramenta ScanState salva o estado do usuário em um repositório de migração de link fixo em cada computador, melhorando o desempenho ao reduzir a duplicação de arquivos, exceto em determinadas instâncias específicas.

    Observação

    Como prática recomendada, a Microsoft recomenda não criar o repositório de migração de link rígido até pouco antes da migração ser executada para migrar as versões mais recentes dos arquivos. Os aplicativos de software não devem ser usados no computador depois de criar o repositório de migração até que os arquivos concluam a migração com LoadState.

  2. Em cada computador, um administrador instala o SOE (ambiente operacional) padrão da organização, que inclui a versão mais recente com suporte do Windows e de outros aplicativos que a organização usa no momento.

  3. Um administrador executa a ferramenta de linha de comando LoadState em cada computador. A ferramenta LoadState restaura o estado do usuário em cada computador.

Observação

Durante a atualização de um computador ingressado no domínio, os perfis de usuários cujo SID não pode ser resolvido não serão migrados. Ao usar um repositório de migração de link rígido, isso pode causar uma perda de dados.

Esta seção fornece detalhes sobre repositórios de migração de link rígido.

Espaço no disco rígido

A /hardlink opção de linha de comando continuará com a criação do repositório de migração somente se houver 250 megabytes (MB) de espaço livre no disco rígido. Se todos os volumes envolvidos na migração estiverem formatados como NTFS, 250 MB deverão ser espaço suficiente para garantir o sucesso de quase todas as migrações de links físicos, independentemente do tamanho da migração.

Não é necessário estimar o tamanho de um repositório de migração de link rígido, pois um repositório de migração de link rígido em um volume NTFS é relativamente pequeno e requer muito menos espaço incremental do que outras opções de armazenamento. Estimar o tamanho de um repositório de migração só é útil em cenários em que o repositório de migração é grande. O único caso em que o repositório local pode ser grande com migrações de link rígido é:

  • Existe um sistema de arquivos não NTFS no sistema.
  • O sistema de arquivos não NTFS contém dados que precisam ser migrados.

Como o NTFS é o formato padrão do sistema de arquivos para todas as versões atualmente suportadas do Windows, essa situação é incomum.

Caminho do repositório de migração em vários volumes

Repositórios de migração de link rígido separados são criados em cada volume NTFS que contém dados sendo migrados. Nesse cenário, o local primário do repositório de migração é especificado na linha de comando e deve ser o volume do sistema operacional. Repositórios de migração com nomes e nomes de diretório idênticos são criados em cada volume contendo dados que estão sendo migrados. Por exemplo:

ScanState.exe /hardlink c:\USMTMIG […]

Executar esse comando em um sistema que contém o sistema operacional na unidade C: e os dados do usuário na unidade D: gera repositórios de migração nos seguintes locais, supondo que ambas as unidades sejam NTFS:

C:\USMTMIG\

D:\USMTMIG\

A unidade especificada na linha de comando para o repositório de migração de link rígido é importante, pois define onde o repositório de migração master deve ser colocado. O repositório de migração master é o local onde os dados que migram de volumes não NTFS são armazenados. Esse volume deve ter espaço suficiente para conter todos os dados provenientes de volumes não NTFS. Como em outros cenários, se um repositório de migração já existir no caminho especificado, a /o opção deverá ser usada para substituir os dados existentes no repositório.

Modificações de local

As modificações de local que redirecionam o conteúdo migrado de um volume para um volume diferente têm um efeito adverso no desempenho de uma migração de link rígido. O desempenho é afetado porque os dados de migração que devem cruzar os volumes do sistema não podem permanecer no repositório de migração de link rígido. Elas devem ser copiadas entre os volumes do sistema.

Migrando certificados e arquivos do Sistema de Arquivos com Criptografia (EFS)

Para migrar arquivos do Sistema de Arquivos com Criptografia (EFS) para uma nova instalação de um sistema operacional no mesmo volume do computador, especifique a /efs:hardlinkScanState.exe opção na sintaxe da linha de comando.

Se os arquivos EFS estiverem sendo restaurados em uma partição diferente, a /efs:copyraw opção deve ser usada em vez da /efs:hardlink opção. Links rígidos só podem ser criados para arquivos no mesmo volume. Mover os arquivos para outra partição durante a migração requer que uma cópia dos arquivos seja criada na nova partição. A /efs:copyraw opção copia os arquivos para a nova partição em formato criptografado.

Para obter mais informações, consulte Migrar arquivos e certificados EFS e Opções de arquivo criptografado.

Quando um aplicativo ou o sistema operacional tem um bloqueio em um arquivo, o arquivo é tratado de forma diferente ao usar um repositório de migração de link rígido.

Os arquivos bloqueados do sistema operacional não podem permanecer no local e devem ser copiados para o repositório de migração de link rígido. Como resultado, a seleção de muitos arquivos do sistema operacional para migração reduz significativamente o desempenho durante uma migração de link físico. Como prática recomendada, a Microsoft recomenda não migrar arquivos para fora do diretório, o que minimiza problemas \Windows relacionados ao desempenho.

Os arquivos bloqueados do aplicativo são tratados da mesma forma em migrações de link rígido como em outros cenários quando o serviço de cópia de sombra de volume não está sendo utilizado. O serviço de cópia de sombra de volume não pode ser usado com migrações de link rígido. No entanto, modificando a nova <seção HardLinkStoreControl> no Config.xml arquivo, é possível habilitar a migração de arquivos bloqueados por um aplicativo.

Importante

Há alguns cenários em que a modificação da <seção HardLinkStoreControl> no arquivo dificulta Config.xml a exclusão de um repositório de migração de link rígido. Nesses cenários, UsmtUtils.exe deve ser usado para agendar a exclusão do repositório de migração na próxima reinicialização.

Elementos XML no arquivo Config.xml

Uma nova seção no arquivo permite a Config.xml configuração opcional de alguns dos comportamentos de migração de link rígido introduzidos com a /HardLink opção.

Elemento Descrição
<Políticas> Esse elemento contém elementos que descrevem as políticas que a USMT segue ao criar um repositório de migração.
<HardLinkStoreControl> Esse elemento contém elementos que descrevem como lidar com arquivos durante a criação de um repositório de migração de link físico.
<fileLocked> Esse elemento contém elementos que descrevem como lidar com arquivos bloqueados para edição.
<createHardLink> Esse elemento define um padrão MigXML padrão que descreve caminhos de arquivo em que links físicos devem ser criados, mesmo que o arquivo esteja bloqueado para edição por outro aplicativo.

Sintaxe: <createHardLink> [padrão] </createHardLink>
<errorHardLink> Esse elemento define um padrão MigXML padrão que descreve caminhos de arquivo em que links físicos não devem ser criados, se o arquivo estiver bloqueado para edição por outro aplicativo.

<errorHardLink> [padrão] </errorHardLink>

Importante

A /nocompress opção deve ser usada com a /HardLink opção.

O exemplo de XML a seguir especifica que os \Users arquivos bloqueados por um aplicativo no diretório podem permanecer em vigor durante a migração. Ele também especifica que os arquivos bloqueados que não estão localizados no \Users diretório devem resultar no erro Arquivo em Uso . É importante ter cuidado ao especificar os caminhos usando a <createhardlink> marca para minimizar cenários que tornam o repositório de migração de link rígido mais difícil de excluir.

<Policies>
    <HardLinkStoreControl>
          <fileLocked>
            <createHardLink>c:\Users\* [*]</createHardLink>
            <errorHardLink>C:\* [*]</errorHardLink>
          </fileLocked>
    </HardLinkStoreControl>
</Policies>
  • Last updated on