随着信息技术的飞速发展，企业越来越依赖于信息化管理。尽管当前各种新的技术层出不穷，但大多数企业的业务数据依然主要存储在数据库中，比如Oracle、SQL server、MySQL等。企业对数据库的安全性要求越来越高，为最大化的保护企业的核心数据资产，数据库的数据安全显得尤为重要。

本文将从备份恢复的角度来谈谈数据库的数据安全。

规划设计篇

要想在数据库发生故障时，使用备份恢复到想要的时间点，需要根据实际需求做提前规划。数据库系统的规模越大，设计时需要考量的点就越多，可以说后期大部分暴露出来的问题，大部分都和前期规划有关，下面几个是比较典型的规划相关 问题。

1. 我们单位有个十几套数据库，想集中规划一下备份，还有恢复计划这方面，想了解一下？

我们单位有个十几套数据库，主要有oracle和MySQL，目前都是dba自己在维护备份，重要的库做了dg，想集中规划一下备份，还有恢复计划这方面，想了解一下？

回答：
当数据规模上来了，完全人工管理，工作量会比较大，还容易出问题。有条件的话，最好还是上一套备份系统，可以把企业所有的重要数据集中统一管理起来，如果确实没条件，也可以自己规划一下，主要有以下几点：

1. 首先是调研和需求梳理，要对需要备份的数据库系统做一个统计，明确下各个库的rpo和rto，然后根据这些信息可以推算出备份的频率和保存的周期，以及需要的存储空间、大概的性能要求。
2. 所有的不能接受丢数据的库都需要备份，高可用、复制等技术替代不了备份。
3. 建议和系统管理员沟通，为备份数据分配独立的存储空间。各个库的备份可以集中存放，也可以单独存放。但是不管怎样都建议存放在独立的磁盘空间内。和数据库的存储分开，避免数据库存储故障了，备份也拿不出来了。
4. 明确责任人，定期检查。 比如备份成功率，备份空间使用率等。
5. 按照前面的调研，定期对数据库做恢复测试，实在做不了的 备份集的校验也得做一下。费这么大精力做数据库备份，就是为了出问题时可以恢复，如果平时不做测试和演练，出了问题手忙脚乱或者发现备份数据不可用，那麻烦可就大了。

2.数据库全备一次的时间较长，如果真出了问题，感觉恢复的时间根本接受不了，请问这种情况有什么好的解决办法吗？

我们核心数据库目前使用oracle 12c，日常的备份策略是周全备，加上按天的归档备份，数据量比较大，全备一次将近一天，如果真出了问题，感觉恢复的时间根本接受不了，请问这种情况有什么好的解决办法吗？

回答：
这是个很常见的问题，这个问题的误区在于把备份当成了数据安全的唯一手段，这其实是不现实的。其实不光是数据库，所有业务系统的保护都是需要综合考量的，需要多种技术和架构综合来实现，备份只是其中的一个手段，具体以下几点：

1. 我们需要确认自己数据库系统的rpo和rto，不同的要求需要不同的技术去匹配，可以参考下面的图：
   

可以看到传统备份可以达到的RPO和RTO实际上是介于小时和天之间的，在现实中可能会几分钟，也可能几天， 具体时间是和要恢复的数据量有密切关系的。

2.从数据库的故障类型来看，也分很多种，比如：

1）高可用的问题，可以通过集群来解决，如oracle rac，基于failover cluster的sql集群，可以解决节点故障的的问题

2）数据存储的问题可以通过存储raid或镜像技术来解决，如独立的磁盘阵列，asm镜像等

3）存储单点可以通过复制技术来解决，比如基于存储复制，或者Oracle DG，db2 hadr，MySQL主从复制等都是这种典型；

4）误操作的问题，就连这种问题也不一定非要用到恢复，比如Oracle 提供的闪回技术，db2Time Travel Query，MySQL的system versioned table等都可以合理利用起来，甚至有复制集群也提供类似的技术，比如db2 hadr Delayed Replay重演延迟

所以，从某种意义上来说， 实际上 大部分情况下是用不到停机停库做介质恢复的，那么备份还有存在的必要吗？ 当然有了，备份是企业的最后一道防线，可以在极端的情况下发挥巨大的作用。比如严重的存储故障，超出数据库闪回限制的误操作等，还是会用到备份恢复的。

另外，也可以通过设计，合理利用现有的备份系统，比如企业自己测试开发环境的创建、数据的二次利用分析等，都可以利用已有的备份环境来实现，可以将备份系统更好的利用起来，发挥更大的作用。

日常运维篇

1.对于一些误操作或者是坏块，不想恢复整个库或者整个表空间，这些相关的方面能否介绍下？

现在的数据库普遍都比较大，做了备份后恢复的粒度也比较粗，耗时长，有时候仅仅是一些误操作或者是坏块，不想恢复整个库或者整个表空间，这些相关的方面能否介绍下？

