Azure 备份提供内置的 规范和后标框架 ，以确保备份期间 Linux VM 的应用程序一致性。 此框架在磁盘快照之前自动运行一个预脚本以使应用程序静默，后脚本将应用程序还原到快照后的正常操作。
管理自定义描述词和后标通常很复杂且耗时。 为了简化此过程，Azure 备份为常用数据库提供随时可用的源脚本和后脚本，以最少的努力和维护量启用应用程序一致性快照。
下图说明了 Azure 备份如何使用增强的规范和后标来实现 Linux 数据库的应用程序一致性快照，以确保可靠的备份和恢复。
增强的前置脚本和后置脚本框架的主要优势
新的 增强 型规范和后标框架具有以下主要优势：
- 这些预脚本和后脚本及备份扩展直接安装在 Azure 虚拟机中，有助于避免创作和从外部位置下载。
- 可在 GitHub 上查看规范和后标的定义和内容。 可以通过 GitHub 提交建议和更改，这些将经过审核并贡献给更广泛的社区。
- 可通过GitHub获取为其他数据库提供的新前置脚本和后置脚本，这些问题已被分类和处理，旨在惠及更广泛的社区。
- 健壮的框架能够有效应对各种情境，例如脚本执行失败或系统崩溃。 在任何情况下，后脚本都会自动运行，以回滚在前脚本中完成的所有更改。
- 该框架还提供了一个 消息 传送通道，供外部工具提取更新，并在任何消息或事件上准备自己的行动计划。
增强的规范和后标框架的解决方案流
下图展示了用于数据库一致性快照的增强型前置脚本和后置脚本框架的解决方案流程。
支持矩阵
增强型框架下介绍了以下数据库：
- Oracle （已普遍可用）：请参阅 Azure VM 备份的支持矩阵。
- MySQL（预览版）。
必备条件
您只需在 /etc/azure 中修改配置文件 workload.conf，以提供连接详细信息。 这样，Azure 备份就可以连接到相关的应用程序，并运行前置脚本和后置脚本。 配置文件具有以下参数：
[workload]
# valid values are mysql, oracle
workload_name =
command_path =
linux_user =
credString =
ipc_folder =
timeout =
下表描述了参数。
| 参数 | 必需 | 说明 |
|---|---|---|
workload_name |
是 | 包含需要应用程序一致性备份的数据库的名称。 当前支持的值为 oracle 或 mysql。 |
command_path/configuration_path |
包含工作负荷二进制文件的路径。 如果工作负荷二进制文件设置为路径变量，则此字段不是必需的。 | |
linux_user |
是 | 包含有权访问数据库用户登录的 Linux 用户的用户名。 如果未设置此值，则根被视为默认用户。 |
credString |
表示用于连接到数据库的凭据字符串。 包含整个登录字符串。 | |
ipc_folder |
工作负荷只能写入某些文件系统路径。 提供此文件夹路径，以便规范可以将状态写入此文件夹路径。 | |
timeout |
是 | 数据库处于安静状态的最大时间限制。 默认值为 90 秒。 不要设置小于 60 秒的值。 |
注意
JSON 定义是 Azure 备份可能修改以适应特定数据库的模板。 若要了解每个数据库的配置文件，请参阅 每个数据库的手册。
使用增强的前置脚本和后置脚本框架的总体体验是：
- 准备数据库环境。
- 编辑配置文件。
- 触发 VM 备份。
- 根据需要从应用程序一致性恢复点还原 VM 或磁盘或文件。
生成数据库备份策略
使用快照而不是流式处理
通常，数据库管理员在他们的备份策略中使用流式处理备份（例如完整备份、差异备份或增量备份）和日志。 设计中的要点包括：
- 性能和成本：每日完整备份和日志是还原期间最快的，但涉及大量成本。 包含差异或增量的流式备份类型虽然可以降低成本，但可能会影响恢复性能。 但快照提供了性能和成本的最佳组合。 由于快照本质上是增量快照，因此它们对备份期间的性能影响最小，还原速度很快，同时节省成本。
- 对数据库或基础结构的影响：流式备份的性能取决于基础存储 IOPS 以及流面向远程位置时可用的网络带宽。 快照没有这一依赖性，对 IOPS 和网络带宽的需求减少。
- 可重用性：用于触发不同流式备份类型的命令对于每个数据库都是不同的，因此无法轻松重复使用脚本。 此外，如果使用不同的备份类型，请确保评估依赖项链以维持生命周期。 对于快照，编写脚本很容易，因为没有依赖链。
- 长期保留：完整备份始终有利于长期保留，因为可以独立移动和恢复备份。 对于操作性备份和短期保留，快照是首选的。
对于长期保留，每日快照加上偶尔完整备份的日志是数据库的最佳备份策略。
日志备份策略
增强的前脚本和后脚本框架构建在 Azure VM 备份上，每天安排进行一次备份。 因此，设置恢复点目标（RPO）为 24 小时的数据丢失窗口不适用于生产数据库。 此解决方案由日志备份策略进行补充，在该策略中，日志备份是显式流式传输出来的。
Azure Blob 存储上的网络文件系统（NFS）和AFS 上的 NFS（预览版）有助于在数据库虚拟机上轻松装载卷，并使用数据库客户端传输日志备份。 RPO 的数据丢失窗口取决于日志备份的频率。 此外，NFS 目标不需要高性能。 在获得数据库一致性快照后，您可能不需要为操作备份触发常规的流式处理（完整和增量）。
注意
增强的规范通常负责刷新传输到日志备份目标的所有日志事务，然后让数据库保持安静以拍摄快照。 因此，快照在恢复期间保持数据库一致性，且具有可靠性。
恢复策略
创建数据库一致性快照并将日志备份流式传输到 NFS 卷后，数据库的恢复策略可以使用 Azure VM 备份的恢复功能。 日志备份的功能也通过使用数据库客户端将其应用于它。 恢复策略的以下选项包括：
- 从数据库一致性恢复点创建新的 VM。 VM 应已连接日志装入点。 使用数据库客户端运行恢复命令，以实现时点还原。
- 从数据库一致性恢复点创建磁盘，并将其附加到另一个目标 VM。 然后挂载日志目标，并使用数据库客户端运行恢复命令以实现时间点恢复。
- 使用文件恢复选项并生成脚本。 在目标 VM 上运行脚本，并将恢复点附加为 iSCSI 磁盘。 然后，使用数据库客户端在附加磁盘上运行特定于数据库的验证函数，并验证备份数据。 此外，使用数据库客户端导出或恢复几个表或文件，而不是恢复整个数据库。
- 使用跨区域还原功能在发生区域性灾难期间从辅助配对区域执行上述操作。
摘要
借助使用自定义解决方案备份的数据库一致性快照和日志，可以构建性能高、经济高效的数据库备份解决方案。 此解决方案使用 Azure VM 备份的优势，并重复使用数据库客户端的功能。