No Windows: é seguro fazer uma robocópia para clonar o sistema?

Deixe-me começar dando um pouco de plano de fundo. Nos sistemas Linux, frequentemente confio no fato de que, desde que eu possa transferir todos os arquivos de um disco rígido para outro, e enquanto eu consertar o gerenciador de inicialização, ficarei com um idêntico, inicializável e totalmente sistema funcional. A mesma coisa funciona para backups e restaurações (não é necessário nenhum backup especial do estado do sistema, apenas os arquivos) ... até o MySQL é recuperável algumas vezes, mesmo quando não estava congelado no momento do backup

No Windows, nunca tive sorte em clonar o sistema fazendo isso no nível do arquivo. Eu sempre preciso de uma ferramenta como o VMWare Converter, o Ghost, o diXML, etc. Eles são baseados em tirar a imagem da unidade como um todo. No começo, eu assumi que isso era principalmente por causa da maneira especial / mágica do Windows fazer o registro e eu não questionei (funcionou). Até hoje. Percebi que esse tipo de pensamento era idiota e que, na realidade, o Windows também é apenas uma coleção de arquivos. Então, como teste, fiz uma unidade offline do servidor Windows 2003, copiei os arquivos para um disco rígido vazio, tornei a unidade ativa e .. funcionou perfeitamente!

Ou fez? Por que tenho esse medo irracional de que falhará apenas porque não é um clone literal como eu esperaria com o Ghost? Eu deveria estar assustado? Por que foi tão fácil? Os servidores AD são diferentes? Existem casos em que esse método falhará?

Se a cópia arquivo a arquivo é o caminho a seguir, por que quando tentei fazer o mesmo com o VSS (expondo a sombra C: drive copiada como uma unidade S:) a mesma abordagem falhou. Mais especificamente, eu tenho um sistema de inicialização até a tela de login. Ele até aceitou minha senha, mas imediatamente desconectou meu usuário sem nenhum erro na GUI. Eu até tentei desligar todos os serviços, sem interrupção, antes de copiar ... o mesmo resultado.

A propósito, eu estou usando robocopy /E /SECpara todas essas operações de cópia

Estou apenas procurando problemas usando esses métodos? Eu sei que o Ghost etc está comprovado. Então, por que reinventar a roda? ... eu entendo tudo isso ... mas como profissional, quero saber por que as coisas funcionam da maneira que funcionam. É por isso que é importante para mim descobrir isso. (para não mencionar uma possibilidade rara de ter que fazer uma restauração bare-metal em um sistema em que nunca tive backup do estado do sistema)

Servidores AD são diferentes. Um controlador de domínio possui uma junção de diretório no diretório C: \ Windows \ SYSVOL \ sysvol que aponta para o diretório C: \ Windows \ SYSVOL \ domain:

 Directory of C:\Windows\SYSVOL\sysvol

04/13/2011  01:22 PM    <DIR>          .
04/13/2011  01:22 PM    <DIR>          ..
04/13/2011  01:22 PM    <JUNCTION>     domainName.acme.com [C:\Windows\SYSVOL\domain]

Quase qualquer tipo de operação de cópia manual resultaria em um SYSVOL que não fica online devido a uma junção com bork. Embora seja preciso, isso pode ocorrer em cenários de restauração normal, portanto, é sempre aconselhável verificar e recriar a junção SYSVOL, se necessário.

Por falar em links, qualquer sistema Windows 2008 / Vista / Windows 7 pode ter milhares de links na pasta% SYSTEMROOT% \ System32 dos binários. Esses destinos de link realmente residem na pasta% SYSTEMROOT% \ Winsxs.

Não confirmei isso, mas o Robocopy pode copiar o destino em vez do link. O que explicaria o switch / SL :: "copiar links simbólicos versus o destino".

É possível que o sistema pareça funcionar corretamente, mas o que ocorreria quando chegasse a hora de executar uma atividade de atualização do sistema, que precisa manter os arquivos em que os destinos do link geralmente residem? Talvez os recriasse, mas isso seria algo que vale a pena testar.

