快速,持续,稳定,傻瓜式
支持Mysql,Sqlserver数据同步

SQL Server上数据库的灾难恢复计划

在线QQ客服:1922638

专业的SQL Server、MySQL数据库同步软件

高可用性是在发生不可预见的灾难事件后恢复正常运行所花费的时间的度量。需要战略规划和全面的文档来克服这一挑战。如果您的继任计划失败,则此事件可能对您的企业造成灾难。Hugo Shebbeare用一个典型的示例讨论了所有这些细节,还提供了所有必要的代码和文档来防止这种情况在您各自的操作中发生。

在本文中,我将解释为生产系统实施灾难恢复计划(DRP)的技术问题。该计划的目的是为您提供通用代码以及文档模板,以便您可以创建自己的继任计划策略。

我列出了在生产环境中发生灾难之后要遵循的步骤,并记录了整个过程中的步骤。这些步骤基于我最近必须创建的继任计划(可下载,因此可以为您的系统自定义)。此外,这些步骤以战术业务文档的样式概述。我同意您,这个话题可能会让人觉得有点压倒性和/或无趣,但我保证您值得一读。

第一部分描述准备备份服务器所需的基本步骤(热备用或“热备用”实例)。第二部分将提供带注释的继任计划,包括发生灾难时应采取的步骤,以及为负责执行继任计划以摆脱上述灾难的幸运管理员提供的信息:

第1部分-将备份文件自动还原到备份服务器

SQL Server norecovery恢复模式可保持数据库稳定,并可以随时应用自动备份过程中的最新更改。这意味着需要应用 最新的差异备份副本或事务日志日志文件),以使数据库可用于您的用户和应用程序。

所使用的恢复方法是在备用模式下使用实例,此后称为SQL2,该实例已安装,稳定且在生产中具有配置的精确副本。恢复服务器SQL2应该已经具有在norecovery恢复模式下完全恢复的关键操作数据库。

实施备份服务器

恢复实例上安装SQL Server之后,必须首先确保Robocopysysroot \ Windows \ system32文件夹中。其次,通过在软件窗口左侧的服务器列表中单击服务器旁边的灰色小按钮,确保正确安装了Red Gate SQL Backup软件并将其连接到恢复服务器。单击此小按钮将自动安装和配置SQL Backup(如果尚未安装)。

791-SQB_installingservercomponents.gif

图像1-SQL Backup自动配置系统。

Robocopy是Windows使用的最好的内置工具,因为Xcopy将在不久的将来被淘汰,这一事实已经证实,自Windows Server 2003以来,Robocopy是推荐的复制工具。从这些手势可以理解,Xcopy在Windows操作系统的未来版本中将不再可用。

接下来,关于利用Robocopy的存储过程(我们将这些过程放置在名为DBA_outils的数据库中),我们需要允许执行高级配置xp_cmdshell:

为了制作备份文件的副本,恢复服务器(SQL2)上的每个数据库都应具有其自己的自动化过程(本地SQL Server代理作业),该过程在约定的时间运行Robocopy,并将备份复制到数据库中。从生产服务器(SQL1)到SQL2的完整或差异。这些自动化过程的时间表可以以所需的频率执行和/或根据您的需要交错排列。

运行Robocopy是SQL Agent自动化过程的第一步,除非您想在Robocopy执行其复制之前添加一个步骤来验证当前备份文件的存在。这是一个示例,演示如何将备份从SQL1复制到SQL2。

SQL Server代理通过为每个数据库设置的过程来完成恢复服务器上备份文件的恢复,该过程将调用以下专门为此恢复计划创建的存储过程,例如:

  • usp_DB_Restore_Master或usp_DB_Restore_Master_Multi
  • usp_DB_Restore
  • usp_DB_Restore_NoRecovery
  • usp_DB_Restore_differential
  • usp_DB_Restore_Log

有关恢复级别的数据库分析师(DBA)的注意事项
如果您当前正在使用简单恢复模式,并且您定期对事务和差异日志文件进行备份(例如多次)每天),您可以将收集模式更改为批量登录生产,以允许渲染到过去的特定时间。此更改将最大程度地减少灾难中的数据丢失。真正的DBA会告诉您,您必须喜欢事务日志文件才能执行像我这样的继任计划。

对于您最关键的数据库,建议使用FULL 恢复模型,模型需要审计证明。

如果发生灾难,可以将最新的事务日志文件或差异备份准备好应用到备份数据库,并保留在NORECOVERY恢复模式下,您就可以开始使用。以最少的停机时间恢复正常运行。

对于小型数据库,另一种恢复时间少于五分钟的方法是每小时对恢复服务器应用完全还原。在此示例中,保持无恢复模式的需求是无益的。

