通过复制/粘贴复制整个 C 驱动器。它会起作用吗？

Question

如果我将 Windows 计算机上的整个 C 驱动器复制到新驱动器（通过复制粘贴甚至镜像工具），是否有任何原因导致复制的 C: 驱动器无法启动？

这是在辅助驱动器上正确设置 MBR 的情况下编辑：并且文件锁定不是问题，复制粘贴不必从要复制的 C 驱动器窗口内部进行，可以是已安装的驾驶。

我知道从备份的角度来看，执行完整快照“更好”，但这个问题与“最佳”实践无关。

有人告诉我，仅通过镜像驱动器文件无法使系统恢复并运行。我不明白为什么！如果它是 1:1 副本（所有文件均已验证位于第二个驱动器上），那么您应该拥有所需的一切？

我被告知的主要原因是注册表不会被复制。但是机器上的所有内容肯定都是某个地方的文件吗？

Answer 1

这可能行不通。

这个答案可能假设一个典型的设置，其中 C: 保存操作系统。

让我从一个例子开始，说明为什么您无法获得精确的副本：

原因一：探险家试图表现得友善

当您使用 Microsoft Windows 的 GUI（资源管理器）将图片复制到新文件夹时，Windows 会尝试为您做一件“用户友好”的事情。它将查看图片并制作缩略图，并将其存储在名为thumbs.db的文件中

因此，如果您复制一堆文件，并且它以 ApicOne.jpg、BpicTwo.jpg、CpicThree.jpg 开头，那么它会在复制这三个图像时创建 3 个缩略图。

然后，当它尝试复制较旧的thumbs.db 文件（因为我们正在复制所有文件）时，会发生冲突，因为较新的thumbs.db 文件已存在。较新的thumbs.db 文件尚不包含ZpicTwentySix.jpg 文件（假设文件按字母顺序复制）。因此，当 GUI 询问您是否要覆盖名为thumbs.db 的预先存在的文件时，它会停止复制

简单的现实是：这是一种痛苦。

现在，理论上，您可以跳过该文件（并保留旧文件），或覆盖旧文件，因为新文件应包含相同的缩略图（最终，在复制最后一张图片后）。但是，该较新的文件现在将具有不同的修改日期。所以，你没有精确的副本。另外，如果文件之前以不同的方式排序（可能根据文件日期添加到目录中，当它们随着时间的推移下载时），但随后以资源管理器复制它们的方式排序（按字母顺序），那么，再一次，您并没有以完全相同的方式存储所有内容。

原因 2：文件可能并非表面所见

有些文件实际上并不像它们看起来那样存在。C:\Windows\WinSXS\ 包含所谓的“并排程序集”。基本上，当您安装两个依赖共享文件的程序时，较新版本的 Microsoft Windows 将保留该文件的两个版本，即使它们具有相同的文件名。当您更新文件时，Microsoft Windows 可能会同时存储新文件和旧文件。此类技术提高了安装多个软件时的兼容性，并且在出现问题时有助于回滚到先前状态（“系统恢复”）。但其实现方式很复杂。

如果您运行 WinDirStat（从WinDirStat 页面下载），该程序将显示硬盘上文件的大小。C:\Windows\WinSXS 目录看起来很大。巨大。

然而，这是错误的。看吧，WinSXS目录很特别。该目录将报告文件具有一定大小。然而，实际上，Windows 对该文件夹使用了一些特殊技巧。该文件夹中实际上是一堆共享一些数据的部分文件。我认为。类似的事情。要点是：使用了某种技巧。而 WinDirStat 不理解这些技巧。因此WinDirStat相信Windows告诉它的每一个谎言，并且WinDirStat最终说WinSXS目录中的文件占用了绝对巨大的磁盘空间。

当您尝试运行一个程序时，Windows 足够智能，能够将 DLL 文件的各个部分组合在一起，并使程序看到任何所需数据的副本，因此程序可以正常运行。

当您使用 Explorer 的 GUI 尝试复制该目录时，Explorer 的 GUI 的“复制”功能无法理解 WinSXS 的特殊性。因此，“复制”功能将尝试复制每个单独的文件，就好像它是整个文件一样。结果是将文件复制到未进行特殊处理的目标目录中。所以目的地与特殊源不匹配。

原因#3：启动过程可能很复杂

