在 Windows 上:执行 robocopy 来克隆系统是否安全?

在 Windows 上:执行 robocopy 来克隆系统是否安全?

首先,我先介绍一下背景。在 Linux 系统上,我经常依赖这样一个事实:只要我能将所有文件从一个硬盘驱动器转移到另一个硬盘驱动器,并且只要我修复了引导加载程序,我就会得到一个完全相同、可引导且功能齐全的系统。备份和恢复也是如此(不需要特殊的系统状态备份,只需要文件)... 甚至 MySQL 也是可恢复的有时即使在备份时没有被冻结

在 Windows 上,我从来没有在文件级别克隆系统。我总是需要一个工具,例如 VMWare Converter、Ghost、diXML 等。它们基于获取整个驱动器的映像。起初,我认为这主要是因为 Windows 处理注册表的特殊/神奇方式,我没有质疑它(它有效)。直到今天。我意识到这种想法很愚蠢,实际上 Windows 也只是一个文件集合。因此,作为测试,我使用了一个离线的 Windows 2003 服务器驱动器,我将文件复制到一个空白硬盘驱动器,使驱动器处于活动状态,并且......它完美地工作了!

还是真的?为什么我会有这种莫名的恐惧,担心它会失败,仅仅因为它不是 Ghost 所期望的逐字克隆?我应该害怕吗?为什么这么容易?AD 服务器有什么不同吗?这种方法会失败吗?

如果逐个文件复制是可行的方法,那么为什么当我尝试使用 VSS 执行相同操作(将影子复制的 C: 驱动器显示为 S: 驱动器)时,相同的方法会失败。更具体地说,我得到了一个启动系统,一直到登录屏幕。它甚至接受了我的密码,但随后立即注销了我的用户,GUI 中没有任何错误。我甚至尝试在复制之前关闭所有无法停止的服务......结果相同。

robocopy /E /SEC顺便说一下,我所有这些复制操作都用

我使用这些方法是不是自找麻烦?我知道 Ghost 等已经得到证实……那么为什么要重新发明轮子呢?……我明白这一切……但作为一名专业人士,我想知道为什么事情会这样运作。这就是为什么弄清楚这一点对我来说很重要。(更不用说在从未备份过系统状态的系统上进行裸机恢复的可能性很小)

答案1

AD 服务器则不同。域控制器具有目录连接点在指向 C:\Windows\SYSVOL\domain 目录的 C:\Windows\SYSVOL\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
)

答案2

我曾对 Windows 2000 和 Windows XP 执行过文件级克隆(使用 Linux NTFS Toolsntfsclone实用程序)。我还没有尝试过ntfscloneWindows Vista 或更新版本,但我认为不会出现任何问题。我经常在 Windows XP 和 Windows 7 上使用 Microsoft 的文件级克隆工具,ImageX也没有遇到任何问题。我通常不克隆服务器计算机,但我希望ImageX它能很好地与服务器操作系统配合使用。

复制实时文件系统始终是一项挑战。卷影复制是应该暴露静态文件系统,但我认为您仍在冒险。(我无法告诉您 VSS 克隆卷发生了什么,导致您无法登录。如果不能看到失败的克隆,诊断起来真的非常非常困难)。如果可能,我始终建议您克隆离线系统。

假设您正在复制一个完全静止的文件系统并且能够获取所有文件,您唯一关心的是:

  • 具有良好的主引导记录 (MBR) 和分区引导记录 (PBR)
  • 拥有良好的引导加载程序

微软的bootsect.exe可用于为基于 NTLDR 的旧版 Windows NT(NT 3.5 至 Windows Server 2003)和基于 BOOTMGR 的版本(Windows Vista 及更新版本)写入良好的 MBR 和 PBR。您的 Windows 2003 克隆必须位于具有 NT 5.2 格式 PBR 的磁盘上(因为它已启动)。

NTLDR 引导加载程序将以文件级副本的形式进行复制,这解释了为什么您的 Windows 2003 副本可以正常工作。可以使用实用bcdboot.exe程序(包含在基于 BOOTMGR 的 Windows 安装媒体中)安装 BOOTMGR 引导加载程序。

我不会以这种方式克隆 Active Directory 域控制器 (DC) 计算机。您不会想在与原始 DC 相同的网络上启动 DC 的克隆,因为这是一种完全不受支持且很可能是计划外的情况。

编辑(现在我在真正的计算机上有几分钟的时间):

我上面描述的工具ImageXntfsclone是文件系统级克隆工具(如果 Ghost 不是以原始扇区模式运行,也是这样)。它们解释 NTFS 文件系统,而不是逐扇区复制。这两个工具都不会像ROBOCOPY(不带参数/SL)和XCOPY(带任何参数)那样出现连接点或硬链接问题。

总体而言,微软不打算让你执行基于文件级复制的系统克隆。是的,你去做吧,但如果它坏了,你就可以保留碎片。

答案3

从实时文件系统复制的问题VSS是,现有 Windows 实例可能已在其注册表中拥有新磁盘的签名。启动副本时,其启动分区的签名与注册表匹配,并安装为D:E:,而不是它C:应该的样子。

您可以通过安装注册表文件并更新来解决这个问题HKLM\SYSTEM\MountedDevices 。在复制之后但在重新启动之前执行此操作。您只需删除该\DosDevices\C:条目并将新驱动器的条目更改为C:

相关内容