遵循这些最佳实践有助于您避免用户在 Backup and DR Service 设备管理控制台中创建和修改政策模板时犯的一些较为常见的错误。
您需要根据恢复点目标 (RPO) 和恢复时间目标 (RTO) 配置政策模板。随着时间的推移，您可能需要对这些模板进行更改。
初始数据备份捕获
当政策模板中的政策首次创建应用的数据备份时，会备份所有数据。后续备份将为增量备份。
如需使用一个政策模板保护多个应用，只需将该政策模板应用于其中几个应用即可。初始完整数据捕获完成后，将政策模板应用于更多应用。重复此过程，直到政策模板已应用于所有应用。
调整卷大小
如果您调整包含受保护数据的卷的大小，对于某些应用类型，该卷的快照政策下次运行时可能会执行完整备份操作；无论该卷的数据过去已备份过多少次。这些备份包括调整大小后的 VMware VMDK，以及基于代理的 Microsoft Windows 应用和非 LVM Linux 应用备份。
如果您必须调整受影响的应用类型所用卷的大小，请考虑捕获所有数据会对应用服务器、网络以及备份/恢复设备产生的影响。
作业并发数
默认情况下，备份/恢复设备可以同时运行六个快照作业。如果您安排在同一时间段运行的作业数量超过允许的数量，政策调度程序将启动允许数量的作业，并将其他作业放入队列中。
由于每个用户的网络设计、数据布局和存储类各不相同，因此请通过实验来确定最佳并发作业数。
政策时间表
设备管理控制台支持在配置政策时通过以下两种方法指定政策时间表：
- 窗口化。定义遵循特定频率和时间窗口的离散快照备份时间表（例如，每 30 分钟执行一次备份，每天从世界协调时间 [UTC] 09:00 到 17:00 执行备份）。您可以指示备份/恢复设备以指定的频率间隔运行多个备份作业，也可以指示其在指定的时间窗口内运行一次。
- 持续。定义连续快照备份时间表（例如，每 8 小时执行一次备份作业，第一次作业从 01:00 UTC 开始）。在此政策安排中，作业会以指定的时间间隔持续运行（全天候）。
频次计算
周期是指计划运行之间的时间，而频次是指单位时间内运行的作业数。例如，如果某个时间表要求每 4 小时运行一次作业，则周期为 4 小时，预期频率为每天 6 次。如果作业需要 1 小时才能完成，而政策的频次为 12 小时，则政策的作业将在上一个作业完成后 11 小时再次运行。
请务必选择能够实现所需恢复点目标 (RPO) 且有足够时间完成作业的频率。
- 建议快照政策的最低频率为 1 小时（本地 RPO）。
- StreamSnap 政策可以指向任何频率为 1 小时或更长（远程 RPO）的 Snapshot 政策。
备份方案政策中的数据库日志保护
为数据库创建快照政策时，您还可以选择以指定频率捕获其日志文件。数据库日志的捕获频率与数据库的频率是分开定义的。例如，可以每天捕获一次数据库，每小时捕获一次数据库日志。
数据库日志备份的频率以分钟为单位设置，捕获日志的频率不得超过捕获关联数据库的频率。例如，如果数据库捕获频率为每 24 小时一次，则日志文件捕获频率必须低于每 24 小时一次。
频率和保留期限在数据库的快照政策的高级设置中定义。日志捕获不考虑日期边界、窗口或关联数据库的捕获频率。
您可以通过备份方案快照政策中的启用数据库日志备份高级设置来启用日志保护功能。频次和保留时间也在备份方案政策的高级设置中定义。
设备管理控制台会自动管理容纳数据库日志所需的物理空间。设备管理控制台至少会评估典型日志大小及其保留期限，并根据需要添加空间。
如需启用日志备份并更高效、更有效地管理数据库日志的存储空间要求，请参阅下表。
| 设置 | 输入 |
|---|---|
| 备份后截断或清除日志 | 必须设置为“是”才能清除生产日志。选择此选项可管理日志清除。这会在每次日志备份结束时运行日志清除。默认值为“不截断”。 |
| 如果将启用数据库日志备份设置为 No，并将备份后截断或清除日志设置为 Yes，则日志清除会在每次数据库备份结束时运行，清除所有日志。 | |
| 日志备份保留期限 | Backup and DR 暂存磁盘下的日志备份将保留到此处设置的值。备份日志保留期限可以不同于快照保留期限。 |
| 日志暂存磁盘增长大小 | 设置在需要时将日志备份过渡磁盘扩容的百分比。 |
| 估算的变化率 | 估计数据库数据每天的变化百分比。 |
| 压缩数据库日志备份 | 使用此标志可启用数据库日志备份，以使用应用级数据库 API 在压缩模式下运行。 |
| 启用数据库日志备份 | 借助启用数据库日志备份选项，备份计划政策可以备份数据库和所有关联的日志文件。当日志备份作业运行时，系统会备份日志。选项为 Yes 或 No。如果设置为“Yes”，则会启用相关选项。 |
| RPO | 当“启用数据库日志备份”设置为“是”时，RPO 会定义数据库日志备份的频率。频次以分钟为单位设置，不得超过数据库备份间隔。 |
| 复制日志 | （使用 StreamSnap 技术）当“启用数据库日志备份”设置为“启用”时，“复制日志”高级设置允许将数据库日志备份复制到远程备份/恢复设备。若要运行日志备份复制作业，模板中必须包含 StreamSnap 复制政策以及指定远程备份/恢复设备的资源配置文件，并且必须先成功完成至少一次数据库复制。然后，您可以使用远程站点中的日志备份来备份复制的日志备份保留范围内的任何数据库。此功能默认处于启用状态。 |
| 日志复制使用 StreamSnap 技术在本地和远程备份/恢复设备之间执行复制；日志复制直接从本地快照池到远程设备上的快照池。 | |
| 注意：在数据库受到保护且数据库备份已复制到远程备份/恢复设备之前，不会发生日志复制。 | |
| 将日志发送到 OnVault 池 | 设置为“是”后，日志将复制到一个或多个 OnVault 存储池，从而能够从其他网站上的 OnVault 池进行时间点恢复。 |
作业优先级和调度
所有活动都作为作业运行。作业会根据创建政策时配置的时间表执行。
有些作业的耗时比其他作业长得多。过期作业速度快。 快照作业取决于应用或虚拟机的大小以及自上次快照以来更改的数据量等变量；任何应用或虚拟机的初始快照都是全新数据，因此可能需要很长时间。
政策调度程序会确定何时运行应用于应用的一项或多项政策，然后在到达预定的开始时间时，启动将政策放入队列中的作业。每种政策类型都有一个步调机制，以确保系统不会因运行过多的作业而过载。此步调控制机制使用作业槽来实现这种稳态，这意味着即使作业应该在特定时间开始，也只有在作业槽可用时才会执行。
如果多个应用安排在同一时间运行，且具有相同的作业优先级，系统会随机选择要运行的应用，以确保所有具有相同优先级的应用都能公平地获得运行机会。
作业重试
当作业失败时，调度器会自动重试运行该作业。 如果作业首次失败，调度程序将等待 4 分钟，然后才允许重试。如果作业尝试失败 3 次，系统会将该作业标记为“失败”，并且不再重试。系统将根据政策的时间表尝试执行下一个作业。
调度程序会将作业重试视为任何其他可用作业。如果可用的作业多于可容纳它们的槽，则作业会排入队列。这可能会导致重试无法在窗口内开始，并且作业被标记为失败。
作业重试会在监控中报告。为了标识作业重试，监控应用会先在每个重试作业的名称中附加“a”，然后附加“b”，最后附加“c”。
影响 RPO 合规性的变量
网络拥堵：网络上的其他活动可能会减慢数据传输速度。确保您可以持续提供用于 RPO 大小调整的带宽。在 Google Cloud上运行时，这通常不是问题，但在保护裸金属解决方案服务器上的 Oracle 数据库时，这可能很重要。
其他正在运行的作业：如果您打算频繁装载虚拟克隆（例如，用于测试数据管理），或者预计需要经常恢复数据，请考虑这些作业的 I/O 影响。挂载或恢复等恢复作业通常在系统中具有最高优先级，会从正在进行的备份作业中占用资源。
工作负载的变化率高于正常水平：有时，用户执行的操作可能会导致变化率大幅升高。例如，重新为数据库编制索引或对数据库执行 ETL 操作可能会导致块级发生大规模更改。有时，用户会迁移工作负载（例如在数据中心之间迁移），因此可能需要进行全新的完整注入。您需要预先确定希望能够处理多少此类更改，同时仍能满足 RPO。如果客户生成的更改超过了约定的数量，服务提供商通常会排除 SLA 遵从情况。
更改块跟踪丢失：有时，更改块跟踪会丢失（例如，当服务器崩溃时）。虽然该服务具有处理此问题的机制，可通过扫描生产数据并重建更改来避免完全重新注入，但这比增量捕获花费的时间更长。您需要决定是否要在系统规模调整中考虑这一点。
变化的分布：最后，变化通常不会均匀分布。虽然系统的大小可能足以满足平均更改速率的 RPO，并且总体上满足 RPO，但仍可能会出现违规情况，尤其是在工作负载较大时。您可能会在每周、每月甚至每年中的某些天活动量更大，即使在一天之内，活动量的变化通常也是不均匀分布的。 如果您仅根据平均变化来确定系统规模，请注意，您会遇到违规情况，并在您与客户（内部或外部）之间定义的任何 RPO 存储 SLA 中考虑这一点并进行衡量。