#yyds干货盘点#信息安全的最后一道防线-数据备份
前言：即使今天我们有各种各样的备份手段来实现最基本的周期性的数据备份到实施数据，数据容灾，业务容灾。但依旧经常听到或遇到数据丢失的情况。到底是现在的备份手段还不够强大，还是运维人员疏忽，究竟是什么原因频频发生数据安全事件，难道数据对企业来说就这样可有可无，值得拿来冒险吗。结果当然是不。任何一个稍有经验的运维人都会知道数据有多么重要，数据是整个信息化的灵魂。没有了这些数据。那些昂贵的设备只会是一堆摆设，究竟要怎样才能让我们做好数据备份。才能守好这信息安全的最后底线呢。
。
1.你的数据备份了吗？观点1：
就我个人而言我感觉他们没有备份或者对备份没有足够的重视，大体原因有二：
1、系统运行一直良好，根本没有出现过数据丢失的问题。即使机器出现故障一般都是电源、内存、硬盘等等，硬盘一般都是以raid5居多，所以坏一块也不会丢失什么数据。
2、即使有了备份，他们也从没真正还原过，或者说不会还原操作。他们把重心放在了前者防范上，而不是遇到丢失用备份去还原上。
总之一句话：是因为还没有真正遇到过数据丢失的情况，所以他们不重视！
观点2：
备份一定要做，不仅从安全角度，而且合规性检查也是要求的，至于备份存放的位置就可以商榷了，除了明文要求异地的，你可以放在同一机房，或者你认为恢复足够快的地方。考虑自然灾害的几率太低了，而且即使发生了，也不会抢救到所有数据，毕竟有异步时间差。
观点3：
备份一定是要做的，否则会有哭起来的哪一天。
不仅要做备份，还需要经常做备份恢复演练。我曾经遇到有的人数据库宕机，用了一个月之前的备份恢复的，虽然丢失了一段时间的数据，但是大部分还在。
我也遇到过，在HA的双机中，没有做备份，询问之后告知我，因为是双机所以不需要备份。不久数据库宕机，起不来了
2.备份，容灾如何去选择？观点1：
说说我的看法吧，数据备份，是只针对业务数据进行备份，实时的也好，调度的也好，都备份的是业务中的数据或环境，用来在系统发生故障，硬件损坏，误操作等情况下恢复正确的数据或者业务环境的一种手段。数据备份一般会保存一定的周期，数据容灾是指建立一个异地的数据系统，为了保护数据安全和提高数据的持续可用性，两者其实实现的效果并不相同，一个是用来保证数据的安全性和正确性，一个是用来保证业务的实时性，在我看来。如果你对你的业务和数据足够重视，那么至少线从数据备份做起，保证数据的基本安全，根据业务特点搭建容灾环境来保证业务的连续性，其实两者并不矛盾。
观点2：
我们信息科只是钢铁生产中的一个小小的服务部门，公司只抓生产，产量、质量，而没有给与我们辅助部门足够的重视，造成我们的维护成本一般偏低。所以容灾是无法让领导理解和明白的。于是乎只能退而求其次运维人员尽量做好数据备份。因为出了问题，不是他们的责任而是我们运维人员的责任。
观点3：
这要看合规性检查的相关要求，比如财务系统是必须容灾加备份的，有的还要求备份到独立介质，异地存放等等，大部分容灾指的是异地数据备份，还未到自动业务切换，要达到业务级的容灾，倒不如做双活或者多活的数据中心，反而投入比单纯的容灾要值得。
3.你的备份数据是有效的吗？观点1：
数据备份，作为发生事故时的救命稻草，往往被我寄予最后的希望，但数据备份真的能在危难时刻挽救我们吗？
曾经发生过的一个教训和大家分享一下，以前的stk9730 磁带库，backupeasy的备份软件备份数据库。因为软件操作简单。界面直观。也让我有些大意，没有定期做数据的恢复测试，直到有一天数据库发生了错误。需要还原一个数据库，才发现整个磁带库上所有备份的数据还原时都出错，可这些数据在备份时都没有任何错误报警。虽然事后还是通过其他的手段恢复了这个库。但还是吓出了一身冷汗。
一路走下来。需要备份的业务也越来越多，也就开始越来越担心数据的有效性。虽然经常去检查备份数据，但总是还不放心，恨不得把数据备份放到所有的地方才安心。
观点2：
备份总是要用来恢复的，备份是尊严是底线。
备份的数据是否有效，通过数据验证方式来判断数据是否有效，是否损坏。
没有经过验证的数据备份方案，本身就是一场灾难。
定期进行数据验证并形成SOP数据恢复操作手册，搭建好数据验证环境。
通过备份软件方式进行数据的备份，定期检查备份策略是否有效。如果对数据库备份，用脚本进行检验校对。
观点3：
我觉得验证备份有效性的唯一手段就是恢复演练，定期进行数据恢复演练是非常有必要的，现在结合虚拟化啥的，异机恢复的资源都不是问题，所以没事就演练一下，看看磁带介质啥的是不是有效？
另外我还觉得，涉及到落带永久保留的数据，最好是要复制成两份，亲身经历的就是数据恢复的时候磁带怎么都无法定位，而且也不抱错，就是一直定位中，直到超时；最后是找到另外一份copy2，从另外的磁带恢复数据，数据这种东西，多保存几份没坏处。
4.如何选择合适的备份手段？
观点1：
说说我们的备份历程吧，
1，2001年网络开始建立初期，供应商上了一堆东西。当时刚入行，对什么都感觉新鲜，当时买了一台STK 9730的磁带库，DLT磁带。单盘容量70g,配合Veritas backupeasy对win系统和SQL SERVER 数据库进行备份。这个软件操作比较简单。但功能也相对有限，本来还算顺利。但随着设备的老化，开始出现问题，备份日志每天都检查并无异常，但是在抽查测试数据恢复的时候恢复失败，尝试了很多个时间点的备份都是同样的问题，这才决定更新备份，
2，大约是2007年左右。备份的手段还不算多，光盘塔已经逐渐被淘汰，磁带库正式快速发展的阶段。价格低廉，而磁盘阵列则还处于一个比较搞的价格，所以对于数据备份。我们还是选择了lto3磁带库，软件方面，当时三大厂商把持这备份市场的份额，Veritas ，legto，和IBM 的tsm,不过当时并没有机会去做更多的测试，领导还是根据价格选择了TSM。总体来说虽然不错，但这东西真的有点繁琐，
3随后大概很长的一段时间，都开始重复在更新TSM ,购买磁带库的阶段，但随着业务的发展，开始逐渐暴露出问题，备份软件版本升级迫使对一些低版本的业务无法备份。有些新扩展的业务比如VMWARE用现有的版本又无法备份。磁带库的备份效率低，。速度慢。磁带库驱动器有限，无法并发多任务，想要解决这些问题，都需要做大改动，
4，大约是2013年，这个时候的磁盘阵列价格已经相对降低了许多，而磁带库虽然仍然占有一定的市场，但已经开始不太作为备份的主流，各种国产备份软件，备份一体机出现。需要备份的系统，软件版本跨度大，备份类型繁多，技术人员少，这些都让我们放弃了传统的大厂商备份软件。转而测试备份一体机，
在emc的备份软件和备份一体机 的测试中，EMC无法适应从2003到2008，sql2000到oracle这样凌乱的数据类型，最终还是选择了界面简单。操作简便的备份一体机。
观点2：
因为工作原因，一直用tsm，刚开始那一两年真是被虐的死去活来。后来入门了觉得还行就慢慢用下来了，发现功能挺强大的，除了难用点。
对传统IT架构来说，几乎搞定一切场景了。
观点3：
目前我们这边的备份也比较凌乱，虽然各个应用和系统都在做备份，但是备份手段太多，
操作系统使用SSR备份；
数据库使用各数据库自带的备份方式，比如Oracle的RMan、SQL Server的备份计划；
所有本地备份后rsync到一台大容量的服务器中。
目前还没有统一的备份平台，这个是我们后面要改善的。
5.你的备份数据保存多久？观点1：
理论上来说。重要数据都有保存的周期。但我们的数据混杂。备份能力不足。本应该保存3个月或半年的数据其实都达不到要求
观点2：
如果存储够，而且数据又不能确定是否有用，建议一直保存，如果不够，建议封存，如果需要找回以前的老数据，那就恢复一下。
观点3：
我们的数据分为三种，活跃数据，查询数据，冷数据。
活跃数据本地存储7天，查询数据在阵列中存储2个月，冷数据在对象存储中存储1年。汇总整理会保留有效数据3年。
观点4：
数据备份保留多久，这个需要根据客户业务而确定。备份策略是指综合备份类型和备份频率。如年度备份，季度备份策略，月度备份，周备份，天备份
这些需备份战略和备份场景，重要业务系统等。
观点5：
数据按照业务要求，数据库的数据一般都是2周到2个月不等，文件的话，有些落带永久保留并出库，还有写保留2周到几年。
6对数据安全，数据备份，领导不重视，你如何处理？观点1：
很多政企对数据安全和备份都不重视，如果你多次申请都没有得到回复。那能做的就是尽量自保吧，
1，首先，利用手头的资源尽可能的做备份。做好安全，是竭尽权利的做好这些。
2.把提交的报告形成书面的文档。得到书面的回复。出了问题。没有你的责任。
3.准备好应急方案，出现问题后那些可以补救。那些补救不了。出问题之后领导知道痛了需要提交怎样的申请。
观点2：
既然不重视，必然有几方面的原因，一种就是外行领导内行，没出过事自然不知切肤之痛。其次难以争取数据安全方面的费用，因为没有相关文件的明文规定，所以较难获得这方面的投资，如果有，那就是不做为了。大部分现在都有指导建议，只是你备份的规模可能和投入有不少差距。做好合理的数据备份规划，提交审批都算尽责了。现在不重视的人越来越少了，还是乌纱帽要紧。
观点3：
作为运维人员，数据安全上你是第一责任人，出了问题肯定不会找领导，先找到你。如果真恢复不了，你就是替罪羊。所以数据备份不备份完全是运维人员的事。即使没有条件，你也应该自己有后路，有办法将损失降到最低，这是你的职责。
https://blog.51cto.com/pysx0503/4598471
页:
[1]