我想知道是否有其他人这样做并随后遇到了任何问题，或者是否根据我的描述，任何人都可以提出我可能遇到的问题类型：
我将 Windows 2008 R2 数据中心作为我的 Hyper-v 主机，并在其上运行 Windows 2008 R2 Ent 来宾虚拟机。
在进行重大更新之前，我保存了来宾 VHD 文件的副本（这是来宾 VM 上的 C: 驱动器）。这不是快照，只是 VHD 文件的复制/粘贴。
在 SQL Server 2012 升级遇到一些困难和挫折后，我决定放弃故障排除（我有一个很短的维护窗口可以使用）——而是停止了虚拟机。然后将 VHD 文件更改为我之前保存的上一个副本。
VM 启动但未被域控制器识别。我将其删除并重新添加到域中，之后没有出现重大问题。我完成了升级，没有出现以前的问题，并且安装了 Windows 更新也没有问题。
这被认为是不好的做法吗？我可以保持这个 VM 不变，还是需要从头开始重建以避免操作系统出现异常？如果您是首席系统管理员并且这是一个生产箱，您会允许吗？谢谢
域成员定期同步域成员凭据。当系统长时间离线时，域将不再识别系统凭据。只要您不重命名系统，您就可以重新加入域而不会出现问题，您也可以尝试
NLTEST /SC_RESET:domain_name\DC_name而不是重新加入域首先，您需要了解（可能知道也可能不知道）有关 Windows 机器/域的一些基本概念：
计算机和用户一样是安全主体
名称只是对基础 SID 的人性化引用
计算机在启动时向域进行身份验证
计算机帐户也有密码（默认情况下每 30 天更改一次）
基本上，当你将旧的 VHD 卡在你的机器中时发生的事情是（我打赌），计算机帐户的本地密码与 DC 的计算机帐户密码不匹配，因为密码在备份之间的某个时间被更改你做了和你恢复它的时间。因此，域控制器不会让计算机进行身份验证，您看到的错误是信任关系失败。
这依赖于一两个假设，最值得注意的是您的备份和失败的机器没有不同的 SID，这也会破坏域信任。当您重命名计算机或将计算机加入与现有帐户同名的域时，通常会发生这种情况。新重命名的计算机将尝试使用其新 SID 进行身份验证，但名称映射到旧 SID，因此当 AD 检查时，SID 不匹配并且身份验证失败。
因此，无论哪种方式，当您“恢复”旧备份时，您基本上都会破坏 VM 和域之间的身份验证。我相信你能明白为什么这很糟糕。（如果只是机器密码而不是不同的 SID，那就没那么糟糕了，这一点值得一提。）
为什么像您那样做是“不好的做法”是主观的，并且会从不同的管理员那里得到不同的答案（或不同的具体问题），但我的回答基本上是这是不好的做法，因为有更好的方法可以做到这一点破坏域身份验证或增加复杂性和未知数。（备份有多久了？从那时到现在系统发生了什么变化？依赖于那些可能会破坏或导致极其难以解决问题的变化的是什么？等等）这也是不好的做法，因为听起来你没有实际的，有效的备份，或在需要时从 [真实] 备份恢复的快速过程。这非常糟糕，出于我希望您不需要澄清的原因。
说了这么多，听起来你还是比较安全的。（当然，假设旧备份没有丢失大量 SQL 数据，或者安装了旧版本的东西，或者任何类似的基本内容。）不同的计算机帐户密码不会在任何地方被引用，而且通常你的计算机的完整 SID 也不会被 AD 之外的很多引用，因此更改它应该不会引起问题。（但就像任何曾经来过一两次街区的管理员一样，我看到了一些会让你的血液凝固并导致我排位赛的东西，否则这些东西将是绝对的陈述。）
希望这会有所帮助。
问题是用域控制器来做。它有一个带有唯一编号的数据库，这些编号与其他域控制器共享并保持同步。突然将其中一个恢复为旧的不同步数字是个坏主意。
编辑：也许我有点简短。让我再补充三点：