技术：大数据时代的数据库备份与恢复

迷途

　大数据已经席卷了企业IT部门。一些软硬件厂商的IT部门都有高速的分析软件，高性能的硬件和基于列式的数据存储，保证了对随机分析查询的快速访问和应答。
　　而在大数据爆炸式发展中，有一件最根本的任务被遗忘了，这也是对于DBA来说最为重要的任务：备份和恢复。
　　备份到底有多重要？
　　无论是厂商还是用户，他们认为大数据的备份和恢复并不是一个重要的问题。其中包括以下原因：
　　故障发生后对可选数据（账户，订单，客户等）的恢复有着更高的优先级
　　大数据解决方案并不运行关键业务；此外，由于分析是在一个大范围的时间序列上进行的，所以大数据恢复并不需要做到完全最新；
　　大数据真的很大，因此备份大量数据所需要的存储介质成本是难以承受的；
　　对于处理数据和必要的数据通道容量来说，存储和加载到大数据表是非常昂贵而又耗时的；事实上，它可能会需要几天或几星期的时间才能完整恢复整个数据存储。
　　上述这些原因可能和你的实际情况并不符合。很多以客户为导向的系统将大数据分析作为运营处理系统的一部分。也就是说，一个大数据部署的失败可能会直接影响到公司自身的运营。这些大数据应用已经逐渐走向关键业务系统，因此数据恢复就变得空前重要。
　　备份方案
　　严谨的灾难恢复计划包括在有限时间内（恢复时间目标，亦或是RTO）恢复数据到某个一致点（恢复点目标，亦或是RPO）的能力。所选备份策略的组合是由这些目标所驱动的。我们所使用的常用备份方法主要包括：
　　本地以及远程副本
　　虚拟快照
　　复制
　　本地和远程副本由磁盘文件备份和数据库实体备份组成。IT支持人员执行的工作是创建media-to-media的备份，这些备份包含有数据库数据的操作系统文件，而DBA可以用数据库供应商或是第三方供应商的工具通过接口（API）来访问数据。由于专有软件产品供应商的成本，磁盘文件备份更便宜；而数据库厂商提供的工具则更快，在恢复过程中占有速度优势。
　　虚拟快照是一个硬件解决方案，它可以让存储介质创建一个整个系统的虚拟备份。在短时期内数据库写操作被禁用，而硬件管理存储子系统会处理所有文件内部备份的工作。此复制过程可能会非常快，有时是在几秒内完成的。在复制完成后，数据库管理系统则恢复写操作。
　　假设成功创建恢复到某时间点的快照，那么快照可以提供非常快的恢复时间。除此之外，恢复到时间点而非快照创建点需要某种方法来把所有最近的数据库变更（记录在日志中）应用到快照上。另外一个问题就是存储容量。一个快照可能会需要两倍于当前所使用的存储容量。并且，如果发生故障而且此快照是作为当前数据使用的，那么就必须分配另一个快照区域来预防故障扩大。
　　复制包括在另外一个站点创建一套完整的数据库镜像，然后获取所有需要在副本站点制作的本地数据库变更。这样当一个灾难发生时，第二个站点就将成为主站点。这一方法的优势在于RPO几乎是可以达到故障发生的时间点。
　　假设备用站点或恢复站点已经加载了一个本地数据的备份。DBA现在要用数个方法中的一种来获取任何本地数据库变更。这些变更接着会送去恢复站点并在那里得以应用。一个方法是获取任何的插入，更新或是删除SQL语句。另外一个方法是获取数据库管理系统产生的所有日志记录。且有多种供应商工具可以将此过程自动化。
　　自动化恢复过程
　　当要恢复多个数据库的时候，每一秒都很重要。这就是为什么对于所有数据库恢复的不同混合的流程，脚本以及作业控制语言（JCL）需要事先存在的原因。而DBA是在数据库创建的同时来创建所有这些的。随着表和索引添加进数据库，DBA要更新备份和恢复流程。
　　这些流程需要进行定期审查。随着数据容量的增加，备份时间和恢复时间也可能会增加。随着恢复时间延长，它们可能会超出应用程序的RTO。
　　审查的另外一部分是处理RPO.恢复到一个特定时间点的过程开始于有备份恢复数据。接下来，DBA会运行一个流程将日志记录应用到备份上。这些日志记录是在最后一次备份之后所创建的。，并且反应了自那个时间点之后的表变更。随着事务量和数据波动性的增加，备份后的日志记录数量也随之增加。因此，DBA可能要考虑更加频繁的进行备份，备份索引，甚至是采用诸如虚拟快照之类的高速备份选项。
　　恢复测试
　　几乎所有IT应用环境都会随时间的推移而改变，因此恢复流程必须进行测试。这要求DBA去确认哪些流程是最新的，再测量恢复时间，还要对未来的容量变更进行规划。此外，恢复实践是一个不错的方法可以用来在恢复流程方面培训新员工或是缺乏经验的员工。此项培训的一个积极成果是一个成功的灾难恢复测试，这是一些企业根据法规约束或服务协议而要求的。
　　你需要做什么？
　　DBA应该确保已经准备好以下条件：
　　所有产品对象恢复状态的文档；
　　对于属于关键应用的对象定期测量其所需要的恢复时间；
　　为特殊情况开发可替代的备份和恢复方法（例如索引的镜像复制，将数据复制到恢复站点，以及DASD镜像）；
　　定期开发，改善并审查数据可恢复性指标。
　　总结
　　大数据应用以及操作系统必须有一个健壮而快速的恢复流程加以支持。创建这些流程需要设计者从数据库设计开始，坚持到第一个生产环境的部署。
　　恢复需求是任何应用程序或数据库解决方案的一个组成部分。数据库设计者和管理人员可以通过利用这里所讨论的备份和恢复流程适当的组合来保证满足恢复时间目标。