读数据保护：工作负载的可恢复性20DR筹划

1.       DR是必不可少的

1.1.         DR（灾难恢复）对于大多数组织来说并不是一个可做可不做的选项，它是一个必须得到满意的需求
1.2.         认为自身受到灾害袭击的概率比力小

• 1.2.1.           如果是在天然灾害或恐怖袭击频发的地区，那么这种概率肯定会稍高一些
  
• 1.2.2.           许多组织都认为它们的运气充足好，不太大概遇到那种事故
  

1.3.         数据中央大概会让飓风摧毁

• 1.3.1.           在这种情况下，你着实没什么选择的余地，你只能把所有东西都重建一遍，这样才能恢复
  
• 1.3.2.           无论你花多少钱都无法改变根本的物理规律，而且总是需要由好几百个承包商通过各种渠道准备相关的材料，这样才能把数据中央重新创建好
  
• 1.3.3.           速率提得稍微快一点，但再怎么快都无法仅用两三天时间就把办公楼跟数据中央建好
  

1.4.         Disaster Recovery，灾难恢复；又称灾备
2.       勒索攻击彻底改变了灾备工作的局面

2.1.         勒索攻击是近来几年才出现的，然而它很快成为许多组织开始认真制定灾难恢复筹划的头号缘故原由
2.2.         必须把应对勒索攻击放在首位

• 2.2.1.           一种RTO充足短的筹划，这样就可以在遇到勒索攻击时从容应对了
  

2.3.         如果你们没针对现在有大概出现的勒索攻击，制定出RTA（实际恢复时间，也就是让系统从灾难中复原所花的时间）较短的灾难恢复筹划，那么在遭遇勒索攻击之后，你就会面对一种状态

• 2.3.1.           这种状态与那种遭遇天然灾害之后所面对的状态差别
  
• 2.3.2.           遇到这种攻击时，你必须尽快做出处置惩罚，每下线一天，你们的组织就要损失一天的钱
  

2.4.         你们的组织会遇到一个让人相称着急的问题，也就是要不要付出赎金

• 2.4.1.           如果决定不付出，那你们就可以把服务器全都清空，然后从头开始恢复
  
• 2.4.1.1.            根据备份与恢复系统的服从，这大概要花费几天到几个星期的时间
  
• 2.4.2.           如果你决定付出赎金，那大概会拿到一个密钥，让你可以或许用这个密钥来解密数据
  
• 2.4.3.           大多数组织在这种情况下都决定付出赎金，因为它们觉得这样处置惩罚起来比力快，而且花的钱要比不付出赎金少
  

2.5.         请别付出赎金

• 2.5.1.           许多组织都是因为这个而多次遭受勒索的
  
• 2.5.2.           对你们的品牌也产生长期影响，因为这意味着你们没有把客户数据恰当地保护好
  
• 2.5.3.           大概因违背GDPR（通用数据保护条例）而遭到罚款，因为这表示你们没有按照这个条例的要求做好数据保护工作
  
• 2.5.4.           付出赎金并不能保证数据肯定会得到恢复
  

3.       DR概述

3.1.         DR（灾难恢复）筹划是一个流程，如果你们的计算情况里有很大一部分办法都无法运作了，那么你就需要启动该流程
3.2.         很有大概是要恢复整个数据中央或整个计算情况

• 3.2.1.           它大概会跨越多个数据中央或云平台
  

3.3.         启动DR筹划的时机与地点，实际上取决于你所要保护的是什么范例的资源

• 3.3.1.           需要保护的大概是数据中央、IaaS/PaaS资源，也大概是你们的任何一款SaaS应用里所生存的数据
  

3.4.         数据中央

• 3.4.1.           如果你需要恢复的是数据中央，那大概是因为它遇到了火灾、水灾或其他天然灾害，也有大概是因为遭受了恐怖攻击
  

3.5.         IaaS/PaaS

• 3.5.1.           如果你们的组织用的是公用云（很大概是这样）​，那么你同样有大概会因为其中的资源丢失而启动灾备筹划
  
