Позвольте мне начать с небольшой предыстории. В системах Linux я часто полагаюсь на тот факт, что до тех пор, пока я могу перенести все файлы с одного жесткого диска на другой, и пока я исправляю загрузчик, у меня останется идентичный загрузочный, полностью функциональная система. То же самое работает для резервного копирования и восстановления (не требуется специального резервного копирования состояния системы, только файлы) ... даже MySQL можно восстановить иногда даже если он не был заморожен во время резервного копирования
В Windows мне никогда не удавалось клонировать систему на уровне файлов. Мне всегда нужны такие инструменты, как VMWare Converter, Ghost, diXML и т. Д. Они основаны на создании образа диска в целом. Сначала я предположил, что это было в основном из-за особого / волшебного способа, которым Windows делает это реестр, и я не подвергал это сомнению (это сработало). До сегодняшнего дня. Я понял, что такое мышление было глупым, и что на самом деле Windows - это тоже просто набор файлов. Поэтому в качестве теста я взял автономный серверный диск Windows 2003, скопировал файлы на чистый жесткий диск, сделал его активным и ... он работал отлично!
Или это так? Почему у меня такой иррациональный страх, что он потерпит неудачу только потому, что это не дословный клон, как я ожидал от Ghost? Я должен бояться? Почему это было так просто? Серверы AD чем-то отличаются? Есть ли случаи, когда этот метод не работает?
Если пошаговое копирование файлов - это путь, почему, когда я попытался сделать то же самое с VSS (отображая скопированный теневой диск C: как диск S:), тот же подход не удался. В частности, я получил загрузочную систему полностью до экрана входа в систему. Он даже принял мой пароль, но сразу же отключил моего пользователя без ошибок в графическом интерфейсе. Я даже попытался отключить все службы, кроме тех, которые нельзя остановить, перед копированием ... тот же результат.
Кстати я использую robocopy /E /SEC для всех этих операций копирования
Я просто ищу проблемы, используя эти методы? Я знаю, что Ghost и т. Д. Доказаны ... так зачем изобретать велосипед? ... Я все это понимаю ... но как профессионал я хочу знать, почему все работает именно так. Вот почему мне важно в этом разобраться. (не говоря уже о редкой возможности выполнить восстановление с нуля в системе, где у меня никогда не было резервной копии состояния системы)
Я выполнил клонирование на уровне файлов (используя Linux NTFS Tools ntfsclone утилита) Windows 2000 и Windows XP. Я не пробовал ntfsclone с Windows Vista или более новыми версиями, но я бы не ожидал никаких проблем. Я использую инструмент клонирования Microsoft на уровне файлов, ImageX, довольно регулярно с Windows XP и Windows 7 и там тоже нет проблем. Обычно я не клонирую серверные компьютеры, но ожидаю ImageX нормально работать с серверными ОС.
Копирование живой файловой системы всегда будет проблемой. Теневая копия тома предполагаемый чтобы открыть неподвижную файловую систему, но я думаю, что вы все еще рискуете. (Я не могу сказать вам, что случилось с вашим VSS-клонированным томом, который не позволил вам войти в систему. Без возможности увидеть отказавший клон, это действительно очень сложно диагностировать). Я всегда советую вам клонировать автономные системы, если это возможно.
Предполагая, что вы копируете полностью неподвижную файловую систему и можете получить все файлы, вас беспокоит следующее:
Microsoft bootsect.exe может использоваться для записи хороших MBR и PBR для более старых версий Windows NT (от NT 3.5 до Windows Server 2003) на основе NTLDR и версий на основе BOOTMGR (Windows Vista и новее). Ваш клон Windows 2003 должен быть на диске с PBR формата NT 5.2 (с момента его загрузки).
Загрузчик NTLDR будет скопирован в копию на уровне файлов, что объясняет, почему ваша копия Windows 2003 работала без проблем. Загрузчик BOOTMGR можно установить с помощью bcdboot.exe утилита (входит в состав установочного носителя Windows на базе BOOTMGR).
Я бы не стал клонировать компьютеры Active Directory Domain Controller (DC) таким образом. Вы не хотите загружать клон DC в той же сети, что и исходный DC, потому что это полностью неподдерживаемый и, вероятно, незапланированный сценарий.
Изменить (теперь, когда у меня есть несколько минут на реальном компьютере):
Инструменты, которые я описал выше, ImageX и ntfsclone, являются инструментами клонирования на уровне файловой системы (как и Ghost, если он не работает в режиме сырого сектора). Они интерпретируют файловую систему NTFS, а не копируют сектор за сектором. У обоих этих инструментов не будет проблем с точками соединения или жесткими ссылками, такими как ROBOCOPY (без /SL аргумент) и XCOPY (с любыми аргументами) будет.
В общем, Microsoft не планирует, чтобы вы выполняли клонирование систем на основе копирования на уровне файлов. Да ты жестяная банка сделай это, но если он сломается, ты останешься на своем месте.
Проблема с копированием живой файловой системы из VSS заключается в том, что существующий экземпляр Windows, вероятно, будет иметь подпись нового диска уже в его реестре. Когда вы загружаете копию, подпись раздела, с которого она загружается, сопоставляется с реестром и монтируется как D: или E:, а не C: так должно быть.
Вы можете разобраться в этом, установив файл реестра и обновив HKLM\SYSTEM\MountedDevices Сделайте это после копирования, но перед перезапуском. Вы просто хотите удалить \DosDevices\C: запись и измените запись для вашего нового диска на C:.
Серверы 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
)