В Windows: безопасно ли делать робокопию для клонирования системы?

Позвольте мне начать с небольшого фона. В системах Linux я часто полагаюсь на тот факт, что, пока я могу перенести все файлы с одного жесткого диска на другой, и пока я чиню загрузчик, у меня останется идентичный, загрузочный, полностью функциональная система. То же самое работает для резервного копирования и восстановления (не требуется специального резервного копирования состояния системы, только файлы) ... даже MySQL иногда можно восстановить, даже если он не был заморожен во время резервного копирования

В Windows мне никогда не удавалось клонировать систему, делая это на уровне файлов. Мне всегда нужны такие инструменты, как VMWare Converter, Ghost, diXML и т. Д., Они основаны на съемке образа диска в целом. Сначала я предположил, что это было главным образом из-за особого / магического способа, которым окна делают свой реестр, и я не подверг сомнению это (это работало). До сегодняшнего дня. Я понял, что такое мышление было глупым, и что на самом деле Windows - это просто набор файлов. Поэтому в качестве теста я взял автономный диск с сервером Windows 2003, скопировал файлы на пустой жесткий диск, активировал диск и ... он работал отлично!

Или сделал это? Почему у меня есть этот иррациональный страх, что он потерпит неудачу только потому, что это не дословный клон, как я ожидал от Призрака? Должен ли я бояться? Почему это было так легко? AD серверы отличаются? Есть ли случаи, когда этот метод потерпит неудачу?

Если пошаговое копирование файла - это то, почему, когда я пытался сделать то же самое с VSS (открывая теневой диск C: как диск S:), тот же подход не удался. Более конкретно, я получил систему загрузки вплоть до экрана входа в систему. Он даже принял мой пароль, но затем немедленно вышел из системы без ошибок в графическом интерфейсе. Я даже пытался отключить все службы, кроме неотключаемых, прежде чем копировать ... тот же результат.

Кстати, я использую robocopy /E /SECдля всех этих операций копирования

Я просто ищу проблемы с помощью этих методов? Я знаю, что призрак и т. Д. Доказаны .. так зачем изобретать велосипед? ... я все это понимаю ... но как профессионал я хочу знать, почему все работает так, как они работают. Вот почему для меня важно понять это. (не говоря уже о редкой возможности выполнения «чистого» восстановления в системе, где у меня никогда не было резервной копии состояния системы)

Серверы AD разные. Контроллер домена имеет соединение каталога в каталоге C: \ Windows \ SYSVOL \ sysvol, которое указывает на каталог 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]

Практически любой тип операции ручного копирования приведет к тому, что SYSVOL не будет подключен к сети из-за разорванного соединения. Хотя, чтобы быть точным, это может происходить в нормальных сценариях восстановления, поэтому всегда рекомендуется проверять и заново создавать соединение SYSVOL, если это необходимо.

Говоря о ссылках, любая система Windows 2008 / Vista / Windows 7 может иметь тысячи ссылок в папке% SYSTEMROOT% \ System32 для двоичных файлов. Эти целевые ссылки на самом деле находятся в папке% SYSTEMROOT% \ Winsxs.

Я не подтвердил это, но Robocopy может скопировать цель вместо ссылки. Что объясняет переключатель / SL :: «копировать символические ссылки против цели».

Может показаться, что система функционирует правильно, но что произойдет, когда придет время выполнить обновление системы, которое должно поддерживать файлы, в которых обычно находятся целевые объекты ссылки? Возможно, они воссоздают их, но это стоит попробовать.

Если вам интересно, как эти ссылки переносятся на скопированный диск, вы можете сделать снимок до и после, а затем сравнить файлы с помощью Windiff или Notepad ++.

Вы можете использовать следующую команду, чтобы получить выходные данные точек соединения на диске:

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

Вы можете использовать следующий скрипт в файле, чтобы получить вывод ссылок для местоположения (например, 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
)

Я выполнил клоны на уровне файлов (с помощью ntfscloneутилиты Linux NTFS Tools ) Windows 2000 и Windows XP. Я не пробовал ntfscloneс Windows Vista или более новыми версиями, но я не ожидал никаких проблем. Я использую инструмент клонирования на уровне файлов Microsoft ImageX, довольно регулярно с Windows XP и Windows 7, и у меня тоже нет проблем. Я обычно не клонирую серверные компьютеры, но я ожидаю, что они ImageXбудут нормально работать с серверными ОС.

Копирование живой файловой системы всегда будет проблемой. Предполагается, что Volume Shadow Copy предоставляет скрытую файловую систему, но я думаю, что вы все еще рискуете. (Я не могу сказать вам, что случилось с вашим VSS-клонированным томом, который не позволил бы вам войти в систему. Без возможности увидеть сбойный клон, это действительно очень трудно диагностировать). Я всегда советую вам клонировать системы, которые находятся в автономном режиме, если это возможно.

Предполагая, что вы копируете полностью неподвижную файловую систему и можете получить все файлы, ваши единственные проблемы:

• Наличие хорошей основной загрузочной записи (MBR) и загрузочной записи раздела (PBR)
• Иметь хороший загрузчик

Microsoft bootsect.exeможно использовать для написания хороших MBR и PBR для более старых версий NTLDR для Windows NT (NT 3.5 - Windows Server 2003) и BOOTMGR (для Windows Vista и новее). Ваш клон Windows 2003 должен был находиться на диске с PBR формата NT 5.2 (с момента загрузки).

Загрузчик NTLDR будет скопирован в виде копии на уровне файлов, что объясняет, почему ваша копия Windows 2003 работала без проблем. Загрузчик BOOTMGR можно установить с помощью bcdboot.exeутилиты (входит в установочный носитель Windows на основе BOOTMGR).

Я бы не стал клонировать компьютеры контроллера домена Active Directory таким образом. Вы не хотите загружать клон DC в той же сети с исходным DC, потому что это полностью неподдерживаемый и, вероятно, незапланированный сценарий.

Изменить (теперь, когда у меня есть несколько минут на реальном компьютере):

Инструменты, которые я описал выше, ImageXи ntfscloneявляются инструментами клонирования на уровне файловой системы (как Ghost, если он не запущен в режиме сырого сектора). Они интерпретируют файловую систему NTFS, а не копируют сектор за сектором. Оба эти инструмента не будут иметь проблем с точками соединения или жесткими ссылками, как ROBOCOPY(без /SLаргумента) и XCOPY(с любыми аргументами).

В общем, Microsoft не планирует выполнять клонирование систем на уровне файлов. Да, вы можете сделать это, но если оно сломается, вы можете оставить себе кусочки.

Проблема с копированием действующей файловой системы из-за VSSтого, что существующий экземпляр Windows, вероятно, будет иметь подпись нового диска уже в своем реестре. При загрузке копии подпись раздела, с которого она загружается, сопоставляется с реестром и монтируется как D:или E:, а не так, C:как должно быть.

Вы можете разобраться с этим, смонтировав файл реестра и обновив « HKLM\SYSTEM\MountedDevices Сделайте это после копирования, но перед перезапуском» Вы просто хотите удалить \DosDevices\C:запись и изменить запись для вашего нового диска на C:.