• 3.5.2.           云不是万能的，使用云平台并不会淘汰其中的计算资源遭遇灾难的风险
  
• 3.5.3.           危机预防(anticipate failure)
  
• 3.5.4.           容错设计(design for failure)
  

3.6.         SaaS
3.7.         业务持续筹划

• 3.7.1.           业务持续筹划（Business Continuity Planning，简称BCP或BC筹划）是一个相称大的流程，用来确保整个组织在遭遇灾难等庞大事故之后，可以或许继续开展其业务
  
• 3.7.2.           COVID-19是一个让它们的BC筹划必须经受考验的契机
  

4.       DR筹划

4.1.         DR筹划假设你必须从头开始做起
4.2.         问题

• 4.2.1.           你的计算资源、存储资源与网络资源从哪里获得？
  
• 4.2.2.           你打算如何保护你的替代情况？
  
• 4.2.3.           你们的恢复需求是什么？
  
• 4.2.3.1.            RPO（目标恢复点）与RTO（目标恢复时间）必须提前约定好
  
• 4.2.4.           按照什么样的次序恢复？
  
• 4.2.5.           是不是必须先恢复某些部分，然后才能恢复其余部分？
  
• 4.2.6.           应该提前确定恢复次序，并按照那样的次序去恢复
  
• 4.2.7.           职员怎么安排？
  
• 4.2.8.           文档准备好了吗？
  
• 4.2.8.1.            DR筹划的阐明书（也就是DR手册）有没有充分地阐明，某个不熟悉操纵的技能职员能否在无人帮忙的条件下执行该筹划
  
• 4.2.8.2.            DR筹划里还应该有一套审核流程，以确保这份文档总是能及时得到更新审核流程
  
• 4.2.9.           DR手册里有多少东西是可以或许主动实施的？
  
• 4.2.9.1.            主动化是DR筹划成功的关键因素
  
• 4.2.10.      DR筹划经过测试了吗？
  
• 4.2.10.1.        不对备份系统与DR系统做测试，就容易在遇到灾难时手足无措
  
• 4.2.10.2.        要想保证DR筹划有用，就必须常常做测试，以便及时了解其中有哪些地方做得还不到位，别比及必须真正执行恢复时，才发现平常根本就没有做过测试
  

4.3.         单凭一箱磁带是做不了DR筹划的

• 4.3.1.           多年以来，大多数组织的DR筹划都打算用一箱保管在离站地点的磁带来实现
  
• 4.3.2.           磁带从来都不是一种擅长做DR的东西，而且现在真的不适合这样做
  
• 4.3.3.           在做灾难恢复的过程中，这种单线程的恢复工作是磁带最不擅长的一种工作
  
• 4.3.4.           在大规模的灾难恢复过程中，你必须同时恢复十几或几百个服务器或虚拟机，而每一个这样的服务器或虚拟机，都需要用一种单线程的方式（也就是同一时间只能做一件事的方式）来恢复，而且这个恢复流程的进度还有大概因为写入数据的那种存储介质速率较慢而遭到耽搁
  

4.4.         把备份复制到去重设备上也好不到哪里去

• 4.4.1.           真正的问题并非去重设备欠好，而是在于恢复本身
  
• 4.4.2.           如果你的DR筹划是在发生灾难之后才开始从某种备份系统里恢复原来的整个系统，那么你们在RTO（目标恢复时间）上大概就无法满意应对勒索攻击所需的水平，从而更有大概选择付出赎金
  
• 4.4.3.           问题其实出在如何将数据中的重复内容填补回来
  
• 4.4.4.           最好的DR筹划是在灾难没有发生时就预先准备着恢复
  

4.5.         一切都是为了RTA

• 4.5.1.           要想抵住勒索攻击，关键就是你们要在还没遭受勒索时就先搞清晰本组织可以或许忍受的下线时间与数据损失量
  
• 4.5.1.1.            如果各人还没有对涉及这种大变乱时的RTO与RPO告竣一致，那现在就赶紧定下来
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。