Oracle、MySQL等常用数据库备份恢复总结.docx

Oracle、MySQL等常用数据库备份恢复总结随着信息技术的飞速发展，企业越来越依赖于信息化管理。尽管当前各种新的技术层出不穷，但大多数企业的业务数据依然主要存储在数据库中，比如Oracle、SQLserver、MySQL等。企业对数据库的安全性要求越来越高，为最大化的保护企业的核心数据资产，数据库的数据安全显得尤为重要。本文将从备份恢复的角度来谈谈数据库的数据安全。规划设计篇要想在数据库发生故障时，使用备份恢复到想要的时间点，需要根据实际需求做提前规划。数据库系统的规模越大，设计时需要考量的点就越多，可以说后期大部分暴露出来的问题，大部分都和前期规划有关，下面几个是比较典型的规划相关问题。1.我们单位有个十几套数据库，想集中规划一下备份，还有恢复计划这方面，想了解一下？我们单位有个十几套数据库，主要有oracle和MySQL，目前都是dba自己在维护备份，重要的库做了dg，想集中规划一下备份，还有恢复计划这方面，想了解一下？回答：当数据规模上来了，完全人工管理，工作量会比较大，还容易出问题。有条件的话，最好还是上一套备份系统，可以把企业所有的重要数据集中统一管理起来，如果确实没条件，也可以自己规划一下，主要有以下几点：首先是调研和需求梳理，要对需要备份的数据库系统做一个统计，明确下各个库的rpo和rto，然后根据这些信息可以推算出备份的频率和保存的周期，以及需要的存储空间、大概的性能要求。所有的不能接受丢数据的库都需要备份，高可用、复制等技术替代不了备份。建议和系统管理员沟通，为备份数据分配独立的存储空间。各个库的备份可以集中存放，也可以单独存放。但是不管怎样都建议存放在独立的磁盘空间内。和数据库的存储分开，避免数据库存储故障了，备份也拿不出来了。4.明确责任人，定期检查。比如备份成功率，备份空间使用率等。按照前面的调研，定期对数据库做恢复测试，实在做不了的备份集的校验也得做一下。费这么大精力做数据库备份，就是为了出问题时可以恢复，如果平时不做测试和演练，出了问题手忙脚乱或者发现备份数据不可用，那麻烦可就大了。2.数据库全备一次的时间较长，如果真出了问题，感觉恢复的时间根本接受不了，请问这种情况有什么好的解决办法吗？我们核心数据库目前使用oracle12c，日常的备份策略是周全备，加上按天的归档备份，数据量比较大，全备一次将近一天，如果真出了问题，感觉恢复的时间根本接受不了，请问这种情况有什么好的解决办法吗？回答：这是个很常见的问题，这个问题的误区在于把备份当成了数据安全的唯一手段，这其实是不现实的。其实不光是数据库，所有业务系统的保护都是需要综合考量的，需要多种技术和架构综合来实现，备份只是其中的一个手段，具体以下几点：我们需要确认自己数据库系统的rpo和rto，不同的要求需要不同的技术去匹配，可以参考下面的图：可以看到传统备份可以达到的RPO和RTO实际上是介于小时和天之间的，在现实中可能会几分钟，也可能几天，具体时间是和要恢复的数据量有密切关系的。2.从数据库的故障类型来看，也分很多种，比如：1）高可用的问题，可以通过集群来解决，如oraclerac，基于failovercluster的sql集群，可以解决节点故障的的问题2）数据存储的问题可以通过存储raid或镜像技术来解决，如独立的磁盘阵列，asm镜像等3）存储单点可以通过复制技术来解决，比如基于存储复制，或者OracleDG，db2hadr，MySQL主从复制等都是这种典型；4）误操作的问题，就连这种问题也不一定非要用到恢复，比如Oracle提供的闪回技术，db2TimeTravelQuery，MySQL的systemversionedtable等都可以合理利用起来，甚至有复制集群也提供类似的技术，比如db2hadrDelayedReplay重演延迟所以，从某种意义上来说，实际上大部分情况下是用不到停机停库做介质恢复的，那么备份还有存在的必要吗？当然有了，备份是企业的最后一道防线，可以在极端的情况下发挥巨大的作用。比如严重的存储故障，超出数据库闪回限制的误操作等，还是会用到备份恢复的。另外，也可以通过设计，合理利用现有的备份系统，比如企业自己测试开发环境的创建、数据的二次利用分析等，都可以利用已有的备份环境来实现，可以将备份系统更好的利用起来，发挥更大的作用。日常运维篇1.对于一些误操作或者是坏块，不想恢复整个库或者整个表空间，这些相关的方面能否介绍下？现在的数据库普遍都比较大，做了备份后恢复的粒度也比较粗，耗时长，有时候仅仅是一些误操作或者是坏块，不想恢复整个库或者整个表空间，这些相关的方面能否介绍下？回答：这个问题其实和选用的数据库产品有关，大部分都是软件自身实现的，通用的规则少一些，这也是各家数据库厂商容易做出差异化的地方，简单罗列几点：首先日常的制度上，