En Windows: ¿es seguro hacer una robocopia para clonar el sistema?

Permítanme comenzar dando un poco de historia. En los sistemas Linux, con frecuencia confío en el hecho de que mientras pueda transferir todos los archivos de un disco duro a otro, y siempre que arregle el cargador de arranque, me quedaré con un dispositivo de arranque idéntico, totalmente sistema funcional Lo mismo funciona para las copias de seguridad y las restauraciones (no se requiere una copia de seguridad especial del estado del sistema, solo los archivos) ... incluso MySQL es recuperable a veces incluso cuando no estaba congelado en el momento de la copia de seguridad

En Windows, nunca tuve suerte con la clonación del sistema al hacerlo a nivel de archivo. Siempre necesito una herramienta como VMWare Converter, Ghost, diXML, etc., se basan en tomar la imagen de la unidad como un todo. Al principio supuse que esto se debía principalmente a la forma especial / mágica en que Windows registra su registro y no lo cuestioné (funcionó). Hasta hoy. Me di cuenta de que este tipo de pensamiento era tonto, y que en realidad Windows también es solo una colección de archivos. Entonces, como prueba, tomé una unidad de servidor Windows 2003 sin conexión, copié los archivos en un disco duro en blanco, activé la unidad y ... ¡funcionó perfectamente!

O lo hizo? ¿Por qué tengo este miedo irracional de que fracasará solo porque no es un clon literal como hubiera esperado con Ghost? ¿Debería estar asustado? ¿Por qué fue tan fácil? ¿Los servidores de AD son diferentes? ¿Hay casos en los que este método fallará?

Si la copia de archivo por archivo es el camino a seguir, ¿por qué cuando traté de hacer lo mismo con VSS (exponiendo la copia C: unidad como una unidad S: copiada) el mismo enfoque falló. Más específicamente, obtuve un sistema de arranque hasta la pantalla de inicio de sesión. Incluso aceptó mi contraseña, pero inmediatamente cerró la sesión de mi usuario sin ningún error en la GUI. Incluso intenté apagar todos los servicios, excepto los que no se pueden detener, antes de copiar ... el mismo resultado.

Por cierto, estoy usando robocopy /E /SECpara todas estas operaciones de copia

¿Estoy buscando problemas usando estos métodos? Sé que Ghost, etc., están probados ... entonces, ¿por qué reinventar la rueda? ... entiendo todo eso ... pero como profesional quiero saber por qué las cosas funcionan de la manera en que lo hacen. Por eso es importante para mí resolver esto. (sin mencionar la rara posibilidad de tener que hacer una restauración completa en un sistema donde nunca tuve una copia de seguridad del estado del sistema)

Los servidores de AD son diferentes. Un controlador de dominio tiene una unión de directorio en el directorio C: \ Windows \ SYSVOL \ sysvol que apunta al directorio 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]

Casi cualquier tipo de operación de copia manual daría como resultado un SYSVOL que no se conecta en línea debido a una unión borked. Aunque para ser precisos, esto puede ocurrir en escenarios de restauración normales, por lo que siempre es recomendable verificar y volver a crear la unión SYSVOL si es necesario.

Hablando de enlaces, cualquier sistema Windows 2008 / Vista / Windows 7 puede tener miles de enlaces en la carpeta% SYSTEMROOT% \ System32 para los binarios. Estos objetivos de enlace en realidad residen en la carpeta% SYSTEMROOT% \ Winsxs.

No he confirmado esto, pero Robocopy puede copiar el objetivo en lugar del enlace. Lo que explicaría el modificador / SL :: "copiar enlaces simbólicos versus el objetivo".

Es posible que el sistema parezca funcionar correctamente, pero ¿qué ocurriría cuando sea el momento de realizar una actividad de actualización del sistema, que necesita mantener los archivos donde generalmente residen los objetivos del enlace? Quizás los volvería a crear, pero eso sería algo que vale la pena probar.

