Google 会使用 AI 技术将内容翻译成您偏好的语言。AI 翻译可能包含错误。

在备份/恢复设备上备份和恢复 Microsoft SQL Server

捕获 SQL Server 数据

借助 Backup and DR，您可以捕获以下类型的 Microsoft SQL Server 应用：

实例
Always On 可用性组中的数据库
数据库一致性组
单个数据库
系统数据库
用户数据库
虚拟机中的数据库

Backup and DR 会将 Microsoft SQL Server 数据移至 Microsoft SQL Server 写入其主存储的位置之外，并单独进行管理。

备份/恢复设备会将应用数据存储在暂存磁盘上。暂存磁盘上的快照可让备份/恢复设备维护历史数据。

准备备份 Microsoft SQL Server 数据

准备备份 Microsoft SQL Server 数据包括四个步骤：

添加托管 Microsoft SQL Server 数据库的服务器。
发现虚拟机和 Microsoft SQL Server 数据库。
根据 RPO 和 RTO 定义 Backup and DR 政策模板和资源配置文件。

使用 Microsoft SQL Server 完整恢复模型的数据库可以同时捕获数据库及其日志。因此，可以通过前滚日志将捕获的数据库恢复到某个时间点。
将 Backup and DR 政策模板和资源配置文件分配给 Microsoft SQL Server 数据库。

数据捕获

捕获数据时，请考虑以下事项：

系统会自动创建暂存磁盘并将其装载到服务器上。
系统会向暂存磁盘创建初始完整副本。后续副本仅包含已更改的块。
暂存磁盘已从服务器卸载。
在备份/恢复设备上创建暂存磁盘的快照。

捕获 SQL Server 数据库日志

数据库日志捕获在快照政策的详细信息和设置中设置。它使单个快照政策能够捕获 Microsoft SQL Server 数据库和包含 Microsoft SQL Server 数据库的一致性组的日志。

数据库日志的捕获频率与数据库的捕获频率是分开定义的。例如，可以每天捕获一次数据库，每小时捕获一次其日志。

数据库日志备份的频率以分钟为单位设置，并且捕获日志的频率不得超过捕获其关联数据库的频率。例如，如果数据库捕获频率为每 24 小时一次，则日志文件捕获频率必须等于或小于每 24 小时一次。

日志保留期限也是与其关联的数据库分开定义的。通过设置不同的保留期限，您可以保留足够的日志信息，以涵盖数据库的所有快照和 OnVault 版本。例如，如果数据库的快照数据保留三天，其 OnVault 数据保留七天，则您可以将日志保留期限定义为涵盖所有七天。在此示例中，您可以选择单个捕获的数据库，并将其日志在整个时间段内向前滚动。

数据库日志会暂存到 Backup and DR 快照池中的单个暂存磁盘。为了节省快照池中的空间，您可以使用高级设置来指示数据库压缩其日志。

您可以指定将 Microsoft SQL Server 数据库事务日志复制到远程备份/恢复设备。对于复制的日志保留范围内的任何数据库，您都可以使用远程站点上的日志。

调整数据库日志的暂存磁盘大小

Backup and DR 会自动管理容纳数据库日志备份所需的物理空间。这称为日志暂存磁盘，与源服务器管理的存储空间分开。Backup and DR 至少会评估典型日志大小及其保留期限，并在需要时使用更大的磁盘。

为了更高效、更有效地管理数据库日志的存储要求，快照政策提供了以下高级设置：

日志备份保留期限：日志保留期限与其关联的数据库分开定义。通过设置不同的保留率，您可以保留足够的日志信息，以涵盖数据库的所有快照版本。日志保留期限是必填设置。
日志暂存磁盘大小增长：定义日志所在的暂存磁盘自动增长的百分比。
Estimated Change Rate（估计变化率）：定义每日变化（百分比），使备份/恢复设备能够更好地计算保存日志所需的暂存磁盘的大小。
压缩数据库日志备份：指示源数据库在备份/恢复设备上捕获日志之前压缩其日志。数据库服务器在日志备份期间执行日志压缩（默认设置为已启用）。

