用于创建数据库一致性快照的增强的前后脚本

2025-09-15

Azure 备份提供内置的 预发布 脚本框架，以确保备份期间 Linux VM 的应用程序一致性。此框架自动运行一个前置脚本以在磁盘快照之前静止应用程序，和一个后置脚本用于在快照后将应用程序恢复到正常运行。

管理自定义前/后脚本可能很复杂且耗时。为了简化此过程，Azure 备份为流行的数据库提供随时可用的预处理/后处理脚本，实现应用程序一致性快照，所需的努力和维护最少。

下图说明了 Azure 备份如何使用增强的预发布脚本来实现 Linux 数据库的应用程序一致性快照，确保可靠的备份和恢复。

图表显示了 Azure 备份提供的 Linux 应用程序一致性快照。

增强的预发布脚本框架的主要优势

新的 增强的 预发布脚本框架具有以下主要优势：

这些预定义脚本与备份扩展一起直接安装在 Azure VM 中，帮助消除编写和从外部位置下载的需求。
可以在 GitHub 中查看预发布脚本的定义和内容，甚至可以提交建议和更改。你甚至可以通过 GitHub 提交建议和更改，这些建议和更改在经过会审后会添加到库中，从而使更广泛的社区受益。
甚至可以通过 GitHub 为其他数据库添加新的预发布脚本， 这将进行会审和解决，以造福更广泛的社区。
健壮的框架能够有效应对各种情境，例如脚本执行失败或系统崩溃。在任何情况下，后脚本都会自动运行，以回滚在前脚本中完成的所有更改。
该框架还为外部工具提供了一个消息传送通道，用于获取更新和准备它们自己针对任何消息/事件的操作计划。

增强的预发布脚本框架的解决方案流

下图演示了针对数据库一致性快照的增强预发布脚本框架的解决方案流。

显示解决方案流的示意图。

支持矩阵

增强的框架下涵盖了以下数据库列表：

Oracle（普遍可用）
MySQL（预览版）

必备条件

只需在中修改配置文件 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 小时的数据丢失时间段不适用于生产数据库。此解决方案由日志备份策略进行补充，在该策略中，日志备份是显式流式传输出来的。

blob 上的 NFS 和 AFS 上的 NFS（预览版）使直接在数据库 VM 上装载卷并使用数据库客户端传输日志备份变得更加容易。数据丢失时间段（即 RPO）会降到日志备份的频率。此外，NFS 目标也不需要具有很高的性能，因为在获取数据库一致性快照后，您可能不需要为操作备份触发常规数据流传输（包括完整和增量备份）。

注意

增强的前脚本通常会注意在将数据库静止以创建快照之前，将传输中的所有日志事务刷新到日志备份目标。因此，快照在恢复期间具备数据库一致性和可靠性。

恢复策略

创建数据库一致性快照并将日志备份流式传输至 NFS 卷后，数据库的恢复策略可以使用 Azure VM 备份的恢复功能。另外，还可以使用数据库客户端向其应用日志备份的功能。下面是恢复策略的一些选项：

从数据库一致性恢复点创建新的 VM。 VM 应已连接日志装入点。使用数据库客户端运行恢复命令，以实现时点还原。
从数据库一致性恢复点创建磁盘，并将其附加到另一个目标 VM。然后，装载日志目标并使用数据库客户端运行恢复命令以进行时点恢复
使用文件恢复选项并生成脚本。在目标 VM 上运行脚本，并将恢复点附加为 iSCSI 磁盘。然后，使用数据库客户端在附加磁盘上运行特定于数据库的验证函数，并验证备份数据。此外，使用数据库客户端导出/恢复几个表/文件，而不是恢复整个数据库。
使用跨区域还原功能，在区域性灾难期间从次要配对区域执行上述操作。

摘要

使用使用自定义解决方案备份的数据库一致性快照 + 日志，可以利用 Azure VM 备份的优势构建高性能且经济高效的数据库备份解决方案，并重用数据库客户端的功能。

通过