Si tiene curiosidad acerca de cómo se transfirieron estos enlaces al disco copiado, puede tomar una instantánea antes y después, y luego comparar los archivos con Windiff o Notepad ++.

Puede usar el siguiente comando para obtener una salida de los puntos de unión en una unidad:

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

Puede usar el siguiente script en un archivo para obtener una salida de los enlaces para una ubicación (por ejemplo, root del 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
)

He realizado clones a nivel de archivo (utilizando la ntfscloneutilidad Linux NTFS Tools ) de Windows 2000 y Windows XP. No he probado ntfsclonecon Windows Vista o versiones más recientes, pero no esperaría ningún problema. Utilizo la herramienta de clonación a nivel de archivo de Microsoft ImageX, con bastante frecuencia con Windows XP y Windows 7 y tampoco tengo problemas allí. Por lo general, no clono las computadoras del servidor, pero esperaría ImageXfuncionar bien con los sistemas operativos del servidor.

Copiar un sistema de archivos en vivo siempre será un desafío. Se supone que Volume Shadow Copy expone un sistema de archivos inactivo, pero creo que aún está tomando sus riesgos. (No puedo decirle qué sucedió con su volumen clonado con VSS que no le permitiría iniciar sesión. Sin poder ver el clon fallido es realmente muy difícil de diagnosticar). Siempre te aconsejaría que clones sistemas que están fuera de línea, si es posible.

Suponiendo que está copiando un sistema de archivos completamente inactivo y capaz de obtener todos los archivos, sus únicas preocupaciones son:

• Tener un buen registro de inicio maestro (MBR) y un registro de inicio de partición (PBR)
• Tener un buen gestor de arranque

Microsoft bootsect.exese puede usar para escribir buenos MBR y PBR para versiones anteriores de Windows NT basadas en NTLDR (NT 3.5 a través de Windows Server 2003) y versiones basadas en BOOTMGR (Windows Vista y posteriores). Su clon de Windows 2003 debe haber estado en un disco que tenía un PBR con formato NT 5.2 (desde que se inició).

El gestor de arranque NTLDR se copiará en una copia a nivel de archivo, lo que explica por qué su copia de Windows 2003 funcionó sin problemas. El cargador de arranque BOOTMGR se puede instalar utilizando la bcdboot.exeutilidad (incluida en los medios de configuración de Windows basados ​​en BOOTMGR).

No clonaría las computadoras de Active Directory Domain Controller (DC) de esta manera. No desea iniciar un clon de un DC en la misma red con el DC original porque este es un escenario totalmente incompatible y, probablemente, no planificado.

Editar (ahora que tengo unos minutos en una computadora real):

Las herramientas que describí anteriormente ImageXy ntfscloneson herramientas de clonación a nivel de sistema de archivos (como lo es Ghost si no se ejecuta en modo de sector sin procesar). Interpretan el sistema de archivos NTFS en lugar de copiar sector por sector. Ambas herramientas no tendrán problemas con los puntos de unión o enlaces duros como ROBOCOPY(sin el /SLargumento) y XCOPY(con cualquier argumento) lo tendrían.

En general, Microsoft no planea que realice una clonación de sistemas basada en copias a nivel de archivo. Sí, usted puede hacerlo, pero si se rompe se llega a mantener las piezas.

El problema al copiar un sistema de archivos en vivo VSSes que la instancia de Windows existente probablemente tendrá la firma del nuevo disco ya en su registro. Cuando inicia la copia, la firma de la partición desde la que se inicia coincide con el registro y se monta como D:o E:, en lugar de C:como debería ser.

Puede solucionar esto montando el archivo de registro y actualizando HKLM\SYSTEM\MountedDevices Haga esto después de la copia pero antes de reiniciar. Solo desea eliminar la \DosDevices\C:entrada y cambiar la entrada para su nuevo disco C:.