SQL Server 数据捕获选项

以下部分介绍了 SQL Server 数据捕获选项。

捕获实例、单个数据库和数据库组

Backup and DR 代理用于捕获物理服务器和虚拟服务器上的实例、用户数据库、系统数据库和数据库组。

捕获 SQL Server 实例时，您可以选择捕获整个实例或实例中的选定数据库。当您保护整个实例时，随着数据库添加到实例中，它们会自动包含在下一个 Backup and DR 捕获作业中。实例中的数据库会通过单个备份方案一起静默和捕获。

如果在备份方案政策中启用了 Backup and DR 数据库和日志捕获，则该实例中的所有数据库都可以恢复到同一时间点。实例中所有或单个数据库的日志恢复和前滚操作均可通过 Backup and DR 界面一键完成。

您可以根据需要通过装载、克隆、LiveClone 和恢复操作访问实例的各个成员。

捕获一致性组

一致性组是指一组数据库，这些数据库通过单个备份方案政策模板和资源配置文件一起静默和捕获。一致性组的成员资格是手动分配的，适用于成员不经常更改的数据库群组。如需自动保护一组数据库的新成员，请改为在 SQL Server 实例中创建和保护这些数据库。

顾名思义，一致性组可确保跨多个数据库进行一致的时间点捕获和恢复。如果在备份方案政策中启用了 Backup and DR 的数据库和日志捕获技术，则该组中的所有数据库都可以恢复到同一时间点。一致性组中所有或单个数据库的日志恢复和前滚操作可通过 Backup and DR 界面一键完成。一致性组的成员必须位于同一实例中。

一致性组可以由以下各项组成：

一个或多个系统数据库
一个或多个用户数据库
系统或用户数据库
零个或多个文件系统（驱动器盘符或装载点）

一致性组的各个成员可以通过装载、克隆、LiveClone 和恢复操作进行访问。

必须从活跃节点发现集群故障切换实例中的数据库。受保护后，GO 会跟随集群中的活跃 SQL 节点。即使在故障切换条件下，保护作业也会继续运行。除了加快捕获和访问操作之外，一致性组消耗的系统资源（虚拟磁盘）也比单独保护数据库要少。

您可以通过将备份装载到服务器并运行数据库一致性检查，定期验证数据库备份的完整性。您可以使用工作流功能自动执行验证过程。

捕获虚拟机的数据库和启动卷

在虚拟机上捕获数据库时，您还可以选择捕获虚拟机的启动卷。当虚拟机的启动卷与其数据库一起捕获时，可以提供一个功能齐全的数据库和虚拟机备份。然后，可以将备份迁移到新的永久位置。

复制 SQL Server 数据

数据可以复制到第二个备份/恢复设备或云端，以用于恢复、灾难恢复或测试或开发目的。长期以来，数据复制一直是地理分布式环境中高效数据管理的阻碍因素。Backup and DR 复制通过以下压缩方式解决这些问题：

降低整体网络用量。
无需专用 WAN 加速器或优化器。
使用 AES-256 加密标准加密数据。备份/恢复设备之间的身份验证使用 1024 位证书执行。

复制由 Backup and DR 政策模板政策控制：

生产环境到镜像政策有多个选项可将数据复制到第二个备份/恢复设备。
Production to OnVault 政策使用 Backup and DR 专有引擎将数据传输到对象存储区。

复制日志

当政策的启用数据库日志备份设置为启用时，复制日志高级设置允许将 Microsoft SQL Server 数据库事务日志复制到远程备份/恢复设备。如需运行日志复制任务，模板中必须包含 StreamSnap 复制政策以及指定远程备份/恢复设备的资源配置文件，并且必须先成功完成至少一次数据库复制。然后，您可以使用远程站点上的日志，在复制日志的保留范围内进行任何数据库备份。此功能默认处于启用状态。

