未解决
此帖子已超过 5 年
2 Intern
•
4K 消息
0
3840
数据库备份注意事项
数据库备份注意事项
转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese
介绍
作为一个数据库管理员,应该选择怎样的备份策略呢?建议您问自己两个问题。
1. 您管理的数据库最多能够容忍多长时间的数据丢失?
2. 您准备投入多少人力物力来做数据库备份与恢复策略?
问题似乎有点残酷。但是世界上大多数事情,要获得越好的效果,就需要越多的投入。数据库备份策略尤其是这样。本文将介绍数据库备份需要注意的一些基本事项。
更多信息
数据丢失因素:
不考虑镜像技术(比如SQL Server自己的数据库镜像和物理磁盘级镜像),数据库不可能时时刻刻地做数据库备份,每次备份之间总要有一定的时间间隔。而这个间隔之间的数据变化在下一次备份之前,是没有保护的。所以讲到底,数据丢失的最大时间段,就是两次备份之间的时间间隔。利用备份恢复机制保护数据,是不可能保证数据一点都不丢失的。如果您的用户提出的要求是不能有任何数据丢失,则必须跟用户沟通,让他们了解这样的要求仅使用数据库备份技术实现是不现实的,需要做更大的投入,引入镜像技术。
既然数据丢失的最大时间段,就是两次备份之间的时间间隔,那么备份做得越多,数据丢失量就会越少。可是,做备份越频繁,需要的投入也越多。涉及的因素有:
1. 备份越多,要管理的备份文件也越多,数据库恢复时要恢复的文件也越多。要建立一个合适的备份管理制度。
2. 备份虽然不会阻塞数据库的正常操作,但是会产生一系列的硬盘读写。如果服务器本身I/O就比较繁忙,备份动作会进一步影响数据库的性能。须要增强服务器的硬盘读写处理能力,才能避免这种问题发生。
3. 备份难免会因为种种因素失败。备份越勤,遇到失败的几率越大。管理员要及时处理错误,将备份任务恢复常态。这对管理员的要求也比较高。
当您对将要投入的人力物力心中有数以后,就可以来决定采用什么样的备份策略了。使用日志备份,可以将数据库恢复到故障点或特定的时点。所以日志备份在备份策略中扮演着很重要的角色。但是日志备份只能在完整恢复模式和有些大容量日志恢复模式的数据库上进行。制定备份策略,首先要决定是否需要做日志备份。如果需要做日志备份,数据库恢复模式就要选成完整模式。(大容量恢复模式不能总保证日志备份成功,所以一般不推荐在生产环境下使用)如果不做日志备份,数据库模式就要设置简单,否则会遇到日志文件无限增长问题。
简单恢复模式下的备份:
简单恢复模式下,不能做日志备份。所以它只支持最简单的备份和还原方式,很容易管理。不过如果没有日志备份,就只能将数据库恢复到最后一次备份的结尾。如果发生灾难,数据库最后一次备份之后做的数据修改将全部丢失。在简单恢复模式下,工作损失风险会随时间增长而增加,直到进行下一个完整备份或差异备份为止。因此,建议您排订充足的备份的频率,以避免遗失大量数据。同时,频率也不能太高而让备份变得难以管理。
为了降低风险,可以引入差异备份。使用差异数据库备份补充数据库完整备份,是减轻工作损失风险的一种备份策略。在第一次数据库备份之后,连续建立了3次差异备份。第3个差异备份后,进行数据库完整备份,建立新的差异基准。因为差异备份的开销一般都比完整备份低,所以能够比较经常地运行。这样的备份策略可以使用在数据量稍大,能够容忍较长时间数据丢失的数据库上。
以上两种备份策略的优势,是不管是备份还是恢复,管理起来都比较简单。但是不管是数据库完整备份,还是差异备份,都不可能以比较频繁的频率进行,一般都只能在晚间进行。如果数据库比较庞大,或者不允许比较长时间的数据丢失,这样的备份策略是不能满足要求的。必须引入日志备份,建立更为复杂,但是也更强大的备份恢复策略。
完整恢复模式下的备份:
选取完整恢复模式,就可以使用日志备份。由于日志备份只拷贝上次日志备份以来的所有日志记录,所以开销会比数据库备份小很多。可以定义以一种很频繁的频率(5分钟甚至更短)来做备份,以达到在最大限度内,防止出现故障时丢失数据的目的。使用日志备份的优点是允许您将数据库还原到日志备份内包含的任何时点(“时点恢复”)。假定可以在发生严重故障后备份活动日志,则可将数据库一直还原到没有发生数据丢失的故障点处。使用日志备份的缺点是它们的数量很多,而且恢复备份时,需要严格按照备份产生的顺序依次恢复。中间不能有任何备份缺失或跳跃。所以日志备份做得越多,还原时间就越长,管理复杂性也越高。
在第一个完整数据库备份完成,并且常规日志备份开始之后,潜在的工作丢失风险存在时间,仅为数据库损坏时点,到上一次常规日志备份的那一段时间。因此,建议经常执行日志备份,以将工作丢失的风险限定在业务要求所允许的范围内。出现故障后,可以尝试备份“日志尾部”(尚未备份的日志)。如果尾日志备份成功,则可以通过将数据库还原到故障点来避免任何工作丢失。所以这种备份计划的优点也是很明显的。
但是上述备份计划的一大缺陷,就是灾难发生后需要恢复的日志文件数目太多。假设每个小时做一次日志备份,每周日做一次数据库备份,如果灾难在周五发生,就不得不恢复上百个日志备份。这个工作量和所要花的时间是很大的。为了最大程度地缩短还原时间,可以对数据库进行一系列差异备份做补充。
文件或文件组备份:
完整文件备份指备份一个或多个文件或文件组中的所有数据。在完整恢复模式下,一整套完整文件备份和跨所有文件备份的日志备份合起来,等同于一个完整数据库备份。使用文件备份能够只还原损坏的文件,而不用还原数据库的其余部分,从而可加快恢复速度。例如,如果数据库由位于不同磁盘上的若干个文件组成,在其中一个磁盘发生故障时,只须还原故障磁盘上的文件。
文件备份在默认情况下包含足够的日志记录,可以将文件前滚至备份操作的末尾。(但是在简单恢复模式下,必须一起备份所有读/写文件,而不是逐个指定每个读/写文件或文件组)相对于数据库备份,文件备份具有如下优点:
l 能够更快地从隔离的媒体故障中恢复。可以迅速还原损坏的文件。
l 与完整数据库备份(对于超大型数据库而言,变得难以管理)相比,文件备份增加了计划和媒体处理的灵活性。文件或文件组备份的更高灵活性对于包含具有不同更新特征的数据的大型数据库也很有用。
与完整数据库备份相比,文件备份的主要缺点是管理较复杂。如果某个损坏的文件未备份,那么媒体故障可能会导致无法恢复整个数据库。因此,必须维护一组完整的文件备份,对于完整/大容量日志恢复模式,还必须维护一个或多个日志备份,这些日志备份至少涵盖第一个完整文件备份和最后一个完整备份之间的时间间隔。维护和跟踪这些完整备份是一种耗时的任务,所需空间可能会超过完整数据库备份的所需空间。所以这种备份策略在实际使用中应用得还是比较少的。它只有在管理超大数据库时,才能发挥出其不可替代的优势。
在完整恢复模式下,一整套完整文件备份与涵盖从第一个文件备份开始的所有文件备份的足够日志备份合起来等同于完整数据库备份。仅使用文件备份和日志备份还原数据库的操作可能比较复杂。因此,如果可能,最好执行完整数据库备份并在第一个文件备份开始之前开始日志备份。创建了第一个数据库备份之后,便可开始执行事务日志备份。事务日志备份计划按设置的间隔执行。文件备份以最适合数据库业务要求的间隔执行。
在完整恢复模式下,恢复一个文件组备份,不但需要恢复文件组备份本身,还需要依次恢复从上一次完整数据库备份后,到恢复的目标时间点为止的所有日志备份,以确保该文件与数据库的其余部分保持一致。所以要恢复的事务日志备份数量会很多。要避免这种情况,可以考虑使用差异文件备份。可是这样会使整个备份计划更加难于管理。这也是为什么文件备份不常使用的重要原因。但是在管理超大数据库时,这可能是唯一的选择。
参考
Introduction to Backup and Restore Strategies in SQL Server
Backup Overview (SQL Server) - MSDN
应用于
数据库备份
liulei_it
2 Intern
2 Intern
•
3.2K 消息
0
2014年10月26日 20:00
不看标题感觉这个是依据SQL server写的,咋一看果然不错。
除了备份对生产数据库的影响和备份需要花费多少时间之外,估计一般责任心的DBA是不会考虑备份是否有效这个问题的。
如果想先进又囊中羞涩,可以考虑数据库本身的镜像。如Oracle的Data Guard 和 Golden Gate,Ms sql server的always 或者 replication 这类。这样不仅数据库多了一份保障且可以直接把数据库备份设置在这些secondary的数据库进行。
为啥呢?一般做成这种“软”镜像的架构本身就要求数据库数据无差错或者无逻辑差错。您直接备份这些secondary的数据库就等于备份处于生产系统的数据库本身,同时又对STD数据库无任何实际的I/O影响做到了真正的应用备份分离。
拿Oracle来说,由于data guard几乎是免费的。那么您可以在STD数据库采用RAID 10那么data guard采用RAID 5啦。
这样话很少的钱也能使得自己的系统看起来高档些。
如果不差钱或者涉不在乎钱就〉。。 这样就直接上硬件或者存储基本的镜像,一个字爽出问题还可以推给厂家。