VSS 下的注册表备份和还原操作
Windows 注册表服务支持名为注册表编写器的 VSS 编写器,它允许请求者使用存储在卷影复制卷上的数据备份系统注册表。 有关注册表编写器的详细信息,请参阅 内置 VSS 编写器。
注册表编写器执行注册表的就地备份和还原。 此外,注册表编写器仅报告系统配置单元;它不报告用户配置单元。
Windows Server 2003: 注册表编写器使用中间存储库文件 (也称为 spit 文件) 来存储注册表数据。 此外,注册表编写器还会报告系统配置单元和用户配置单元。
注册表编写器的编写器 ID 为 AFBAB4A2-367D-4D15-A586-71DBB18F8485。
Windowsxp: 没有注册表编写器。 注册表数据由可启动状态编写器报告,其编写器 ID 为 F2436E37-09F5-41AF-9B2A-4CA2435DBFD5。
注意
Microsoft 不提供开发人员或 IT 专业人员的技术支持,以在 Windows 上实现联机系统状态还原 (所有版本) 。 有关使用 Microsoft 提供的 API 和过程实现联机系统状态还原的信息,请参阅 MSDN 社区中心提供的社区资源。
注意
以下信息仅适用于 Windows Server 2003 和 Windows XP。
使用 VSS 的注册表备份
注册表编写器将导出活动注册表文件并将其保存在由系统\CurrentControlSet\控件\配置单元HKEY_LOCAL_MACHINE\项定义的位置。
此注册表项下的值的名称标识要保存的注册表配置单元,并且该值的数据提供包含文件的文件 (hive 文件) 。 配置单元文件使用以下格式指定:\Device\HarddiskVolumeX\路径\文件名。
例如,在 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\hivelist 下,你可能会看到 \REGISTRY\MACHINE\SOFTWARE = \Device\HarddiskVolume1\Windows\System32\config\SOFTWARE。
注册表编写器确保 Hive 文件在卷影复制之前保存到磁盘。
备份注册表配置单元时,请求者会将 \Device\HarddiskVolumeX 替换为卷影副本 的设备对象 字符串。
注意
可以使用 QueryDosDevice 函数将 \Device\HarddiskVolumeX 路径转换为等效的 Win32 路径。 有关详细信息,请参阅 从文件句柄获取文件名 或 显示卷路径名称。
使用非 VSS Win32 API 还原注册表
注意
Windows Server 2016 及更高版本不支持注册表还原。
对于联机 (安全模式或完整操作系统) 还原,必须保留 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\控制\会话管理器\PendingFileRenameOperations 注册表项中的子项。
MoveFileEx 和 MoveFileTransacted 函数使用此注册表项来存储有关使用 dwFlags 参数中的 MOVEFILE_DELAY_UNTIL_REBOOT 值重命名的文件的信息。
若要保留 PendingFileRenameOperations 注册表项的内容,备份应用程序应调用 RegLoadKey 函数以连接要还原到活动注册表的注册表文件。 然后,备份应用程序可以使用各种注册表函数将所需的键和值复制到加载的配置单元中。 复制完成后,应调用 RegFlushKey 和 RegUnloadKey 函数。
对于脱机 (Windows 恢复环境或 Windows PE) 还原,无需遵循 PendingFileRenameOperations 注册表项。
在 Windows Server 2003 中使用非 VSS Win32 API 还原注册表
注意
以下信息仅适用于在 Windows Server 2003 中执行的与灾难恢复相关的还原操作, (也称为裸机恢复) 。
还原注册表时,备份应用程序需要将当前注册表中的某些子项移动到要还原的注册表中。
为此,备份应用程序可以调用 RegLoadKey 来连接要还原到当前活动注册表的注册表文件。 然后,它可以使用各种注册表函数将所需的键和值复制到加载的配置单元中。 复制完成后,将调用 RegFlushKey 和 RegUnloadKey 。
有一个注册表项指示还原应用程序 (请求者) 不应在还原时覆盖 HKEY_LOCAL_MACHINE\SYSTEM 下的注册表项:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\BackupRestore\KeysNotToRestore
系统状态还原过程的一部分涉及还原以前备份的注册表。
还原 HKEY_LOCAL_MACHINE\SYSTEM 配置单元时,备份应用程序需要格加小心,因为安装临时版本的 Windows 操作系统的过程中会在新安装的系统配置单元中建立密钥,其值必须在还原操作中保留下来。
例如,当更换系统的网络接口卡不同于原始系统时,还原前一张卡的原始密钥将导致不可预知的结果。 这是因为即插即用服务已检测到正确的服务和驱动程序注册表项并将其放入注册表中。 必须保留这些值才能在系统还原后正确启动。
本部分介绍备份应用程序在执行还原 HKEY_LOCAL_MACHINE\SYSTEM 配置单元时如何发现要保留的密钥和文件。 在某些情况下,这将涉及以编程方式将密钥从新安装的安装配置单元复制到要还原的配置单元中。 在其他情况下,确保不替换产品的注册表项与在产品的 INF 配置文件中指定此类键一样简单。
将 (键和要保留的密钥数据) 枚举在 HKEY_LOCAL_MACHINE\SYSTEM 配置单元下
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore\KeysNotToRestore
key 作为REG_MULTI_SZ字符串集, (本文档) 中称为 键字符串 。
备份应用程序 (请求者) 必须检查活动注册表和新还原的注册表中的这些项的值,因为任何应用程序或服务都可以随时添加值。
备份应用程序如何解释密钥字符串取决于其终端字符:
以反斜杠 ('\') 结尾的键字符串被解释为子项。 遇到此类子字符串时,备份应用程序必须保留所有数据和所有从属键。
例如,以下内容指定在还原操作中保留所有从属键和数据:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\dmio\boot信息\
为此,必须将此密钥以及所有从属项和数据从现有注册表 (即 Windows) 安装创建的注册表复制到新还原的注册表中。 这称为 密钥替换 操作。 此操作将替换还原的注册表中的相应项。
终止字符为星号 ('*') 的键字符串指定应合并所有子项。 例如,键字符串:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\*
指定现有注册表中的服务项 (例如,由 Windows) 安装创建的服务键必须合并到还原的注册表中。 这称为 密钥合并 操作,如果现有配置单元和已还原配置单元中都存在子项,则会保留还原目录中的密钥,但存在以下例外情况:
- 如果现有配置单元中的子项包含名为“start”的值,并且还原的 子项不包含。
- 如果现有和已还原配置单元中的子项都包含名为“start”的值,并且它在现有配置单元中的数值较小。
注册表中的“start”值指定服务或驱动程序何时启动,并且可以具有介于 0-4 的数值。 值越低,服务在启动过程中越早启动。
如果此密钥同时存在于现有目录和已还原目录中,则必须检查每个配置单元中的开始键的值。 如果现有配置单元中的值小于还原目录中的值,则必须保留较低的值。
同样,此密钥用于确定服务或驱动程序是在启动时启动、在系统时间启动、手动启动、自动启动还是禁用。 较小的值表示较早的开始时间。 必须将较早的开始时间应用于新注册表,以确保服务或驱动程序在下一次启动时正确启动。
其终止字符既不是反斜杠也不是星号的键字符串将被解释为要保留的注册表值。
例如,键字符串:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations
以编程方式保留密钥的机制涉及 Win32 注册表 API。 例如,下面枚举了一种算法:
将备份的系统配置单元文件还原到文件。 在此示例中,将名称命名为 System.reg。
使用 RegLoadKey 以临时名称将 System.reg 加载到 HKEY_LOCAL_MACHINE 中。 例如,其中一个名称可能是
HKEY_LOCAL_MACHINE\TMP_SYSTEM
从两个注册表副本中枚举 KeysNotToRestore 子项中的值,并创建列表的超集。 从现有的 复制每个此类密钥
HKEY_LOCAL_MACHINE\SYSTEM
键到
HKEY_LOCAL_MACHINE\TMP_SYSTEM
根据上述语义进行键。
完成后,使用 RegFlushKey&RegUnloadKey 入口点保存
HKEY_LOCAL_MACHINE\TMP_SYSTEM
将 键返回到 System.reg。
最后,使用 RegReplaceKey 指定 System.reg 替换
HKEY_LOCAL_MACHINE\SYSTEM
hive 文件 SYSTEM。
反馈
https://aka.ms/ContentUserFeedback。
即将发布:在整个 2024 年,我们将逐步淘汰作为内容反馈机制的“GitHub 问题”,并将其取代为新的反馈系统。 有关详细信息,请参阅:提交和查看相关反馈