日志复制使用 StreamSnap 技术在本地和远程备份/恢复设备之间执行复制；日志复制直接从本地快照池到远程设备上的快照池。

日志也可能会复制到 OnVault 池。启用后（非默认），日志会发送到由有效 OnVault 政策或资源配置文件组合指定的每个 OnVault 池（例如，在政策中选择 OnVault 池 1，并在资源配置文件中指定 OnVault 池 1）。OnVault 池中的日志保留期限始终与快照池中的日志保留期限一致。

访问 SQL Server 数据

对于使用完整恢复模型的 Microsoft SQL Server 数据库，Backup and DR 可以即时呈现前滚到特定时间点的数据库副本。前滚操作在设备管理控制台中指定。

对于使用基本恢复模型的 Microsoft SQL Server 数据库，Backup and DR 可以即时呈现尚未超过保留期限的任何数据库备份。

无论使用哪种 Microsoft SQL Server 恢复模型，都可以使用 iSCSI 接口访问 Microsoft SQL Server 数据。如果您使用的是 VMware (GCVE)，也可以使用提供给 ESXi 主机的 NFS 数据存储区来访问数据。

基于角色的访问控制

您可以控制哪些用户有权访问数据、Backup and DR 功能和资源。捕获的数据可以标记为敏感数据，并且可以向 Backup and DR 用户授予对敏感数据的访问权限。

支架

Backup and DR 装载功能可让您即时访问数据，而无需移动数据。您可以使用 Backup and DR 界面前滚捕获的数据库副本，并将其装载到任何数据库服务器上。Backup and DR 提供了两种装载 Microsoft SQL Server 数据库的方法：

虚拟应用装载会将捕获的 Microsoft SQL Server 数据作为 Microsoft SQL Server 数据库呈现并提供给目标服务器。这样，您就可以创建和管理生产数据库的副本，以用于非生产用途。虚拟应用装载通过备份/恢复设备创建，不需要数据库、服务器或存储管理员的手动干预。虚拟应用装载可用于数据库报告、分析、完整性测试以及测试和开发。将 SQL Server 数据库装载为新的虚拟数据库和将数据库装载到 SQL Always On 可用性组中详细介绍了虚拟数据库。
标准装载（也称为直接装载）将捕获的 Microsoft SQL Server 数据作为文件系统（而非数据库）呈现并提供给目标服务器。如果数据库损坏、丢失或数据库服务器正在更换，此功能非常有用。在这种情况下，您无法使用恢复操作来恢复数据库。您可以改为装载备份，并将数据库文件从装载的备份复制到数据库服务器上的原始位置。装载捕获的 Microsoft SQL 数据中详细介绍了直接装载。

LiveClones

LiveClone 是 Microsoft SQL Server 数据的独立副本，可在提供给用户之前进行刷新和遮盖。这样，开发和测试团队就可以处理最新数据集，而无需手动管理数据或干扰生产环境。

克朗斯

克隆功能会将商品数据的副本移至与来源不同的位置。完成克隆操作所需的时间取决于所涉及的数据量。克隆 SQL Server 数据库中详细介绍了克隆。

恢复

恢复操作会将生产数据还原到指定的时间点。恢复操作实际上会移动数据。恢复操作通常在发生大规模数据损坏后执行。完成恢复操作所需的时间取决于所涉及的数据量。

如需恢复数据库，然后应用日志，恢复的数据库必须处于恢复模式。您可以在恢复模式下恢复数据库，然后将日志前滚到特定时间点。如果您在恢复数据库时未指定恢复但不恢复，则系统会恢复数据库并使其上线，而不会应用日志。恢复 SQL Server 数据库中详细介绍了恢复。如需实现近乎零停机时间的恢复，请先装载数据，如装载和迁移 SQL 数据中所述。

自动访问 SQL Server 数据的 Workflows

Workflows 自动访问捕获的 Microsoft SQL Server 数据。Workflows 可以将数据呈现为直接装载或 LiveClone：

