数据库备份方案

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

数据库备份恢复方案

Version 1.0

2011/1/18

目录

一、修改记录 (3)

二、简介 (3)

三、生产库备份恢复计划 (4)

1. 数据库恢复模式 (4)

2. 系统数据库的备份 (4)

3. 用户数据库的备份 (5)

4. 验证备份内容 (6)

5. 备份文件大小和位置 (6)

6. 磁盘配置要求 (6)

7. 远程备份 (6)

8. 备份操作的管理 (6)

四、生产库还原操作 (7)

1. 数据库服务权限 (7)

2. 备份还原顺序 (8)

五、数据库归档 (8)

六、其它数据保护方案 (10)

1. 数据库镜像 (10)

2. 日志传送 (11)

一、修改记录

二、简介

本手册旨在提高数据库大容量时备份的速度和数据安全性,并在数据库故障时进行快速还原。

数据库备份和恢复技术是数据库系统维护工作中的重要技术,不论是开发测试环境的数据库,还是生产环境的数据库,建议都要进行备份,而且要确保备份文件可用。对于数据库系统来说,当发生故障甚至是灾难性的故障的时候,数据库备份就是最有效的最后一道防线。对于数据库维护人员来说,备份与恢复技术的熟练运用,加之规范性的操作,是企业数据库系统正常运行的重要保障。

创建SQL Server 备份的目的是为了可以恢复已损坏的数据库。但是,备份和还原数据必须根据特定环境进行自定义,并且必须使用可用资源。因此,可靠使用备份和还原以实现恢复需要有一个备份和还原策略。设计良好的备份和还原策略在考虑到特定业务要求的同时,可以尽量提高数据的可用性并尽量减少数据的丢失。

设计有效的备份和还原策略需要仔细计划、实现和测试。测试是必需环节。直到成功还原了还原策略中所有组合内的备份后,才会生成备份策略。必须考虑各种因素。其中包括:您的组织对数据库的生产目标,尤其是对可用性和防止数据丢失的要求。

每个数据库的特性,包括:大小、使用模式、内容特性以及数据要求等。

对资源的约束,例如:硬件、人员、备份媒体的存储空间以及所存储媒体的物理安全性等。

设计备份和还原计划时,应根据您自身的特定环境和业务需求来考虑灾难恢复计划。例如,假设失火了并且烧毁了您的24 小时数据中心。您是否有把握恢复数据?恢复系统并保证系统运行需要多长时间?您的用户能够承受丢失多少数据?

理想的情况是,灾难恢复计划应规定恢复所需的时间以及用户可以期望的最终数据库状态。例如,可以确定在获取指定的硬件后,在48 小时内完成恢复,并且保证最多能恢复到上周末时的数据。灾难恢复计划可以通过多种方式构建,并且可以包含各种类型的信息。灾难恢复计划类型包括:

●获取硬件计划。

●通信计划。

●发生灾难时的联系人名单。

●与负责处理灾难的人员的联系方式。

●对计划拥有管理权的人员的信息。

●每个恢复方案所需执行的任务的清单。为了便于您检查灾难恢复的进度,将初始化

已完成的任务,并在清单中指示任务完成时间。

三、生产库备份恢复计划

当前数据库数据和索引容量大概20G左右,为了提高在容量继续增大时备份和还原的效率,并保证数据尽量不丢失,建议采用如下备份策略:

1.数据库恢复模式

为了提高数据安全性,数据库应处于完整恢复模式下,这时所有的修改记录都会记录在日志文件中。对数据库日志文件定期进行备份,以备份这些修改信息。

2.系统数据库的备份

master数据库保存了用户数据库和登录账号等信息,msdb保存了计划任务等信息,model数据库作为创建数据库的模板会保存自定义的一些模板信息。因此,对于这些系统数据库应该在创建用户数据库、修改用户信息、修改作业信息、修改数据库模板等操作后对这些数据库进行备份。因为这些数据库一般比较小,因此可以直接使用数据库完整备份即可。

3.用户数据库的备份

上图描述了数据丢失的风险。假设现在在t9和t10中间的时刻出现硬件故障。首先尝试备份数据库的尾日志,就是t9时刻后的日志,如果能成功备份则不会丢失任何数据。如果无法备份尾日志,则丢失从t9时刻之后的操作。这时可以通过还原t1时刻的完整备份和t7时刻的差异备份,接着还原t8和t9时刻的日志备份,如果有尾日志备份继续还原尾日志。

a)完整备份周期

完整备份是指对整个数据库所有内容进行备份,就目前数据库的容量进行一次完整备份大概需要30分钟左右可以完成。因完整备份占用与数据库容量大小差不

多的磁盘空间,并且随着容量不断增大,备份时间也会不断增长。

建议完整备份可以每月进行一次。过于频繁的完整备份对于保护数据没有多大意义。随着数据库不断增大,备份周期也应相应调整大些,以避免不必要的重复备

份没有修改过的内容。

b)差异备份周期

差异备份是指自上次完整备份之后所有发生变化的数据块的备份,每执行一次差异备份都会备份下这些数据块。因此在每次执行完数据库完整备份后差异备份的

内容就会变小。因为差异备份包含的内容较小,因此备份频率可以高一些。随着数

据块内容不断被更新或插入删除新的记录,被修改的数据块会越来越多,当所有数

据块都被修改过后,差异备份所包含的内容就与完整备份是一样的。因此,应该定

期对数据库进行完整备份,以减小每次差异备份的包含的数据块。

建议差异备份可以每天进行一次。每次差异备份都会包含前一次差异备份的内

容,因此完成备份之后,之前的差异备份可以删除。

c)日志备份周期

日志备份保存了自上次完整或差异备份之后对数据库内容的修改信息。为了尽量避

免数据的丢失,建议每15分钟或30分钟进行一次日志备份。过于频繁的日志备份

会对数据库性能造成一定影响,因此备份频率不应过高。

4.验证备份内容

为了保证备份的有效性,在进行备份时应对数据页面进行校验和验证,以保证当前数据页的有效性。在完成备份时,为了保证写入磁盘的备份内容一致,应对备份文件使用RESTORE VERIFYONLY执行还原操作验证,保证备份文件的有效。

5.备份文件大小和位置

为了在数据库损坏时尽快恢复数据库,节省远程拷贝备份文件的时间,应在本机保留至少一次完整备份和它之后所有的差异和日志备份文件用于还原数据库。同时,为了在拷贝文件时占用生产服务器过多内存,并能保存至磁带设备中,每个备份文件的大小一般控制在2G左右。

6.磁盘配置要求

为了避免硬盘故障造成数据库和备份文件同时损坏,应确保本地有两个以上的独立硬盘,分别存放数据库文件和备份文件。如果使用共享存储设备,应确保每个LUN所对应的卷使用不同的独立磁盘设备。

7.远程备份

为了防止单点故障,应先在本机完成备份并验证备份有效性后,定期把备份拷贝至远程服务器。根据业务需要远程备份应至少保留两个备份周期以内的备份文件。

8.备份操作的管理

因为数据库的差异备份和日志备份是基于完整备份的,如果完整备份没有或是无效,这些差异和日志备份就变得没有意义。因此应防止除管理员之外的人员对数据库进行的任何备份操作。如果备份是备份到原有完整备份指定的目录位置,应确保保留至下一个有效的完整备份之后才能删除这个完整备份。

如果因为需要在不是指定的备份时刻进行完整备份,应使用“仅复制备份”方式对数据库进行备份,以防止破坏当前数据库的备份链。具体语法参见下面示例:

相关文档
最新文档