MySQL之备份与恢复(二)

备份与恢复

定义恢复需求

如果一切正常，那么永远也不需要考虑恢复。但是，一旦需要恢复，只有世界上最好的备份系统是没用的，还需要一个强大的恢复系统。
不幸的是，让备份系统平滑工作比构造良好的恢复过程和工具更容易。原因如下:

• 1.备份在先。只有已经做了备份才可能恢复，因此在构建系统时，注意力自然会集中在备份上
• 2.备份由脚本和任务自动完成。经常不经意地，我们会花些时间调优备份过程。花5分钟来对备份过程做小地调整看起来并不重要，但是你是否天天同样地重视恢复呢？
• 3.备份时日常任务，但恢复常常发生在危急情形下
• 4.因为安全的需要，如果正在做异地备份，可能需要对备份数据进行加密，或采取其他措施来进行保护，安全性往往只关注数据被盗用的后果，但是有没有人想过，如果没有人能对用来恢复数据的加密卷解锁，或需要从一个整块的加密文件中抽取单个文件时，损害又是多大？
• 5.只有一个人来规划、设计和实施备份。当灾难袭来时，那个人可能不在。因此需要培养几个人并有计划地互为备份，这样就不会要求一个不合格的人来恢复数据

这里有一个看到的真实例子:一个客户报告说当mysqldump加上-d选项后，备份变得像闪电一般快，他想知道为什么没有一个人提出该选项可以如此快地加速备份过程。如果这个客户已经尝试还原这些备份，就不难发现其原因:使用-d选项将不会备份数据!这个客户关注备份，却没有关注恢复，因此完全没有意识到这个问题。规划备份和恢复策略时，有两个重要的需求可以帮助思考:恢复点目标(PRO)和恢复时间目标(RTO)。它们定义了可以容忍丢失多少数据，以及需要等待多久将数据恢复。在定义RPO和RTO时，先尝试回答下面几类问题:

• 1.在不导致严重后果的情况下，可以容忍丢失多少数据?需要故障恢复，还是可以接受自上次日常备份后所有的工作全部丢失？是否有法律法规的要求？
• 2.恢复需要在多长时间内完成？哪种类型的宕机是可以接受的？哪种影响(例如，部分服务不可用)是应用和用户可以接受的？当哪些场景发生时，又该如何持续服务?
• 3.需要恢复什么？常见的需求是护肤整个服务器，单个数据库，单个表，或仅仅是特定