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

SQL Server数据库的灾难恢复

在线QQ客服:1922638

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

高可用性取决于导致故障的事件后恢复生产系统的速度。这需要计划和文档。如果您错误地制定了灾难恢复计划,则可能使事件成为企业的灾难。Hugo Shebbeare讨论了一些要点,描述了一个典型的系统,并提供了示例文档。

在本文中,我将介绍为运行Microsoft SQL Server的生产应用程序实施简单的灾难恢复计划(DRP)的技术细节。我的目标是为您提供通用文档,以用作您自己的生产系统故障转移策略的基础。当然,您将需要使用自己的详细信息对其进行更改,并在对生产系统进行更改时随时对其进行更新,但这将为您提供一个很好的出发点,以供您构建自己的策略。

我将描述在数据库生产系统发生故障时应遵循的步骤,并在进行过程时对过程进行注释。这主要基于我最近设计的灾难恢复计划(最好可以下载和个性化设置),因此,它是故意以业务战略文档的样式编写的。我还将说明从故障转移服务器自动还原压缩备份文件的优点。我也将第一个承认这个话题可能看起来有些枯燥,但是拥有DRS将使其值得一读-我保证。

本文的第1部分将描述设置“热”备用服务器(我在起草此DRP时所使用的恢复方法)所必需的基本步骤,而第2部分是Disaster Recovery文档的带注释的抄本,其中包括将要采用的步骤。灾难事件,以及不幸的DBA负责从灾难中恢复的信息。开始了:


第1部分–将备份文件自动还原到故障转移服务器

SQL Server的norecovery模式可保持数据库稳定并准备好接受您在备份过程中逐渐应用的更改。这意味着只有在用户和应用程序准备好访问数据库之前,才需要应用最新的差异备份或日志备份。

所使用的灾难恢复方法是拥有一个“热”备用服务器(SQL2),该服务器已经安装,稳定并且最重要的是它是生产服务器配置的精确副本。备用服务器应该已经具有在norecovery模式下完全还原的最新操作数据库。

实施热备服务器

在故障转移服务器上安装SQL Server之后,您需要检查Robocopy是否已安装在sysroot \ windows \ system32文件夹中。其次,Red Gate的SQL Backup软件必须连接到服务器,并通过单击左窗格中服务器列表旁边的灰色小方块进行配置-例如,如果尚未完成,则是自动配置。

791-SQB_installingservercomponents.gif

图1 – SQL Backup的自动配置系统。

顺便说一下,Robocopy比(即将停产的)Xcopy好得多。自Windows Server 2003以来,Robocopy已成为推荐的/面向未来的工具。据我所知,Xcopy在Windows Server的未来版本中将不再可用。

接下来,对于执行Robocopy的存储过程(我们将这些过程放置在名为DBA_tools的每台服务器上的本地数据库中),您需要允许xp_cmdshell 运行高级选项:

为了复制备份文件,备用服务器上的每个数据库都需要一个特定于数据库的SQL Server代理作业,该作业以所需的间隔运行Robocopy,以将完整备份和差异备份从生产服务器复制到备用服务器。这些作业可以按需要的频率运行,无论是每天,每小时还是在您的操作需要时更频繁地运行。

Robocopy是所有自动还原作业的第一步,除非您要在备份文件副本之前添加验证步骤。以下示例将所有差异数据库备份从生产服务器复制到DRP服务器:

特定于数据库的SQL Server作业将使用为此设置专门创建的存储过程,每天将这些备份还原到热备用服务器(DRP),例如:

  • usp_DB_Restore_Master or usp_DB_Restore_Master_Multi
  • usp_DB_Restore
  • usp_DB_Restore_NoRecovery
  • usp_DB_Restore_differential
  • usp_DB_Restore_Log

DBA关于数据库恢复级别的注意事项

如果您当前处于简单恢复模式下,并且提供了常规的事务日志和差异备份(如一天几次),则可以将恢复模型切换到批量登录生产中,以还原到特定位置。时间。自然地,这将最大程度地减少任何停机之前从工作会话中丢失的数据量。

对于需要审核合规性的关键数据库,建议使用完全恢复模式。

如果发生故障,可以将最新的日志或差异备份准备好应用到处于无恢复模式的备用数据库,并且您可以在不停机的情况下快速启动和运行。

对于较小的数据库(总还原时间少于5分钟),另一种替代方法是每小时将完整还原应用于故障转移服务器,在这种情况下,您无需担心norecovery模式。

