【51CTO.com 原创】这次开场我和大家来个brainstorm吧。当提到存储和备份的时候，大家会想到哪些词语呢?
“高可用，高性能、弹性扩展、可按需提供服务， 保障7*24小时的业务连续性，确保数据的一致性、安全性……”
这说明大家已经有了数据保护方面的意识和要求。这使我想到了在大学计算机课程中曾学到的诺兰模型，据个人观察，目前国内大多数企业对于存储备份已经处于了从简单的技术集成阶段向合理化管理和使用阶段迈进的演进中。即“组织使用数据库和远程通信技术，整合现有的信息系统”的阶段，慢慢过渡到“组织开始全面考察和评估信息系统建设的各种成本和效益，全面分析和解决信息系统投资中各个领域的平衡与协调问题”(此处远方传来一声“快闪开，廉哥又要开始装高逼格!”)。说通俗点，当前大多企业要处理的不是有没有备份的问题，而是备份是否得当、有效并与时俱进的问题。
所以我这次来谈谈我在这方面的设计和治理的心得与经验吧。这样接地气的方式容易引起小伙伴们的共鸣。
备份技术
先唠叨、复习一下统一存储的基本概念吧。虽然大家可能都已经明白，而且根据本企业的实际情况已经在内部的传统系统中部署了FC SAN、IP SAN(iSCSI)和NAS三种存储架构中的任意一种。其中FC SAN、IP SAN的传输方式是数据块，而NAS则用文件。而从传输介质来看，FC用的是光纤，而IP SAN和NAS则用的是双绞线。在实际场景中，对需要高性能、高带宽的服务器，多数采用FC SAN架构;对普通文件服务器采用则IP SAN架构;而对于需要进行文件共享的应用也可以采用NAS架构。
然而，大家是否意识到，很多情况下，是为了配合某些新上马的应用系统，我们时常需要集成和采取一套相应的软硬件存储、备份措施，而这在某种意义上导致了整个大系统在宏观上成为了各种数据保护和备份容灾产品的“自治领”。此现象在那些有多个ROBO(远程办公室分支办公室)的企业里尤为突出。而其结果就是：由于备份灾备产品种类多，在产品选型和测试上，需要花费比较多的时间;需要运维人员在跟进过程中，需要学习更多的操作技能;更致命的是各个产品之间相互联动和异构平台支持的效果差，进而形成了各种维护的孤岛。我的建议是企业可以乘系统升级改造的契机(比如说将实体服务器转为虚拟机或转向云服务等)，拿起“奥卡姆剃刀”，进行改造和整合。
说到虚拟化，大家都知道虚拟化的主要好处是可以通过整合来实现规模效应。由于大量的服务器、存储和网络集中在一个资源池中并被统一管理和按需配置，因此虚拟化已被各个企业IT系统所广泛使用，成了迈向云服务的“入场券”。虚拟化平台的容灾保护，一般像SRM和Veeam采用的是虚拟化复制技术。打住，不多说这个了，哥再次重申我们的漫谈说好的是vendor neutral的，大家没有必要“来互相伤害”。因此，对于业务系统连续性要求较高和恢复时间苛刻的企业，一般都会选择使用具有持续数据保护(CDP)特性的产品。从而达到对“任意时间点(Any Point-In-Time)”的细粒度数据访问，实现秒级的恢时间目标 RTO降低恢复点目标 (RPO)。企业如果要扩容来，则可以采取旁路模式部署，只需增加备份或CDP节点，无需修改生产环境下的网络架构，避免不必要的风险。另外，现在固态驱动器(SSD)的价钱降下来了。单单一块磁盘就能获得普通硬盘(HDD)同样的工作负载性能。而且SSD还具有耗电量低、碳排放量少等优点。所以我们曾在硬件选型时重点考量过全闪存阵列 (AFA)。
大家也许会问到："云备份"和备份即服务 (BaaS)，以及灾难复原即服务 (DRaaS)这样的新概念。我个人觉得在技术实现和操作上基本没问题，关键是观念上的认可度的问题。人们总觉得数据放在公有云端后非自己所能完全掌控了。如今国内外各大云平台提供商都已经能提供一整套完善的云备份的方案了，而且也已经有不少“吃螃蟹”的企业用户了。所以关键还是看自己的业务系统。如果业务系统都已经使用或者搬到“云端”了，使用云备份趋势想必也是势在必行的了，it’s only a matter of time。我们就让它“野蛮生长”吧。
备份与留存策略
我们应当根据现有存储空间整体容量和系统使用开销，并根据各个业务部门要求，逐个确定好每个子系统的数据备份和留存周期。比如说，您可以指定：快照每八个小时执行一次(可以仅工作时间);保留最近7天的快照;同时将每天的最后一份快照出库一份到备份环境中，进行离线离场保护。每周二、四的初次备份采用全量备份，其余时间采用差分备份方式;而每月最后一份快照备份扩展保留1年，每一年最后一份快照备份则永久保留。这里只是些参考，具体策略一定要征求业务部门的同意，并最好能双方确认留存。
事故发生前：勤练兵和更新
大家在日常工作中，可通过制定一份详细的恢复演练计划，并定期验证数据保护的效果和灾备数据的完整性。同时演练计划还能提高运维人员的相关操作技能，既能未雨绸缪，还能提升业务水平，真是一举两得。另外，系统恢复后的检查列表也很重要。一份好的check list既是对各项功能的梳理和自检，又能方便大家排查盲点。因此千万不可抱有一劳永逸的思想，要尽量保持及时更新和不断改进。
这里不得不说到一个概念Call Tree，从名字上可知它有别于一般的联系人列表。它更多包含的是If/then的关系的树形结构，并在每个节点上有着primary/alternate的联络方式。它一般包括了当什么类型事件发生时，应该联系谁(响应人员)和通知到谁(监管人员)，以及在某个节点无法联系上时应该采取的流程等。这样的列表不但要保证能分发到每个相关人员，而且在关键场地(如机房或call center)能触手可及。同时保持相关人员联系方式的定期更新也是非常重要的，不然真正事故发生了，大家一派焦(躁)郁(闷)(忙)碌的景象是谁都不想看到的。
事故处理中：厘清主次和关联
一旦中断事故发生了，大喊“Word天”是一种很low的行为。作为专业从业人员，我们一定要“淡定”。要根据需要马上恢复的主要系统和次要系统的事先分类，进行轻重缓急、有条不紊的恢复。在实际操作中可以参照各种关键业务的最大允许中断时间(Maximum Tolerable Downtime, MTD)。而这些数据一般来自于服务水平协议(SLA)，日常业务风险分析或是从企业年度内、外审中得到。
恢复过程中千万别忘了各个子系统之间的相互关联以及先后顺序。比如说B系统一定要等A系统恢复运转后才能顺利进行，或者某些设备必须要等整个网络起来后方可显示为上线状态等。
事故处理后：估值损率和“小目标”
多说一句，如今企业特别是上市公司都讲求信息公开并对各类股东负责，所以一旦发生灾难，信息安全人员乃至IT部门要能第一时间向领导层汇报损失。那么问题来了，如何才能迅速评估损失呢?最快的获取方式是：从年度综合保险的里找到资产清单，并参照日PV(page view)和交易量等数据便可得到。当然通过定期进行业务风险评估(Business Impact Assessment， BIA)，在事故发生前定义好各个子系统可能导致的定量(quantitative，如财务损失等)和定性(qualitative，如公司形象等)损失才是正道哦。不要问这方面我怎么搞得如此清楚，西湖的水，我的泪。。。。
最后再和大家分享一下有趣的事情，大型外企的灾难恢复方案中最重要的目标不是系统的恢复，而是在场人员安全的保护哦。更有甚者还有人员精神及其家属的安抚办法。哥为他们这种不按套路的“傲娇”出牌方式点赞!
至此，我们漫谈系列的第一趴--系统技术部分和大家聊完了。我为自己能坚持到现在所感动，当然也离不开小伙伴们的积极互动与捧场。信息安全从来不是一个人的战斗!常言道：“天青色等烟雨!”(什么鬼?自己去百度一下就知道了!哈哈)See U next time。
【51CTO.com 原创稿件，转载请注明作者及出处。】