第2部分-生产灾难期间应遵循的步骤

  1. 请与第一线支持DBA(插入电话/寻呼机/手机号码)联系,或通过(插入号码)与辅助DBA联系
  2. 在主生产服务器(SQL1)发生故障之后,备份服务器(SQL2)成为主数据库服务器。通过电子邮件通知涉及此更改的所有人(内部部门以及外部客户(如有必要))。这些人应该已经准备好了
  3. 一旦备用服务器(SQL2)准备好接受连接,并且SQL1(旧的主服务器)确实死了,则将所有应用程序链接更改为SQL2。如果您的应用程序具有配置文件以对SQL2服务器进行此类更改,则建议在完成该计划的实施之前(例如,在周末)测试此配置。
  4. 禁用自动SQL2备份还原过程。
  5. 禁用自动SQL1备份过程(如果可能)。
  6. 在托管主数据库的恢复服务器上激活所有自动化维护和备份过程(必不可少的Jobs)。

请注意,如果生产数据库恢复模型设置为“简单”,则不可能还原日志备份。为了进行细粒度的还原,数据库需要一直使用完整恢复模型-幸运的是,默认模式是完全恢复。当硬盘驱动器空间变紧并且需要减少日志文件使用量时,还原为特定时间的最小模式为大容量日志记录模式。

自动还原压缩备份如何使您的生产环境受益。理想情况下,应保留两个完整备份,第一个完整备份在“入侵/测试”服务器上,第二个完整备份在备份服务器上。此备份生产副本的存在使执行生产中应避免的有用检查和/或繁重的任务成为可能,例如,DBCC CheckDB控制台命令可验证所讨论数据库的完整性。

恢复的文件列表应位于以下目录中:

\\ DatabaseServer \磁盘$ \ ProductBackup Dir \ DBlog \

还原完成后,我们应该通过PowerShell 脚本或批处理命令文件自动清理旧的备份文件(使用SQL Server维护计划每周至少应执行一次清理)。

为了确保顺利进行还原,我们应该直接从MSDB数据库中的元数据表(例如BackupHistory,BackupSet,BackupFile或BackupLog)读取还原设置-除非使用BackupLog表已在DBA_Tools数据库(下面的其他对象所在的位置)中定期显式创建。由于始终需要可用的基本参数(备份名称和硬盘上的位置)来成功运行这些存储过程,因此这始终是必需的。

在自动化流程中创建步骤时,我经常会在插入过程中手动编写参数,并保持原样-但是,最好的方法当然是直接从参数的元数据表中删除参数上面描述的系统,因为如果我们移动MDF,NDF或LDF文件,则很可能是我们忘记了更新步骤(英语中称为脚本的将来证明)。

配置设备以及生产和备份服务器(SQL1和SQL2)

这是救济项目服务器的典型配置。在这种情况下,我记不清所有系统规范,但这并不意味着不应该记录它们。请根据您使用的设备更新这些规格表。

SQL1(生产实例)

