灾难恢复工作流程
企业已经将公共云作为可行的资源和灾难恢复目的地。 SnapCenter使这个过程尽可能无缝。此灾难恢复工作流程与克隆工作流程非常相似,但数据库恢复通过复制到云的最后一个可用日志来恢复所有可能的业务交易。但是,还有针对灾难恢复的额外预配置和后配置步骤。
将本地 Oracle 生产数据库克隆到云以进行灾难恢复
-
为了验证克隆恢复是否通过最后一个可用日志运行,我们创建了一个小测试表并插入了一行。完全恢复到最后可用日志后,测试数据将被恢复。
-
以 Oracle 数据库管理用户 ID 身份登录SnapCenter 。导航到“资源”选项卡,其中显示受SnapCenter保护的 Oracle 数据库。
-
选择 Oracle 日志资源组并单击“立即备份”以手动运行 Oracle 日志备份,将最新事务刷新到云中的目标。在真实的 DR 场景中,最后一个可恢复的事务取决于数据库日志卷复制到云端的频率,而这又取决于公司的 RTO 或 RPO 策略。
在灾难恢复场景中,异步SnapMirror会丢失在数据库日志备份间隔内未到达云目标的数据。为了最大限度地减少数据丢失,可以安排更频繁的日志备份。然而,从技术上来说,日志备份频率是有限制的。 -
选择辅助镜像备份上的最后一个日志备份,并安装该日志备份。
-
选择最后一个完整数据库备份,然后单击“克隆”以启动克隆工作流程。
-
在主机上选择一个唯一的克隆数据库 ID。
-
为 Oracle 闪回恢复区和在线日志配置日志卷并将其挂载到目标 DR 服务器。
Oracle 克隆过程不会创建日志卷,需要在克隆之前在 DR 服务器上进行配置。 -
选择目标克隆主机和放置数据文件、控制文件和重做日志的位置。
-
选择克隆的凭据。填写目标服务器上 Oracle 主目录配置的详细信息。
-
指定克隆之前要运行的脚本。如果需要,可以调整数据库参数。
-
选择“直到取消”作为恢复选项,以便恢复运行所有可用的存档日志来恢复复制到辅助云位置的最后一个事务。
-
如果需要,配置 SMTP 服务器以接收电子邮件通知。
-
DR 克隆摘要。
-
克隆完成后,克隆的数据库会立即在SnapCenter中注册,然后可用于备份保护。
Oracle 的灾难恢复后克隆验证和配置
-
验证已在云中的 DR 位置刷新、复制和恢复的最后一个测试事务。
-
配置闪回恢复区。
-
配置 Oracle 监听器以供用户访问。
-
将克隆卷从复制的源卷中分离出来。
-
从云端反向复制到本地并重建故障的本地数据库服务器。
|
克隆分裂可能会导致临时存储空间利用率远高于正常运行。但重建本地DB服务器后,可以释放额外的空间。 |
将本地 SQL 生产数据库克隆到云端以进行灾难恢复
-
类似地,为了验证 SQL 克隆恢复是否运行了最后一个可用日志,我们创建了一个小型测试表并插入了一行。完全恢复到最后一个可用日志后,测试数据将被恢复。
-
使用 SQL Server 的数据库管理用户 ID 登录SnapCenter 。导航到“资源”选项卡,其中显示 SQL Server 保护资源组。
-
手动运行日志备份以刷新要复制到公共云中的二级存储的最后一个事务。
-
选择最后一个完整的 SQL Server 备份进行克隆。
-
设置克隆设置,例如克隆服务器、克隆实例、克隆名称和挂载选项。执行克隆的辅助存储位置是自动填充的。
-
选择要应用的所有日志备份。
-
指定克隆之前或之后运行的任何可选脚本。
-
如果需要电子邮件通知,请指定 SMTP 服务器。
-
DR 克隆摘要。克隆的数据库会立即在SnapCenter中注册并可用于备份保护。
灾难恢复后克隆 SQL 验证和配置
-
监视克隆作业状态。
-
验证最后一个事务是否已通过所有日志文件克隆和恢复进行复制和恢复。
-
在 DR 服务器上配置新的SnapCenter日志目录以用于 SQL Server 日志备份。
-
将克隆卷从复制的源卷中分离出来。
-
从云端反向复制到本地并重建故障的本地数据库服务器。
去哪里寻求帮助?
如果您需要有关此解决方案和用例的帮助,请加入"NetApp解决方案自动化社区支持 Slack 频道"并寻找解决方案自动化渠道来发布您的问题或询问。