【.com原创】这次和大家来个头脑风暴。提到存储和备份，你会想到哪些词？“高可用、高性能、弹性扩展、按需服务、7*24小时业务连续性、数据一致性和安全性……”可见大家对于数据保护已经有了意识和需求。这让我想起了我在大学计算机课程中学习的诺兰模型。据我个人观察，目前国内大部分企业都处于从简单的技术集成阶段向存储备份的合理化管理和使用阶段演进的过程中。即“组织利用数据库和远程通信技术整合现有信息系统”阶段逐步过渡到“组织开始全面审视和评估信息系统建设的各种成本和收益，并综合分析和解决所有问题”。信息系统投资方面。领域的平衡与协调”（远处传来声音，“让开，廉哥又要开始装高能了！”）。说白了，目前大多数企业要应对的不是有没有备份，而是备份是否合适、有效、是否与时俱进。所以这次我就来谈谈我在这方面的设计和治理方面的经验和体会。这样接地气的做法很容易引起朋友的共鸣。让我们谈谈备份技术，回顾一下统一存储的基本概念。虽然大家可能已经有所了解，并且根据企业的实际情况，在内部的传统系统中已经部署了FCSAN、IPSAN（iSCSI）和NAS这三种存储架构中的任意一种。其中，FCSAN和IPSAN的传输方式是数据块，而NAS使用的是文件。从传输介质来看，FC采用光纤，IPSAN、NAS采用双绞线。在实际场景中，对高性能、高带宽要求的服务器大多采用FCSAN架构；普通文件服务器采用IPSAN架构；需要文件共享的应用程序也可以使用NAS架构。然而，你是否意识到，在很多情况下，为了配合一些新上线的应用系统，我们往往需要集成并采用一套相应的软硬件存储和备份措施，这在某种意义上导致了整个大，该系统已成为各种数据保护和备份容灾产品的“自治”。这种现象在那些拥有多个ROBO（RemoteOfficeBranchOffices）的企业中尤为突出。结果是：由于备份和容灾产品种类繁多，选择和测试产品需要花费大量时间；运维人员在后续过程中需要学习更多的操作技能；更致命的是，各种产品之间的相互联动和异构平台的支持不力，从而形成了各种维护孤岛。我的建议是，企业可以利用系统升级改造的契机（比如物理服务器转虚拟机或者云服务等），拿起“奥卡姆剃刀”进行改造整合。说到虚拟化，大家都知道虚拟化的主要好处是可以通过整合实现规模经济。由于大量的服务器、存储和网络集中在一个资源池中，统一管理，按需配置，虚拟化已被广泛应用于各企业IT系统，成为云服务的“入场券”。虚拟化平台的容灾保护一般采用SRM、Veeam等虚拟化复制技术。打住，我不说这个了，我重申了我们在聊天中所说的是供应商中立的，没有必要让大家“互相伤害”。因此，对业务系统连续性和恢复时间要求高的企业，一般会选择使用具有持续数据保护（CDP）特性的产品。这样就可以实现“AnyPoint-In-Time”的细粒度数据访问，达到秒级恢复时间目标RTO，降低恢复点目标（RPO）。如果企业要扩容，可以采用旁路方式部署，只需要增加备份或CDP节点，无需在生产环境修改网络架构，避免不必要的风险。此外，固态硬盘（SSD）的价格现在已经下降。单个磁盘可以实现与硬盘驱动器(HDD)相同的工作负载性能。此外，SSD还具有低功耗和低碳排放的优势。因此，我们在选择硬件时重点关注全闪存阵列(AFA)。你可能会问：“云备份”和备份即服务（BaaS），以及灾难恢复即服务（DRaaS）等新概念。我个人认为在技术实现和操作上基本没有问题，关键是概念认同的程度。人们总觉得数据放在公有云之后，就不能完全掌控了。如今，国内外各大云平台提供商已经能够提供一整套的云备份解决方案，已经有不少“吃螃蟹”的企业用户。所以关键还是看自己的业务系统。如果业务系统已经使用或迁移到“云”，那么使用云备份的趋势势在必行，只是时间问题。就让它“野蛮生长”吧。备份与保留策略我们应根据现有存储空间的整体容量和系统使用成本，并根据各业务部门的要求，一一确定各子系统的数据备份与保留期限。例如，您可以指定：每八小时拍摄一次快照（仅在工作时间）；保留最近7天的快照；同时将每天的最后一张快照导出到备份环境中进行离线异地保护。每周二、周四第一次备份采用全量备份，其余时间采用差异备份；每月最后一次快照备份延长1年，每年最后一次快照备份永久保留。这里只是一些参考。具体策略一定要征求业务部门的同意，最好是双方确认。事发前：经常培训更新在日常工作中，可以制定详细的恢复演练计划，定期验证数据保护的效果和灾备数据的完整性。同时，演练方案还可以提高运维人员的相关操作技能，既可以未雨绸缪，又可以提高业务水平，真正做到一石二鸟。此外，系统恢复后的清单也很重要。一份好的检查表，不仅是对各项功能的梳理和自查，也方便大家排查盲点。因此，千万不能有一劳永逸的想法，要努力保持更新，不断完善。这里不得不说一个概念CallTree，从名字上就区别于一般的联系人列表。它包含更多If/then关系的树结构，并且在每个节点上都有主要/备用联系方法。一般包括发生什么类型的事件应该联系谁（响应人员）和通知谁（主管），以及联系不上某个节点时应该采取的流程。这样的名单不仅要分发给所有相关人员，而且要在关键位置（如计算机房或呼叫中心）也能拿到。同时，定期更新相关人员的联系方式也很重要，否则真的会发生事故，谁也不想看到大家焦急（不安）郁闷（无聊）（忙碌）的场景.事故处理过程中：理清主次和关系一旦发生中断事故，喊“字日”是一种很低级的行为。作为专业人士，我们必须“静下心来”。按照事前对需要立即恢复的主系统和次系统的分类，有序、有序地进行恢复。在实际运行中，可以参考各种关键服务的最大允许停机时间（MaximumTolerableDowntime，MTD）。这些数据一般来自服务水平协议（SLA）、日常业务风险分析，或者来自公司每年的内外部审计。在恢复过程中，不要忘记各个子系统的相互关系和先后顺序。例如，B系统必须等待A系统恢复运行才能顺利进行，或者某些设备必须等待整个网络都起来才能显示在线。事故处理后：估值损失率和“小目标”多说一句，现在的公司，尤其是上市公司，强调信息披露，对各股东负责，所以一旦发生灾难，信息安全人员乃至IT部门必须能够立即响应向领导报告损失。那么问题来了，如何才能快速评估损失呢？最快的获取方式是：从年度综保中找到资产列表，参考每日PV（pageview）、交易量等数据。当然，通过定期的业务风险评估（BusinessImpactAssessment，BIA）来定义定量（quantitative，如财务损失等）和定性（qualitative，如公司形象等）损失才是正确的方法可能是事故发生前各子系统引起的。哦。别问我这方面怎么这么清楚，西湖之水，我的泪。...最后，想跟大家分享一件有趣的事情。国外大公司的容灾计划最重要的目标不是系统的恢复，而是对在场人员安全的保护。更重要的是，有办法安抚人员及其家属的精神。喜欢他们不按套路出牌的“傲娇”打牌方式！至此，我们和大家聊完了本系列的第一部分——系统技术部分。能坚持到现在很感动，当然也离不开朋友们的积极互动和支持。信息安全从来不是一个人的战斗！俗话说：“天高云淡，雨露守候！”（什么鬼？去百度一下就知道了！哈哈）下次见。【.com原创稿件，转载请注明作者及出处。】