1.1 操作系统 Windows 2008(标准版或x64版)
1.2 系统型号 [系统编号,产品类型]
1.3 物理内存 8 GB
1.4 物理CPU数量 2
1.5 CPU与速度 AMD(x64)
硬盘 磁盘空间 C(#Go); D(#转)

SQL2(备份服务器)

1.1 操作系统 Windows 2008(标准版或x64版)-必须与SQL1相同
1.2 系统型号 [系统编号,产品类型]
1.3 物理内存 8 GB
1.4 物理CPU数量 2
1.5 CPU与速度 AMD(x64)Opteron处理器280
硬盘 磁盘空间 C(#Go); D(#Go); F(2To); G(250GB);H(1.5To); Z(20GB)

除非您的数据库不是很大,否则此服务器必须在磁盘空间方面做好充分的准备。

配置SQL Server实例

我们的服务器运行64位版本的SQL Server 2005数据库引擎,尽管当前使用的是SP3和CU5,但已应用第二个主要应用程序更新(Service Pack 2)和第三次累积更新。可用,我们成功地将其早期版本投入生产。排序规则类型设置为Latin1_General_CI_AS或SQL_Latin1_General_CP1_CI_AS-在两种情况下,我们建议注意重音符号(AS = 重音敏感)。当然,如果我们现在重做该缓解环境,我们将受益于Service Pack 3,该Service Pack 3已在生产环境中的实例上安装了累积的第五个更新-当然,强烈建议在更新后将最新的补丁程序投入生产。成功地进行了开发和测试/预生产的轴承。

有关此继承计划中包含的每个数据库服务器(SQL1和SQL2)的详细信息,可在本地硬盘上编译的帮助文件中找到。例如:

D:\ DRP \ ServerName.chm(很容易找到)

有关用户数据库的关键详细信息

1. 数据库清单

BD1

BD2

请注意:我们不会接触定期备份的系统数据库(主数据库,msdb,模型或临时数据库),这些数据库将由Robocopy复制,但不会直接还原到恢复服务器。

2.数据库维护计划和自动归还

通常,我们的计划将准确反映备份计划。

3.计划在生产中维护数据库

自动化过程名称 进度解析 频率 计划的时间
SauvgardeComplet_BD1 完整的BD备份1 每周 星期日上午6点
SauvgardeComplet_BD2 完整的BD备份2 每周 星期日6.30am

4.恢复服务器上的自动过程

自动化过程名称 进度解析 频率 计划的时间
SauvgardeComplet_BD1 完整的BD备份1 w ^ 星期日上午6点
SauvgardeComplet_BD1 完整的BD备份2 w ^ 星期日6.30am

该继任计划正常运行的关键程序和代码

以下是利用此SQL1到SQL2继承计划所需的所有代码。

usp_DB_Restore_Master

usp_DB_Backup和usp_DB_Restore

usp_DB_Restore_NoRecovery

usp_DB_Restore_Differential

usp_DB_Restore_Log

usp_RoboCopy

usp_KillConnections

系统数据库备份

在恢复服务器本身上,对于此计划至关重要的MSDB备份DBA_tools(此恢复代码所在的位置)可以在以下位置找到:

\ PollServer:\ BackupFolder \ Full

系统数据库始终应该有一个可选的本地备份文件夹,例如在生产前/最终入侵服务器上。但是,强烈建议您在入侵服务器上放置以下系统数据库:

\ EncodingServer:\ BackupFolder \ Full

以下示例在测试服务器上运行,并且在恢复服务器上。usp_DB_restoreX存储过程接收6个参数。为了与备份日志元数据保持一致,我们将按日期和适当的参数匹配数据库名称,然后将这些参数推入适当的usp_DB_restoreX存储过程。这些集中化的过程分为两种:一种接收与简单元数据有关的参数,另一种适合使用多个数据文件或事务日志的DB。使用所有相关过程进行真实渲染。

应该理解,usp_DB_RestoreX依赖于usp_KillConnections,它通过强制关闭数据库连接来帮助恢复过程(但要注意系统用户SPID <50)

例如

有问题的存储过程usp_DB_restore_norecovery与usp_DB_restore相同,适用于将保持在无恢复模式的数据库(上面已经说明)

请阅读有关备份报告的Red Gate SQL备份的活动历史记录,因为本文档的范围仅在还原过程级别。尽管与备份相关的信息已从元数据中删除,以便放入流程(SQL Agent Jobs)中的自动化脚本中,但我们不会(至少在此阶段)不会创建任何报告。自动化。

791-SQB_activityhistory.gif

图2-SQL备份活动日志

应用差异备份时还原数据库的方法

请注意,我们将使用usp_restore_db_norecovery加载Robocopy在本地复制的生产存储集。因此,如果由DBA在DBA_Tools中的救济服务器上滚动:

这是自动化过程(作业)第二步过程的本质,此过程使数据库处于无恢复模式,此后,我们将调用过程ups_ RestoreDiff_dbx,最后由usp应用事务文件。   RestoreLog_dbx

还原之后,有必要确保进行检查(DBCC CHECKDB)且没有错误,以准备对数据库的正常操作。


继任计划摘要

这种灾难计划,这种方法会真正减少灾难中的人工干预吗?我们可以改善吗?是的,可以肯定,总是有可能完善和修订计划以使其更加有效。不要犹豫,让我留下您的评论和贡献。重要的是要了解这种方法并非适用于所有环境。闭着眼睛复制/粘贴上面的代码进行操作之前,强烈建议您阅读下面的“高可用性选择”网格,以充分了解您的个人需求。当然,选择正确的道路还需要对客户的期望进行深入分析。

高可用性方面的选择

成本 复杂 演替 返回 
硬件集群 学生 学生
软件集群 学生 学生
复写 方式 方式 中-手动操作 慢-手动操作
连续数据
保护
方式 方式 方式
日志传送 方式
备份与
还原
数据库镜像 快速,受个别漫画限制 快速,受个别漫画限制

没有必要的准备,没有人愿意面对灾难。

当加拿大最大的机构基金经理要求我制定继任计划时,我认真地对待了这一任务,这份文件中的大量细节便证明了这一点。

我们在一个周末进行了自己的测试以模拟灾难,一切都进行得很顺利(感谢!)。

相关推荐

咨询软件
 
QQ在线咨询
售前咨询热线
QQ1922638