回答：
这个问题其实和选用的数据库产品有关，大部分都是软件自身实现的，通用的规则少一些，这也是各家数据库厂商容易做出差异化的地方，简单罗列几点：

1. 首先日常的制度上，做好权限管理，这个反而是最重要的。如果权限混乱 谁都可以sys上去，技术再好也没用。
2. 做好日常备份，如果有备份的话，Oracle的坏块实际上可以直接通过块恢复的方式在线把数据块恢复出来。
3. 如果没备份，或者备份没覆盖到，Oracle本身提供了一些手段（dbms_repair包或者10231事件）可以跳过坏块，但相应的可能会损失一点数据，如果可以接受，跳过再补录就行。如果不能接受可能得需要找专业的数据恢复来做。
4. 日常的误操作可以考虑使用闪回技术，Oracle的闪回工具比较多，有下面几个：

闪回数据库：基于数据块对库做闪回

flashback drop：基于recycle bin恢复误删除的表

flashback version query和flashback transaction query: 基于undo技术恢复误操作的数据，记录级别

flashback table：基于undo技术恢复误操作的表

其他数据库也有类似的技术，但可能不太全，具体根据对应的手册查询一下即可。

5. 如果是查询类的库，平时数据量变化不大，可以对数据库对象进行导出备份，出现问题的时候，导入受损对象即可，比如db2 数据库可以有导出表的作业进行另一种形式的备份，有问题时只恢复单独某个表。

2.db2数据库异构系统迁移？db2数据库从aix小机迁移至redhat的X86服务器系统

回答：
异构的话：
1.用导入导出的方式做，db2look导出表结果，export导出数据，再用import或者load做导入，简单但比较慢，导的过程中数据有增量后面需要处理；

优化建议：通过定义游标的方式+分批处理 这样会快很多，不用担心服务器硬件资源不够用。建议采用 load 游标方式进行迁移。 Load 语句中需要带 nonrecoverable; 参数，不然迁移完毕数据库后 导致表所在的表空间出现了 pending 状态。

需要特别注意的地方：当数据库表有自增序列时，定义表结构时需要把 GENERATED ALWAYS AS IDENTITY 改成 GENERATED BY DEFAULT AS IDENTITY ； 不然无法导入！

2.用数据库同步软件，比如ogg cdc

3.db2数据库归档日志模式，日志清理？

已将DB2日志模式设置成归档日志；

每天定时执行online 备份，

命令：db2 backup db DBNAME online to /data/db2backup/ compress include logs

发现备份文件每2天 就要增大100M左右（数据量不会有这么大），怀疑是日志的原因于是执行了清理日志命令：

//查看备份历史，找出最近备份数据库的日志,

db2 list history backup all for DBNAME

db2 prune history 20210310190913 and delete

db2 prune logfile prior to S0000110.LOG

执行成功后，发现日志确实被清理了，但是重新备份数据库，数据库备份文件还是没有变小

回答：

db2 backup语句中的include logs选项是把备份期间产生的几个归档备份上，本身就没多大。而用prune修建的是归档目录中的日志，和产生的备份文件没有关系，这是两码事，所以备份文件没啥变化是正常的。

4.MySQL数据库故障Can't open file: 'xxx_forums.MYI'. (errno: 145)？

回答：
.myi是MySQL myisam引擎的索引文件，一般情况下，文件属组丢了或者数据库意外关机可以导致出这个问题，可以尝试使用myisamchk命令修复一下。

命令参考：

https://dev.mysql.com/doc/refman/5.7/en/myisamchk.html

5. 在利用ftp下载备份文件进行恢复测试时，突然出现文件损坏的现象无法恢复数据库？

备份文件ftp传输后无法恢复？在利用ftp下载备份文件进行恢复测试时，突然出现文件损坏的现象无法恢复数据库？

回答：

1、备份文件坏了就不能用了

2、找到坏的原因更重要。FTP传输时，有ASCII和BINARY两种模式，在ASCII 方式下传输 二进制文件 ，即使不需要也仍会转译，这会损坏数据，建议采用 BINARY模式传输。

3、每个备份上传后，源、目标端两个文件对比一下MD5 SUM值，放心。

4、备份任务重的话，买Dell EMC DataDomain，省时、省力、省心，还安全可靠！

总结

从数据库的数据安全的角度来看，备份恢复只是这个体系中的一部分，和集群、复制等技术共同保护数据库数据安全，但备份却是不能忽略的一部分。一个良好的备份系统，前期的规划设计是非常重要的，在日常运维中也要注意定期的测试和演练，确保出现问题时可以及时顶上。

备注：本文取材于交流活动“Oracle、MySQL等常用数据库备份恢复难点与运维故障在线答疑”， 内容由hufeng719、ostrich、yulu4314、lbam001等会员贡献，本人归纳整理。