Se você estiver curioso para saber como esses links são transferidos para o disco copiado, faça um instantâneo antes e depois e compare os arquivos usando o Windiff ou o Notepad ++.

Você pode usar o seguinte comando para obter uma saída dos pontos de junção em uma unidade:

dir C:\ /aL /s  >> junctions.txt  

Você pode usar o seguinte script em um arquivo para obter uma saída dos links para um local (por exemplo, raiz do sistema):

for /r %systemroot% %%i in (*.exe,*.dll) do (
  echo Checking file: %%i >> file.txt
  fsutil.exe hardlink list "%%i" >> file.txt 2>&1
  echo . >> file.txt
)

Eu executei clones no nível de arquivo (usando o ntfscloneutilitário Linux NTFS Tools ) do Windows 2000 e Windows XP. Eu não tentei ntfsclonecom o Windows Vista ou versões mais recentes, mas não esperaria problemas. Uso a ferramenta de clonagem em nível de arquivo da Microsoft ImageX, regularmente com o Windows XP e o Windows 7, e também não tenho problemas. Geralmente não clono computadores servidores, mas esperaria ImageXfuncionar bem com sistemas operacionais de servidores.

Copiar um sistema de arquivos ao vivo sempre será um desafio. O Volume Shadow Copy deve expor um sistema de arquivos inativo, mas acho que você ainda está se arriscando. (Não sei dizer o que aconteceu com o volume clonado por VSS que não permitiria o logon. Sem poder ver o clone com falha, é muito, muito difícil de diagnosticar). Eu sempre aconselho você a clonar sistemas que estão offline, se possível.

Supondo que você esteja copiando um sistema de arquivos completamente inativo e capaz de obter todos os arquivos, suas únicas preocupações são:

• Ter um bom registro mestre de inicialização (MBR) e registro de inicialização da partição (PBR)
• Ter um bom gerenciador de inicialização

A Microsoft bootsect.exepode ser usada para gravar bons MBRs e PBRs para versões mais antigas baseadas em NTLDR do Windows NT (NT 3.5 a Windows Server 2003) e versões baseadas em BOOTMGR (Windows Vista e versões mais recentes). Seu clone do Windows 2003 deve estar em um disco com uma PBR no formato NT 5.2 (desde a inicialização).

O carregador de inicialização NTLDR será copiado em uma cópia no nível do arquivo, o que explica por que a sua cópia do Windows 2003 funcionou sem problemas. O carregador de inicialização do BOOTMGR pode ser instalado usando o bcdboot.exeutilitário (incluído na mídia de instalação do Windows baseada no BOOTMGR).

Eu não clonaria computadores do Active Directory Domain Controller (DC) dessa maneira. Você não deseja inicializar um clone de um controlador de domínio na mesma rede com o controlador de domínio original, porque esse é um cenário totalmente sem suporte e, provavelmente, não planejado.

Editar (agora que tenho alguns minutos em um computador real):

As ferramentas que descrevi acima ImageXe ntfsclonesão ferramentas de clone no nível do sistema de arquivos (como o Ghost, se não for executado no modo de setor bruto). Eles interpretam o sistema de arquivos NTFS em vez de copiar setor por setor. Ambas as ferramentas não terão problemas com pontos de junção ou hardlinks como ROBOCOPY(sem o /SLargumento) e XCOPY(com qualquer argumento).

Em geral, a Microsoft não planeja executar a clonagem de sistemas com base em cópia no nível de arquivo. Sim, você pode fazer isso, mas se quebrar, você fica com as peças.

O problema de copiar um sistema de arquivos ativo VSSé que a instância existente do Windows provavelmente já terá a assinatura do novo disco em seu registro. Quando você inicializa a cópia, a assinatura da partição da qual está inicializando é correspondida ao registro e montada como D:ou E:, e não C:como deveria.

Você pode resolver isso montando o arquivo de registro e atualizando HKLM\SYSTEM\MountedDevices Faça isso após a cópia, mas antes de reiniciar. Você deseja excluir a \DosDevices\C:entrada e alterar a entrada da sua nova unidade para C:.