数据库备份方案

数据库备份恢复方案2011/1/18目录一、 修改记录 2二、 简介 2三、 生产库备份恢复方案 31. 数据库恢复模式 32. 系统数据库的备份 33. 用户数据库的备份 44. 验证备份内容 55. 备份文件大小和位置 56. 磁盘配置要求 57. 远程备份 58. 备份操作的管理 5四、 生产库复原操作 61. 数据库效劳权限 62. 备份复原顺序 7五、 数据库归档 7六、 其它数据保护方案 91. 数据库镜像 92. 日志传送 10修改记录修改人内容日期付海涛初稿2011-1-18简介本手册旨在提高数据库大容量时备份的速度和数据平安性，并在数据库故障时进行快速复原。数据库备份和恢复技术是数据库系统维护工作中的重要技术，不管是开发测试环境的数据库，还是生产环境的数据库，建议都要进行备份，而且要确保备份文件可用。对于数据库系统来说，当发生故障甚至是灾难性的故障的时候，数据库备份就是最有效的最后一道防线。对于数据库维护人员来说，备份与恢复技术的熟练运用，加之标准性的操作，是企业数据库系统正常运行的重要保障。创立SQLServer备份的目的是为了可以恢复已损坏的数据库。但是，备份和复原数据必须根据特定环境进行自定义，并且必须使用可用资源。因此，可靠使用备份和复原以实现恢复需要有一个备份和复原策略。设计良好的备份和复原策略在考虑到特定业务要求的同时，可以尽量提高数据的可用性并尽量减少数据的丧失。设计有效的备份和复原策略需要仔细方案、实现和测试。测试是必需环节。直到成功复原了复原策略中所有组合内的备份后，才会生成备份策略。必须考虑各种因素。其中包括：您的组织对数据库的生产目标，尤其是对可用性和防止数据丧失的要求。每个数据库的特性，包括：大小、使用模式、内容特性以及数据要求等。对资源的约束，例如：硬件、人员、备份媒体的存储空间以及所存储媒体的物理平安性等。设计备份和复原方案时，应根据您自身的特定环境和业务需求来考虑灾难恢复方案。例如，假设失火了并且烧毁了您的24小时数据中心。您是否有把握恢复数据？恢复系统并保证系统运行需要多长时间？您的用户能够承受丧失多少数据？理想的情况是，灾难恢复方案应规定恢复所需的时间以及用户可以期望的最终数据库状态。例如，可以确定在获取指定的硬件后，在48小时内完成恢复，并且保证最多能恢复到上周末时的数据。灾难恢复方案可以通过多种方式构建，并且可以包含各种类型的信息。灾难恢复方案类型包括：获取硬件方案。通信方案。发生灾难时的联系人名单。与负责处理灾难的人员的联系方式。对方案拥有管理权的人员的信息。每个恢复方案所需执行的任务的清单。为了便于您检查灾难恢复的进度，将初始化已完成的任务，并在清单中指示任务完成时间。生产库备份恢复方案当前数据库数据和索引容量大概20G左右，为了提高在容量继续增大时备份和复原的效率，并保证数据尽量不丧失，建议采用如下备份策略：数据库恢复模式为了提高数据平安性，数据库应处于完整恢复模式下，这时所有的修改记录都会记录在日志文件中。对数据库日志文件定期进行备份，以备份这些修改信息。系统数据库的备份master数据库保存了用户数据库和登录账号等信息，msdb保存了方案任务等信息，model数据库作为创立数据库的模板会保存自定义的一些模板信息。因此，对于这些系统数据库应该在创立用户数据库、修改用户信息、修改作业信息、修改数据库模板等操作后对这些数据库进行备份。因为这些数据库一般比拟小，因此可以直接使用数据库完整备份即可。用户数据库的备份 上图描述了数据丧失的风险。假设现在在t9和t10中间的时刻出现硬件故障。首先尝试备份数据库的尾日志，就是t9时刻后的日志，如果能成功备份那么不会丧失任何数据。如果无法备份尾日志，那么丧失从t9时刻之后的操作。这时可以通过复原t1时刻的完整备份和t7时刻的差异备份，接着复原t8和t9时刻的日志备份，如果有尾日志备份继续复原尾日志。完整备份周期完整备份是指对整个数据库所有内容进行备份，就目前数据库的容量进行一次完整备份大概需要30分钟左右可以完成。因完整备份占用与数据库容量大小差不多的磁盘空间，并且随着容量不断增大，备份时间也会不断增长。建议完整备份可以每月进行一次。过于频繁的完整备份对于保护数据没有多大意义。随着数据库不断增大，备份周期也应相应调整大些，以防止不必要的重复备份没有修改正的内容。差异备份周期差异备份是指自上次完整备份之后所有发生变化的数据块的备份，每执行一次差异备份都会备份下这些数据块。因此在每次执行完数据库完整备份后差异备份的内容就会变小。因为差异备份包含的内容较小，因此备份频率可以高一些。随着数据块内容不断被更新或插入删除新的记录，被修改的数据块会越来越多，当所有数据块都被修改正后，差异备份所包含的内容就与完整备份是一样的。因此，应该定期对数据库进行完整备份，以减小每次差异备份的包含的数据块。建议差异备份可以每天进行一次。每次差异备份都会包含前一次差异备份的内容，因此完成备份之后，之前的差异备份可以删除。日志备份周期日志备份保存了自上次完整或差异备份之后对数据库内容的修改信息。为了尽量防止数据的丧失，建议每15分钟或30分钟进行一次日志备份。过于频繁的日志备份会对数据库性能造成一定影响，因此备份频率不应过高。验证备份内容为了保证备份的有效性，在进行备份时应对数据页面进行校验和验证，以保证当前数据页的有效性。在完成备份时，为了保证写入磁盘的备份内容一致，应对备份文件使用RESTOREVERIFYONLY执行复原操作验证，保证备份文件的有效。备份文件大小和位置为了在数据库损坏时尽快恢复数据库，节省远程拷贝备份文件的时间，应在本机保存至少一次完整备份和它之后所有的差异和日志备份文件用于复原数据库。同时，为了在拷贝文件时占用生产效劳器过多内存，并能保存至磁带设备中，每个备份文件的大小一般控制在2G左右。磁盘配置要求为了防止硬盘故障造成数据库和备份文件同时损坏，应确保本地有两个以上的独立硬盘，分别存放数据库文件和备份文件。如果使用共享存储设备，应确保每个LUN所对应的卷使用不同的独立磁盘设备。远程备份为了防止单点故障，应先在本机完成备份并验证备份有效性后，定期把备份拷贝至远程效劳器。根据业务需要远程备份应至少保存两个备份周期以内的备份文件。备份操作的管理因为数据库的差异备份和日志备份是基于完整备份的，如果完整备份没有或是无效，这些差异和日志备份就变得没有意义。因此应防止除管理员之外的人员对数据库进行的任何备份操作。如果备份是备份到原有完整备份指定的目录位置，应确保保存至下一个有效的完整备份之后才能删除这个完整备份。如果因为需要在不是指定的备份时刻进行完整备份，应使用“仅复制备份”方式对数据库进行备份，以防止破坏当前数据库的备份链。具体语法参见下面例如：BACKUPDATABASEdatabase_nameTO<backup_device>…WITHCOPY_ONLY…生产库复原操作数据库效劳权限为了加快在数据库复原操作时的效率，应为SQL效劳的启动账号分配“执行卷维护任务”的权限。这样，在复原操作期间可绕过为每个文件的bit位进行初始设置为0的操作，可提高复原速度。备份复原顺序以上图为例，假设完整备份的周期为1月，差异备份每天执行一次，日志备份每30分钟执行一次。完整备份包含了数据库中的所有内容，差异是自上次完整备份之后变化的内容，日志备份是自上次完整或差异之后变化的信息。因此如果想要复原到t11这个时刻的数据库状态，应先复原t1的完整备份，再复原t10的差异备份，接着复原t11的日志备份即可使数据库上线使用。如果想复原到t14时刻，那么只需要复原t13的完整备份和t14的日志备份即可使用数据库上线使用。数据库归档根据业务需要，对于不需要使用的历史数据迁移至归档数据库中。对归档的数据库，只在每次归档操作之后做一次备份即可。因为归档库不需要做修改操作，因此恢复模式可以设置为简单恢复模式，这时不需要对日志进行备份。归档数据库保存的历史数据比拟多，在数据库规模超过TG级别时，备份时可以使用文件组或文件的备份方式。在创立归档历史库时，把所有索引独立于它所在的表，存放在单独的文件组，因为索引可以根据表的内容生成，因此不需要备份索引所在的文件组。把不频繁变化的表放在同一个文件组中。把经常变化的表使用分区的方式创立，每次做归档操作时把这些数据保存至不同的分区下，备份时只需要备份这个分区所在的文件组便可完成备份操作。所有文件组备份的集合构成整个数据库的内容。使用文件组备份可以大大减小备份的时间和空间要求，但是会增加复原操作时的时间。因些，只建议在数据库超过TG以上使用这种方式。下面示意图演示了文件组备份的策略：复原数据库时，复原主文件组和其它的备份文件组即可复原整个数据库。如果有日志备份，要把数据库完整备份之后的所有日志备份复原才可使数据库处于在线状态。因为要复原很多文件，因此复原时间会比其它方式要长很多，而且对数据库维护人员也有较高的要求。其它数据保护方案数据库镜像为了防止机器故障时复原操作影响业务使用，可以使用镜像技术在另一台机器创立一个备用的数据库。此数据库的内容可以与生产库的数据适时同步，确保数据不会丧失。同时，如果有一台见证效劳器的话，可以在生产库发生故障时实现自动切换。不影响业务的正常操作。如果没有见