第2部分–在生产系统发生灾难时应遵循的说明

  1. 如果你还没有听到他们已直接,请接触第一线DBA支持在[ INSERT NUMBER ]或二次DBA在[ INSERT NUMBER ]
  2. 生产/原始数据发布服务器失败(SQL1)之后,还原/备份订阅服务器(SQL2)将用作主数据库服务器(又名DRP服务器)。通过电子邮件通知部门中的每个人(也值得考虑由谁来通知内部/外部客户)
  3. 一旦切换到DRP服务器并且实际上发生了SQL1的停机,就需要更改所有应用程序连接字符串以访问SQL2。CGI应该自动处理此步骤。
  4. 在SQL2上禁用自动还原SQL代理。
  5. 如有可能,禁用故障服务器SQL1上的所有SQL Agent作业。
  6. 在新活动的服务器SQL2上启用所有维护和备份作业

请注意,如果生产数据库恢复模型设置为“简单”,则不可能还原日志备份。为了进行细粒度的还原,数据库需要一直使用完整恢复模型-幸运的是,默认设置完全恢复模式。如果管理部门定期要求进行时间点恢复,那么如果空间有限,我们还可以将数据库恢复级别更改为大容量日志记录,否则将数据库恢复级别更改为“满”。也许从数据库管理员的侧当之无愧的犹豫,因为大容量日志恢复是多少空间效率更高。

从压缩备份还原的自动化如何对您的生产环境有利。理想情况下,您应该保留两个完整备份,一个保存在测试服务器上,另一个保存在DRP服务器上。拥有生产数据库的第二个副本,将使您能够执行一些不需要在实时数据库上运行的有用且密集的工作,例如完整的DBCC CheckDB –可以检查确切数据库完整性的控制台命令恢复副本。

已还原内容的日志应放在以下目录中:

\\ DatabaseServerName \ drive $ \ prodBackupDir \ DBlog \

还原完成后,我们应该自动清除旧备份-大概每周执行一次(手动或自动在SQL Server维护计划中最多保留14天),并且可以使用批处理文件或PowerShell脚本将其自动化。

为了确保恢复过程顺利进行,我们应该直接从备份日志系统表中读取恢复参数,例如BackupHistory,BackupSet,BackupFile或

Backuplog –除非在本地数据库中显式创建了backuplog表或msdb中存在该表。这是为了确保基本还原参数(例如备份文件名和位置)立即可用。

正如我经常设置的那样,SQL Agent Restore作业在测试过程中会手动设置它们的参数,并且通常采用这种方式–但是当然,最好是直接从系统中提取元数据,以防您四处移动文件而忘记更新还原脚本。

SQL1和SQL2(产品和DRP)服务器硬件配置

这是本文档最初为之编写的服务器的配置(我不记得该设置的系统模型,但这并不是说您不应该记录您的系统模型)使用您自己的服务器属性更新以下内容。

SQL1(生产实例)

