数据库备份注意事项有哪些？

　　我们试着想一想,在生产环境中什么最重要？如果我们服务器的硬件坏了可以维修或者换新,软件问题可以修复或重新安装,但是如果数据没了呢？这可能是最恐怖的事情了吧,我感觉在生产环境中应该没有什么比数据跟更为重要.那么我们该如何保证数据不丢失、或者丢失后可以快速恢复呢？

　　答案当然是进行数据库备份啦！

　　备份，就是把数据库复制到转储设备的过程。备份的本质就是将数据集另存一个副本，但是原数据会不停的发生变化，所以利用备份只能回复到数据变化之前的数据。那变化之后的呢？其中，转储设备是指用于放置数据库拷贝的磁带或磁盘。通常也将存放于转储设备中的数据库的拷贝称为原数据库的备份或转储。小编将在本文介绍在MySQL数据库备份的过程中的注意事项！

　　首先，我们要先了解一些关于数据库备份的基础内容:

　　一、备份的目的

　　1、做灾难恢复：对损坏的数据进行恢复和还原

　   2、需求改变：因需求改变而需要把数据还原到改变以前

　　3、测试：测试新功能是否可用

　　二、备份需要考虑的问题

　　1、可以容忍丢失多长时间的数据；

　   2、恢复数据要在多长时间内完；

　   3、恢复的时候是否需要持续提供服务；

　　4、恢复的对象，是整个库，多个表，还是单个库，单个表。

　　三、备份的类型

　　1、根据是否需要数据库离线

　　冷备（coldbackup）：需要关mysql服务，读写请求均不允许状态下进行；

　　温备（warmbackup）：服务在线，但仅支持读请求，不允许写请求；

　　热备（hotbackup）：备份的同时，业务不受影响。

　　注：

　　1、这种类型的备份，取决于业务的需求，而不是备份工具

　　2、MyISAM不支持热备，InnoDB支持热备，但是需要专门的工具

　　2、根据要备份的数据集合的范围

　　完全备份：fullbackup，备份全部字符集。

　　增量备份:incrementalbackup上次完全备份或增量备份以来改变了的数据，不能单独使用，要借助完全备份，备份的频率取决于数据的更新频率。

　　差异备份：differentialbackup上次完全备份以来改变了的数据。

　　建议的恢复策略：

　　完全+增量+二进制日志

　　完全+差异+二进制日志

　　3、根据备份数据或文件

　　物理备份：直接备份数据文件

　　优点：

　　①备份和恢复操作都比较简单，能够跨mysql的版本，

　　②恢复速度快，属于文件系统级别的

　　建议：

　　①不要假设备份一定可用，要测试

　　②mysql>checktables；检测表是否可用

　　③逻辑备份:备份表中的数据和代码

　　优点：

　　①恢复简单、

　　②备份的结果为ASCII文件，可以编辑

　　③与存储引擎无关

　　④可以通过网络备份和恢复

　　缺点：

　　①备份或恢复都需要mysql服务器进程参与

　　②备份结果占据更多的空间，

　　③浮点数可能会丢失精度

　　④还原之后，缩影需要重建

　　四：备份的对象

　　1、数据；

　　2、配置文件；

　　3、代码：存储过程、存储函数、触发器

　　4、os相关的配置文件

　　5、复制相关的配置

　　6、二进制日志

　　五：设计合适的备份策略

　　针对不同的场景下,我们应该制定不同的备份策略对数据库进行备份,一般情况下,备份策略一般为以下三种

　　1.直接cp,tar复制数据库文件

　　2.mysqldump+复制BINLOGS

　　3.lvm2快照+复制BINLOGS

　　4.xtrabackup

　　以上的几种解决方案分别针对于不同的场景

　　1.如果数据量较小,可以使用第一种方式,直接复制数据库文件

　　2.如果数据量还行,可以使用第二种方式,先使用mysqldump对数据库进行完全备份,然后定期备份BINARYLOG达到增量备份的效果

　　3.如果数据量一般,而又不过分影响业务运行,可以使用第三种方式,使用lvm2的快照对数据文件进行备份,而后定期备份BINARYLOG达到增量备份的效果

　　4.如果数据量很大,而又不过分影响业务运行,可以使用第四种方式,使用xtrabackup进行完全备份后,定期使用xtrabackup进行增量备份或差异备份

