У Windows: чи безпечно робити робоче копіювання, щоб клонувати систему?

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

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

Або це зробили? Чому я маю цей ірраціональний страх, що він зазнає невдачі лише тому, що це не дослівний клон, як я б очікував із Привидом? Чи варто боятися? Чому це було так просто? Чи відрізняються сервери AD? Чи є випадки, коли цей метод не вдасться?

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

До речі, я використовую robocopy /E /SECдля всіх цих операцій з копіюванням

Чи я просто шукаю проблеми, використовуючи ці методи? Я знаю, що Ghost і т. Д. Доведено .. так навіщо винаходити колесо? ... Я все це отримую ... але як професіонал я хочу знати, чому все працює так, як вони роблять. Тому мені важливо це зрозуміти. (не кажучи вже про рідкісну можливість відновити голий метал у системі, де я ніколи не мав резервного копіювання стану системи)

Сервери AD різні. Контролер домену має з'єднання каталогів у каталозі C: \ Windows \ SYSVOL \ sysvol, який вказує на домен C: \ Windows \ SYSVOL \:

 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на те, що добре працюватиме з серверними ОС.

Копіювання живої файлової системи завжди стане проблемою. Тонова копія тіней повинна відкрити спокійну файлову систему, але я думаю, ви все ще ризикуєте. (Я не можу сказати вам, що сталося з вашим клонованим 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 Controller (DC) таким чином. Ви не хочете завантажувати клон постійного струму в одній мережі з оригінальним постійним струмом, оскільки це повністю непідтримуваний і, швидше за все, незапланований сценарій.

Редагувати (тепер, коли у мене на справжньому комп’ютері є кілька хвилин):

Інструменти , які я описав вище, ImageXі ntfscloneє клон інструментів файлової системи на рівні (як це Дух , якщо він не працює в режимі сировинного сектора). Вони інтерпретують файлову систему NTFS, а не копіюють сектор за сектором. Обидва ці інструменти не матимуть проблем з точками з'єднання або жорсткими посиланнями, як-от ROBOCOPY(без /SLаргументу) та XCOPY(з будь-якими аргументами).

Загалом, Microsoft не планує для вас виконувати клонування на основі копіювання систем на рівні файлів. Так, ви можете це зробити, але якщо він зламається, ви можете зберегти шматки.

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

Ви можете розібратися з цим, встановивши файл реєстру та оновивши HKLM\SYSTEM\MountedDevices це після копіювання, але перед перезапуском. Ви просто хочете видалити \DosDevices\C:запис і змінити запис для нового диска на C:.