1.1 服务器类型 Windows 2008(标准x64版)
1.2 系统型号 [服务器型号,产品类型]
1.3 RAM内存 8演出
1.4 CPU数量 2
1.5 CPU与速度 AMD(x64)
驱动器 硬盘空间 C(#G); D(#G)

SQL2(存储复制伙伴/热备用还原订户)

1.1 服务器类型 Windows 2008(标准x64版)
1.2 系统型号 [服务器型号,产品类型] –与SQL1相同
1.3 RAM内存 9演出
1.4 CPU数量 2
1.5 CPU与速度 AMD(x64)Opteron处理器280
驱动器 硬盘空间 C(#G); D(#G); F(2TB);G(250GB);H(1.5TB);Z(20GB)

该服务器应具有TB和TB的空间,具体取决于您的归档需求。

SQL Server配置

对于以前的客户,我们的SQL Server生产版本为9.0.3152,因此自然地,DRP服务器必须为完全相同的版本-两个系统必须尽可能相同。

我们的服务器使用64位版本的SQL数据库引擎2005/8,至少安装了Service Pack 2(2005),cu3(2008),并且排序规则类型为Latin1_General_CI_AS(建议使用重音符号)。最好至少具有SQL Server 2005的累积汇总包8或SP3,并且定期对生产版本的SQL进行更新很重要。

服务器和数据库的详细信息包含在服务器SQL1和SQL2上的已编译帮助文件中

D:\ DRP \ ServerName.chm(即,使查找DRP信息非常容易)

关键SQL Server用户数据库详细信息

1.数据库清单

数据库1

数据库2

注意:我们不会做master,msdb,model或temp,它们会定期备份,并且会被Robocopy复制,尽管不会直接还原到数据库中,而是直接复制到复制订户中。

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

通常,我们的数据库还原计划将准确反映备份计划,并通过从生产服务器查询元数据来等待备份完成。还原作业将使用backupset.backup_finish_date列检查天的完整备份是否已完成(或每日差异)。一旦看到完全备份已在生产服务器上完成,就将备份文件复制到热备用服务器上。在工作的第二步中,我们继续从适当的usp_DB_restore中执行代码,并结合从系统表中提取元数据。

3.生产中的数据库备份时间表

维护工作名称 维护工作说明 频率 运行时间
BackupFull_Database1 完整数据库备份Database1 w ^ 星期日6:00
BackupFull_Database2 完整的数据库备份Database2 w ^ 星期日6:30

4.在DRP服务器上还原作业

维护工作名称 维护工作说明 频率 运行时间
BackupFull_Database1 完整数据库备份Database1 w ^ 星期日6:00
BackupFull_Database2 完整的数据库备份Database2 w ^ 星期日6:30

与灾难恢复有关的关键脚本,过程和程序

以下是用于从SQL1到SQL2的DRP流程的所有代码的列表:

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

系统数据库备份

在DRP服务器本身上,对于整个DRP过程至关重要的MSDB,DBA数据库备份位于以下位置:

\\ DRPServerName:\ DRPbackupFolder \ Full 

系统数据库(例如在测试服务器上)应始终有一个备用本地备份位置。

所有DBA和系统数据库均已备份以及备份:

\\ TstServerName:\ TestSrvBackupFolder \ Full

以下示例在主测试服务器上进行了测试,并且在还原服务器上存在。所述usp_DB_restoreX存储过程需要6个输入参数。为了与备份日志元数据匹配,我们将按日期匹配数据库名称,然后将相关的还原文件输入参数拉入适当的usp_DB_restoreX存储过程。主还原过程分为单个文件还原过程和多个文件还原过程,使用所有子过程来执行实际的还原过程。

请注意,usp_DB_RestoreX存储过程取决于usp_KillConnections,这将通过杀死现有数据库用户(也就是说,除非它是系统用户)来帮助恢复过程。

例如

存储过程usp_DB_restore_norecoveryusp_DB_restore相同,仅适用于需要保留在非恢复模式下的数据库(如本文前面所述)

请查看Red Gate SQL备份中的活动历史记录,以报告有关已备份的数据库的信息,因为本文档的范围仅涵盖还原过程。尽管提取了备份信息以准备作业中的自动还原脚本,但我们不会(至少在此阶段)创建自定义的备份报告信息。但是,请不要忘记,由于我们在SQL Server代理作业中使用这些脚本,因此我们将具有每个步骤的历史记录,并将日志文件写入运行这些SQL代理作业的灾难恢复服务器本地的\ DBlog \文件夹中。

791-SQB_activityhistory.gif

图2 – SQL备份活动日志

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

请注意,我们使用usp_restore_db_norecovery从使用Robocopy移动的本地副本加载生产备份。因此,如果在DRP服务器(服务器名称/实例名称)的DBA数据库上执行:

这将是自动作业第二步的核心内容,该步骤将数据库置于NoRecovery模式,因此下一步应调用相应的RestoreDiff_dbx,最后通过RestoreLog_dbx应用日志文件。

还原后,请确保运行多个测试以确保数据的完整性,并且典型的应用程序可以在数据库上运行常规操作。


摘要

这种灾难恢复方法真的能最大程度地减少故障后的手动干预吗?我们可以做得更好吗?是的,是的,但是总有改进的余地。更重要的是,这种方法当然并不适合所有环境。强烈推荐您阅读下面的“高可用性选项”表,以清晰了解哪些方法可能更适合您的个人需求,然后再使用此处的内容进行操作。为了做出有效的选择,您自然需要对每个客户端的还原过程有详细的了解。

高可用性选项

成本 复杂 故障转移 故障回复
硬件集群 快速 快速
软件集群 快速 快速
复写 带有手动
处理的介质
手动
处理慢
连续数据
保护
日志传送
备份与
还原
数据库镜像 快速,但仅在
数据库级别
快速,但仅在
数据库级别

在撰写本文时,我们的备份和还原非常慢-至少要在热备份上运行13个小时之前-但是如果运行优化,则应该在2个小时左右完成。

没有充分的准备,没人愿意经历一场灾难。当我被要求为加拿大最大的机构基金经理准备计划时,我相当认真地对待了这份文件,因此篇幅太长了。我们在周末进行了一次真实的灾难恢复测试,结果一切都很好。我已经尝试与您确切地分享如何制定自己的灾难恢复计划,这样,当时间到了时,至少恢复步骤本身并不是灾难。

相关推荐

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