　　作为一个数据库管理员，应该选择怎样的备份策略呢？建议您问自己两个问题。

　　1.您管理的数据库最多能够容忍多长时间的数据丢失？

　　2.您准备投入多少人力物力来做数据库备份与恢复策略？

　　问题似乎有点残酷。但是世界上大多数事情，要获得越好的效果，就需要越多的投入。数据库备份策略尤其是这样。本文将介绍数据库备份需要注意的一些基本事项。

　　数据丢失因素:

　　不考虑镜像技术（比如SQLServer自己的数据库镜像和物理磁盘级镜像），数据库不可能时时刻刻地做数据库备份，每次备份之间总要有一定的时间间隔。而这个间隔之间的数据变化在下一次备份之前，是没有保护的。所以讲到底，数据丢失的最大时间段，就是两次备份之间的时间间隔。利用备份恢复机制保护数据，是不可能保证数据一点都不丢失的。如果您的用户提出的要求是不能有任何数据丢失，则必须跟用户沟通，让他们了解这样的要求仅使用数据库备份技术实现是不现实的，需要做更大的投入，引入镜像技术。

　　既然数据丢失的最大时间段，就是两次备份之间的时间间隔，那么备份做得越多，数据丢失量就会越少。可是，做备份越频繁，需要的投入也越多。涉及的因素有：

　　1.备份越多，要管理的备份文件也越多，数据库恢复时要恢复的文件也越多。要建立一个合适的备份管理制度。

　　2.备份虽然不会阻塞数据库的正常操作，但是会产生一系列的硬盘读写。如果服务器本身I/O就比较繁忙，备份动作会进一步影响数据库的性能。须要增强服务器的硬盘读写处理能力，才能避免这种问题发生。

　　3.备份难免会因为种种因素失败。备份越勤，遇到失败的几率越大。管理员要及时处理错误，将备份任务恢复常态。这对管理员的要求也比较高。

　　当您对将要投入的人力物力心中有数以后，就可以来决定采用什么样的备份策略了。使用日志备份，可以将数据库恢复到故障点或特定的时点。所以日志备份在备份策略中扮演着很重要的角色。但是日志备份只能在完整恢复模式和有些大容量日志恢复模式的数据库上进行。制定备份策略，首先要决定是否需要做日志备份。如果需要做日志备份，数据库恢复模式就要选成完整模式。（大容量恢复模式不能总保证日志备份成功，所以一般不推荐在生产环境下使用）如果不做日志备份，数据库模式就要设置简单，否则会遇到日志文件无限增长问题。

　　简单恢复模式下的备份：

　　简单恢复模式下，不能做日志备份。所以它只支持最简单的备份和还原方式，很容易管理。不过如果没有日志备份，就只能将数据库恢复到最后一次备份的结尾。如果发生灾难，数据库最后一次备份之后做的数据修改将全部丢失。在简单恢复模式下，工作损失风险会随时间增长而增加，直到进行下一个完整备份或差异备份为止。因此，建议您排订充足的备份的频率，以避免遗失大量数据。同时，频率也不能太高而让备份变得难以管理。

　　为了降低风险，可以引入差异备份。使用差异数据库备份补充数据库完整备份，是减轻工作损失风险的一种备份策略。在第一次数据库备份之后，连续建立了3次差异备份。第3个差异备份后，进行数据库完整备份，建立新的差异基准。因为差异备份的开销一般都比完整备份低，所以能够比较经常地运行。这样的备份策略可以使用在数据量稍大，能够容忍较长时间数据丢失的数据库上。

　　以上两种备份策略的优势，是不管是备份还是恢复，管理起来都比较简单。但是不管是数据库完整备份，还是差异备份，都不可能以比较频繁的频率进行，一般都只能在晚间进行。如果数据库比较庞大，或者不允许比较长时间的数据丢失，这样的备份策略是不能满足要求的。必须引入日志备份，建立更为复杂，但是也更强大的备份恢复策略。

　　完整恢复模式下的备份：