引导代码可以做一些有趣的事情。不同操作系统的不同版本可能会有不同的行为，因此我在这里提到的具体细节可能与您正在使用的特定 Windows 版本不完全匹配。基本上，系统启动（BIOS / (U)EFI）将检查带有引导代码（MBR / GPT）的磁盘部分，该部分将指向文件的位置。了解计算机正在运行可能非常简单的代码。这种简单的代码甚至可能无法完全理解文件系统的复杂细节。例如，它可能不理解 NTFS 连接。但没关系。也许引导代码只知道必要的文件位于磁盘的扇区号 6,189,247,145 上。安装操作系统后，操作系统会帮助确保引导代码知道文件的正确位置。

如果将所有文件从根目录 (C:*. ) 复制到新驱动器 (D:*. )，Windows 资源管理器的 GUI 可能会以非常简单的方式执行操作，例如按字母顺序复制数据。如果您的操作系统添加了一个文件（例如，名为 C:\BootLog.txt 的隐藏文件），该文件可能位于 C:\bootmgr 之前（按字母顺序排列）。因此，C:\bootmgr 并没有像 Windows 安装到 C:\ 驱动器时那样早地出现在文件列表中。

这是在辅助驱动器上正确设置 MBR 的情况下进行的

好的，您已经了解 MBR 可能需要查找该文件了。

现在，通常磁盘引导代码的工作是查找包含有关如何引导系统的更多详细信息的文件。例如，在 Windows 95 中，这些详细信息通常存储在名为 \IO.SYS 的文件中（但也可以使用其他一些文件名）。在 IBM PC DOS 中，相同类型的功能存储在 C:\IBMBIO.COM 和 C:\IBMBIO.SYS 中。所以有多个启动文件可以一起工作。

因此，该问题可能不仅仅局限于 MBR。即使操作系统启动后，引导加载程序也可能有多个“阶段”，这可能会影响多个文件。我确实知道至少有一个操作系统记录了“第一阶段引导加载程序”和“第二阶段引导加载程序”，更不用说稍后启动的“内核”了。因此，对引导的担忧不仅仅局限于初始引导扇区。

原因#4：数据可能正在使用中

我被告知的主要原因是注册表不会被复制。但是机器上的所有内容肯定都是某个地方的文件吗？

我不会相信这一点。我确实相信，一旦 Windows 启动，它可能会将某些注册表存储在内存中或某种缓存文件中。即使注册表存储在磁盘上，其中一些也可能位于另一个文件中（例如“DataThatStillNeedsToBeWritten”文件），并且 Windows 的运行副本可能会记住“我仍然有一些数据需要写入”。

Windows GUI 复制主注册表文件后，Windows 可能会执行一些它需要执行的工作，例如从缓存文件中获取文件以移动数据（我在本示例中将其称为一个可笑的名称，“DataThatStillNeedsToBeWritten”） ") 到主注册表文件中。

当 Windows GUI 开始复制“DataThatStillNeedsToBeWritten”缓存文件时，该文件不再包含现在已复制到注册表的详细信息。

现在，如果您的计算机断电，Windows 经常可以很好地恢复（也许可以通过运行 ChkDsk 的帮助）。但是，在复制 D: 上的文件时，某些关键数据可能永远不会成功复制，因此 Windows 的新“副本”可能无法成功恢复。

这整个概念就是微软开发一些复杂技术的原因，例如 Windows 的“卷影复制服务”（通常缩写为 VSS 或 VSC；这两个缩写用于指代同一事物）。这些问题就是为什么备份软件可能会获取“系统状态”，并且流行的备份软件产品可能有专门的插件用于与 SQL 数据库和电子邮件交互（因为此类数据通常保持在线/可用，并且积极地被使用）。用过的）。

评论

请注意，我并不是说这些是唯一的问题。这些只是我很快想到的一些。随着新版本的出现，Microsoft Windows 平台变得更加复杂。（XP 明显比 2K/ME 更复杂，XP Service Pack 2 也引入了显着的复杂性，Vista 也是如此，可能是 7 个，当然是 8 个，并且根据此跟踪记录，我确信 10 也是如此。）可能缺少一些原因，特别是因为未来新版本将继续增加更多复杂性。

解决方案

帮助解决这些问题的两个技巧：

• 如果 Windows 从另一个硬盘驱动器启动，则通常可以复制 Windows 的休眠副本，而这些问题较少。
• 支持“快照”的软件通常具有特殊代码来尝试考虑其中的许多问题。