直接装载（标准或 Application Awareness）非常适合在呈现之前不需要遮盖的 Microsoft SQL Server 数据。装载的数据副本可以手动刷新，也可以按时间表自动刷新。通过直接装载，您可以即时访问捕获的 Microsoft SQL Server 数据，而无需实际移动数据。
LiveClone 是生产 Microsoft SQL Server 数据的副本，可以手动或按计划进行更新。您可以在 LiveClone 中遮盖敏感数据，然后再将其提供给用户。

将 Backup and DR 的自动化 Microsoft SQL Server 数据捕获和访问权限控制与工作流及其可选的数据遮盖功能相结合，可让您创建自助预配环境。用户几乎可以即时预配自己的环境。

例如，Backup and DR 管理员可以创建备份模板政策，以便根据指定的时间表捕获 Microsoft SQL Server 数据。管理员可以将捕获的生产 Microsoft SQL Server 数据标记为敏感数据，并且只有具有适当访问权限的用户才能访问。

定义访问权限并捕获数据后，管理员可以创建执行以下操作的工作流：

使捕获的 Microsoft SQL Server 数据可用作 LiveClone 或直接装载。
按计划或按需更新 LiveClone 或可装载的 Microsoft SQL Server 数据
（可选）在每次更新后自动将脚本应用于 LiveClone 的 Microsoft SQL Server 数据。这对于遮盖敏感的 Microsoft SQL Server 数据非常有用。

工作流完成后，具有适当访问权限的用户可以使用 LiveClone 或可装载的 Microsoft SQL Server 数据预配其环境。

Backup and DR 与现有备份产品搭配使用

随着越来越多的企业希望使用生产数据库来加快应用开发速度，Backup and DR 通常需要与在同一生产数据库环境中运行的旧版备份产品共存。如果遵循这些最佳实践，Backup and DR 可以与其他从生产数据库捕获数据的产品完美共存。

Backup and DR 具有专有的变更块跟踪方法，因此使用 SQL 或其他方法获取备份的备份解决方案不会受到预定的 Backup and DR 数据捕获作业的影响。

备份作业可能会占用大量 I/O。它们可能需要很长时间，并且可能会在备份窗口期间影响数据库的性能。Backup and DR 可最大限度地减少作业期间的影响，但即使是块级永久增量更新也必须生成一些 I/O，并且必须花费一些时间。

要求	请勿安排旧版备份软件和 Backup and DR 以时间重叠的方式运行作业。
最佳实践	安排 Backup and DR 数据库作业在旧版备份软件应完成的时间开始。请勿将旧版备份软件安排在 Backup and DR 作业通常完成之后立即运行。
原因	如果旧版备份作业和 Backup and DR 作业同时运行，可能会对数据库服务器造成严重的性能影响，导致不稳定，甚至可能导致服务中断。

数据库日志用于捕获数据库中的各个事务，从而实现时间点恢复。大多数敏捷性用例都围绕定期从生产环境获取数据库快照。常见频率从每天到每周或每两周一次，具体取决于应用场景。因此，应用开发者通常不需要将非生产实例定位到源（生产）中的特定时间点。这样通常就无需在 Backup and DR 敏捷性解决方案中捕获和管理日志。

要求	只能有一个系统管理（捕获或截断 [清除]）日志，即旧版备份软件或 Backup and DR。
最佳实践	继续允许由旧版备份软件执行所有日志管理，请勿使用 Backup and DR 保护此环境中的日志。
原因	如果您的系统配置为管理（捕获或截断 [清除]）日志，并且旧版备份软件也在捕获和/或截断/清除日志，则一个或两个系统最终可能会出现不完整的日志链，从而导致难以或无法将数据库恢复到特定时间点。

适用于 Microsoft SQL Server 的 Backup and DR 的其他文档

本页面是专门介绍如何使用 Backup and DR 保护和恢复 Microsoft SQL Server 数据库的系列页面之一。如需了解更多信息，请参阅：