在Windows上:为了复制系统,安装robocopy是否安全?

首先让我介绍一下背景。 在Linux系统上,我经常依靠的事实是,只要我能把所有文件从一个硬盘驱动器转移到另一个硬盘驱动器上,并且只要我修复了引导加载程序,我就会留下完全相同的可引导的function系统。 同样的事情也适用于备份和恢复(不需要特殊的系统状态备份,只需要文件)甚至有时即使MySQL在备份时没有被冻结可以恢复

在Windows上,我从来没有在文件级别克隆系统的运气。 我总是需要一个像VMWare Converter,Ghost,diXML等工具。它们是基于整个驱动器的形象。 起初,我认为这主要是因为特殊/神奇的方式窗户是registry,我没有质疑(它的工作)。 直到今天。 我意识到这种想法是愚蠢的,实际上Windows也只是一个文件集合。 所以作为一个testing,我拿走了一个离线的Windows 2003服务器驱动器,我把这些文件复制到一个空白的硬盘驱动器上,使驱动器处于活动状态。

还是呢? 为什么我会有这种非理性的恐惧,认为它会失败,因为它不像我想象的那样是一个逐字的克隆? 我应该害怕吗? 为什么这么容易? AD服务器有什么不同? 有没有这种方法会失败的情况?

如果逐个文件复制是要走的路,那么为什么当我试图用VSS做同样的事情时(将C:驱动器复制到S:驱动器),同样的方法失败了。 更具体地说,我有一个引导系统一直到login屏幕。 它甚至接受我的密码,但立即注销我的用户在GUI中没有错误。 我甚至试图closures所有,但不能停止的服务之前复制…相同的结果。

顺便说一下,我正在使用robocopy /E /SEC进行所有这些复制操作

我只是用这些方法寻找麻烦? 我知道鬼等被certificate..所以为什么重新发明轮子? 我得到了所有这些……但作为一名专业人士,我想知道为什么事情会按照他们的方式工作。 这就是为什么我认识这一点很重要。 (更不用说在一个我从来没有进行过系统状态备份的系统上进行裸机还原的一种罕见的可能性)

    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] 

    几乎任何types的手动复制操作都会导致SYSVOL由于连接错位而不能联机。 虽然要准确,但在正常还原的情况下可能会出现这种情况,所以如有必要,始终build议检查并重新创buildSYSVOL联结。

    说到链接,任何Windows 2008 / Vista / Windows 7系统都可能在二进制文件的%SYSTEMROOT%\ System32文件夹中包含数千个链接。 这些链接目标实际上驻留在%SYSTEMROOT%\ Winsxs文件夹中。

    我还没有证实这一点,但Robocopy可能会复制目标,而不是链接。 这将解释开关/ SL ::“复制符号链接与目标”。

    系统似乎可能正常工作,但是当执行系统更新活动时需要维护链接目标通常驻留的文件时会发生什么? 也许它会重新创build它们,但这将是值得testing的东西。

    如果您好奇这些链接是如何传输到复制的磁盘上的,则可以使用快照之前和之后的快照,然后使用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 ) 

    我已经执行了Windows 2000和Windows XP的文件级克隆(使用Linux NTFS Tools ntfsclone实用程序)。 我还没有尝试ntfsclone与Windows Vista或更新的版本,但我不希望有任何问题。 我经常在Windows XP和Windows 7上使用Microsoft的文件级克隆工具ImageX ,并且在那里也没有问题。 我通常不克隆服务器计算机,但我希望ImageX在服务器操作系统上正常工作。

    复制实时文件系统总是会成为一个挑战。 卷影复制应该是暴露一个静止的文件系统,但我认为你仍然抓住机会。 (我不能告诉你,你的VSS克隆卷发生了什么事情,不允许你login,不能看到失败的克隆,这确实很难诊断)。 如果可能的话,我总是build议你克隆离线的系统。

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

    • 有一个很好的主引导logging(MBR)和分区引导logging(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相同的networking上启动DC的克隆,因为这是完全不受支持的,可能是无计划的情况。

    编辑(现在,我有一个真正的电脑上几分钟):

    上面描述的工具ImageXntfsclone是文件系统级别的克隆工具(如果它不是以原始扇区模式运行的话,就像Ghost一样)。 他们解释NTFS文件系统,而不是复制扇区为扇区。 这两种工具都不会有像ROBOCOPY (没有/SL参数)和XCOPY (有任何参数)的连接点或硬链接的问题。

    一般来说,微软并不打算为系统执行文件级的基于拷贝的克隆。 是的,你可以做,但如果它打破了,你可以保留这些东西。

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

    您可以通过挂载registry文件和更新HKLM\SYSTEM\MountedDevices进行sorting在副本之后但重新启动之前执行此操作。 您只想删除\DosDevices\C:项并将新驱动器的条目更改为\DosDevices\C: