No Windows: é seguro fazer um robocopy para clonar o sistema?

Question

Deixe-me começar dando um pouco de experiência. Nos sistemas Linux, costumo confiar no fato de que, desde que eu consiga colocar todos os arquivos de um disco rígido para outro, e desde que eu corrija o gerenciador de inicialização, ficarei com um idêntico, inicializável, totalmente sistema funcional. A mesma coisa funciona para backups e restaurações (não é necessário backup de estado do sistema especial, apenas os arquivos) ... mesmo o MySQL é recuperável às vezes mesmo quando não está congelado no momento do backup

No Windows, eu nunca tive sorte com a clonagem do sistema, fazendo isso em um nível de arquivo. Eu sempre preciso de uma ferramenta como o VMWare Converter, Ghost, 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 do modo especial / mágico que o Windows faz com o registro e eu não questionei (funcionou). Até hoje. Percebi que esse tipo de pensamento era burro e que, na realidade, o Windows também é apenas uma coleção de arquivos. Então, como teste, eu peguei uma unidade de servidor offline do Windows 2003, copiei os arquivos para um disco rígido vazio, deixei a unidade ativa e .. funcionou perfeitamente!

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

Se a cópia arquivo por arquivo é o caminho a percorrer, por que é que quando tentei fazer a mesma coisa com o VSS (expondo a unidade C: da sombra copiada como S:) a mesma abordagem falhou. Mais especificamente eu tenho um sistema de inicialização todo o caminho para 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, mas não parar, antes de copiar ... o mesmo resultado.

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

Estou apenas procurando problemas usando esses métodos? Eu sei que o Ghost etc está provado .. então por que reinventar a roda? ... Eu tenho tudo isso ... mas como profissional eu quero saber porque as coisas funcionam do jeito que fazem. É 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 onde eu nunca tive backup de estado do sistema)

    

Answer 1

Os servidores do AD são diferentes. Um controlador de domínio tem uma junção de diretório no diretório C: \ Windows \ SYSVOL \ sysvol que aponta para o C: \ Windows Diretório \ 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 on-line devido a uma junção borked. Apesar de ser preciso, isso pode ocorrer em cenários normais de restauração, 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 para os binários. Esses destinos de link, na verdade, residem na pasta% SYSTEMROOT% \ Winsxs.

Eu não confirmei isso, mas o Robocopy pode copiar o alvo em vez do link. O que explicaria o switch / SL :: "copiar links simbólicos contra o alvo".

É possível que o sistema pareça funcionar corretamente, mas o que ocorreria na hora de realizar uma atividade de atualização do sistema, que precisa manter os arquivos onde os alvos de link geralmente residem? Talvez recriá-los, mas isso seria algo que vale a pena testar.

Se você está curioso para saber como esses links são transferidos para o disco copiado, você pode tirar um instantâneo antes e depois e comparar 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, systemroot):

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
)

    

Answer 2

Eu executei clones em nível de arquivo (usando o utilitário ntfsclone do Linux NTFS Tools) do Windows 2000 e do Windows XP. Eu não tentei ntfsclone com o Windows Vista ou versões mais recentes, mas eu não esperaria nenhum problema. Eu uso a ferramenta de clonagem em nível de arquivo da Microsoft, ImageX , bastante regularmente com o Windows XP e o Windows 7 e também não tenho problemas. Eu geralmente não clonei computadores servidores, mas eu espero que ImageX funcione bem com o sistema operacional do servidor.

Copiar um sistema de arquivos ao vivo sempre será um desafio. A Cópia de Sombra de Volume é suposta para expor um sistema de arquivos inativo, mas acho que você ainda está se arriscando. (Não posso dizer o que aconteceu com o volume clonado por VSS que não permitia que você fizesse logon. Sem conseguir ver o clone com falha, é muito difícil diagnosticar). Eu sempre aconselho você a clonar sistemas que estão off-line, 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 um registro de inicialização de partição (PBR)
• Ter um bom bootloader

bootsect.exe da Microsoft pode ser usado para escreva bons MBRs e PBRs para versões antigas baseadas em NTLDR do Windows NT (NT 3.5 a Windows Server 2003) e versões baseadas em BOOTMGR (Windows Vista e mais recentes). Seu clone do Windows 2003 deve ter sido em um disco que tinha um PBR no formato NT 5.2 (desde que inicializou).

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

Eu não clonaria os computadores do Controlador de Domínio do Active Directory (DC) dessa maneira. Você não quer 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, ImageX e ntfsclone , são ferramentas clone no nível do sistema de arquivos (assim 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 argumento /SL ) e XCOPY (com qualquer argumento).

Em geral, a Microsoft não está planejando executar a clonagem de sistemas baseada em cópia em nível de arquivo. Sim, você pode fazer isso, mas se quebrar você consegue manter os pedaços.

    

Answer 3

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

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ê só deseja excluir a entrada \DosDevices\C: e alterar a entrada da sua nova unidade para C: .