　　选取完整恢复模式，就可以使用日志备份。由于日志备份只拷贝上次日志备份以来的所有日志记录，所以开销会比数据库备份小很多。可以定义以一种很频繁的频率（5分钟甚至更短）来做备份，以达到在最大限度内，防止出现故障时丢失数据的目的。使用日志备份的优点是允许您将数据库还原到日志备份内包含的任何时点（“时点恢复”）。假定可以在发生严重故障后备份活动日志，则可将数据库一直还原到没有发生数据丢失的故障点处。使用日志备份的缺点是它们的数量很多，而且恢复备份时，需要严格按照备份产生的顺序依次恢复。中间不能有任何备份缺失或跳跃。所以日志备份做得越多，还原时间就越长，管理复杂性也越高。

　　在第一个完整数据库备份完成，并且常规日志备份开始之后，潜在的工作丢失风险存在时间，仅为数据库损坏时点，到上一次常规日志备份的那一段时间。因此，建议经常执行日志备份，以将工作丢失的风险限定在业务要求所允许的范围内。出现故障后，可以尝试备份“日志尾部”（尚未备份的日志）。如果尾日志备份成功，则可以通过将数据库还原到故障点来避免任何工作丢失。所以这种备份计划的优点也是很明显的。

　　但是上述备份计划的一大缺陷，就是灾难发生后需要恢复的日志文件数目太多。假设每个小时做一次日志备份，每周日做一次数据库备份，如果灾难在周五发生，就不得不恢复上百个日志备份。这个工作量和所要花的时间是很大的。为了最大程度地缩短还原时间，可以对数据库进行一系列差异备份做补充。

　　文件或文件组备份：

　　完整文件备份指备份一个或多个文件或文件组中的所有数据。在完整恢复模式下，一整套完整文件备份和跨所有文件备份的日志备份合起来，等同于一个完整数据库备份。使用文件备份能够只还原损坏的文件，而不用还原数据库的其余部分，从而可加快恢复速度。例如，如果数据库由位于不同磁盘上的若干个文件组成，在其中一个磁盘发生故障时，只须还原故障磁盘上的文件。

　　文件备份在默认情况下包含足够的日志记录，可以将文件前滚至备份操作的末尾。（但是在简单恢复模式下，必须一起备份所有读/写文件，而不是逐个指定每个读/写文件或文件组）相对于数据库备份，文件备份具有如下优点：

　　l能够更快地从隔离的媒体故障中恢复。可以迅速还原损坏的文件。

　　l与完整数据库备份（对于超大型数据库而言，变得难以管理）相比，文件备份增加了计划和媒体处理的灵活性。文件或文件组备份的更高灵活性对于包含具有不同更新特征的数据的大型数据库也很有用。

　　与完整数据库备份相比，文件备份的主要缺点是管理较复杂。如果某个损坏的文件未备份，那么媒体故障可能会导致无法恢复整个数据库。因此，必须维护一组完整的文件备份，对于完整/大容量日志恢复模式，还必须维护一个或多个日志备份，这些日志备份至少涵盖第一个完整文件备份和最后一个完整备份之间的时间间隔。维护和跟踪这些完整备份是一种耗时的任务，所需空间可能会超过完整数据库备份的所需空间。所以这种备份策略在实际使用中应用得还是比较少的。它只有在管理超大数据库时，才能发挥出其不可替代的优势。

　　在完整恢复模式下，一整套完整文件备份与涵盖从第一个文件备份开始的所有文件备份的足够日志备份合起来等同于完整数据库备份。仅使用文件备份和日志备份还原数据库的操作可能比较复杂。因此，如果可能，最好执行完整数据库备份并在第一个文件备份开始之前开始日志备份。创建了第一个数据库备份之后，便可开始执行事务日志备份。事务日志备份计划按设置的间隔执行。文件备份以最适合数据库业务要求的间隔执行。

　　在完整恢复模式下，恢复一个文件组备份，不但需要恢复文件组备份本身，还需要依次恢复从上一次完整数据库备份后，到恢复的目标时间点为止的所有日志备份，以确保该文件与数据库的其余部分保持一致。所以要恢复的事务日志备份数量会很多。要避免这种情况，可以考虑使用差异文件备份。可是这样会使整个备份计划更加难于管理。这也是为什么文件备份不常使用的重要原因。但是在管理超大数据库时，这可能是唯一的选择。

　　小编结语：

　　更多内容尽在课课家教育！