ToB企服应用市场:ToB评测及商务社交产业平台

标题: 读数据保护：工作负载的可恢复性22DR运行手册 [打印本页]

---

作者: 十念    时间: 2024-12-31 11:02
标题: 读数据保护：工作负载的可恢复性22DR运行手册

1. 购买DR软件

1.1. 自行选购DR软件，意味着你可以把它安装到你自己所管理的服务器上

• 1.1.1. 服务器可能是实体机
  
• 1.1.2. 能是你所拥有的（或你向云平台购买的）虚拟机
  

1.2. 必须全面负责它们的安保工作

• 1.2.1. 任何一个安保疏失，都是你的责任
  
• 1.2.2. 必须确保硬件、操作系统、存储设备以及DR软件都已经把各种应该安装的补丁给安装过了
  

1.3. 勒索攻击之以是可以或许造成破坏，大多数都是因为系统管理员没有安装得当的安全补丁
1.4. 利益主要在于可以或许控制

• 1.4.1. 可以采用你们平常制定的那些信息安全原则来维护
  

1.5. 坏处则体现在本钱上

• 1.5.1. 如果要自己购买并维护足够的基础设施来处理这项工作，那么必须提前准备额外的设备，而且还要考虑到这个过程中可能出现的各种负载较高的情况，并为此预留相应的设备
  
• 1.5.2. RTO与RPO越严，你们在这方面的开销就越有可能暴增
  

1.6. 主流的软件公司已经推出了基于订阅的收费形式

• 1.6.1. 不用一次就交纳一大笔费用
  
• 1.6.2. 其实这只是收费上的区别，并不意味着该方案的优点与缺点会因此而有所变化
  

2. DRaaS

2.1. 如果你是用DRaaS（DR-as-a-Service，灾难恢复即服务）式的产品来做DR的，那么一样平常来说，你只需要在得当的地方安装一个agent
2.2. 其实就是基于SaaS模式的DR服务

• 2.2.1. 真正的SaaS环境不需要让你去管理系统运作所需的那套基础设施。
  

2.3. 你不需要以管理员身份登录某个服务器或存储系统，因为这完满是由SaaS厂商负责的
2.4. 如果你照旧得以超级用户的身份登录位于某地的某些服务器，那你用的就不是真正的DRaaS产品
2.5. 利益在于，你不用担心怎样购买、配置并管理该服务背后的那套盘算设施或存储设施了，因为那些都已经由服务提供商替你做了

• 2.5.1. 确保全部的DR资源都安排到位，完满是DRaaS提供商的责任
  
• 2.5.2. 它们会保证你总是有足够的资源做DR，并负责确保这些资源免受攻击
  

2.6. DRaaS方案会把那种自行管理DR软件的方案所没能做好的地方，全都做好
2.7. 即便采用了该方案，你也可能照旧要自己管理恢复站

• 2.7.1. 你可能照旧得负责管理这些用来在发生灾难时取代主盘算环境的服务器
  
• 2.7.2. 把管理权限赋予这些盘算机，让它们自己去管理自己
  
• 2.7.3. 采用公用云，这意味着在真正遇到灾难之前，不会出现相关的虚拟机或未经加密的卷
  

2.8. 缺点

• 2.8.1. 你无法施加控制
  
  
  
  • 2.8.1.1. 要想把某件事做好，你就自己来吧
    
  • 2.8.1.2. If you want something done right, you do it yourself.
    
  
  
• 2.8.2. 它通常需要经由云资源来提供，而在某些人眼里，云总是不如自己的数据中心安全
  
• 2.8.3. 某些人总觉得云不敷安全，其中的资源更容易遭到网络攻击
  

2.9. 一样平常的云提供商所具备的安保水平，都要高于一样平常的数据中心

• 2.9.1. 对于大多数组织而言，IT部门本身并不是该组织的目标，它只是为该组织实现其目标提供支持而已
  
• 2.9.2. 云端产品则否则，对于许多云端产品来说，它的主要目标就是把IT做好
  
• 2.9.3. 如果某个云产品连安全都做欠好，那很快就会遭到淘汰
  
• 2.9.4. 云端产品这一领域就是要靠安全说话，这也正是以为一样平常云厂商，以致一样平常SaaS厂商，都必定会做好安保的原因
  
• 2.9.5. IT职员是专心做安保，而云工作者则是拼了命做安保
  

3. 用同一产品做照旧用不同产品做

3.1. 就SaaS应用而言，现在除了厂商自己所执行的DR之外，还没有真正意义上的这种DR产品
3.2. 当前最好的办法也只能是等SaaS厂商恢复正常之后，再去恢复你的数据
3.3. 购买一件产品来管理全部事件，当然要比分别购买两三件产品来专门管理两三种不同的事件要自制
3.4. 如果RTO或RPO是0，那你肯定需要购买一款基于主数据复制机制的DR工具

• 3.4.1. 几乎没有那种既能把RTO或RPO压到0，又能把一样平常的操作恢复给做好的工具
  

3.5. 如果这种基于复制机制的DR工具可以或许把一样平常的操作恢复给做好，那你就可以考虑让该工具身兼二职，而不用专门购买一样平常的操作恢复工具了
4. DR方案

4.1. 目标是让主盘算环境在为某种灾难所摧毁之后，可以或许尽快上线
4.2. 目标不是购买某个可以或许做备份的数据复制产品，或某个可以或许做复制的数据备份产品，也不是为了专门去使用或专门不去使用云平台，而是要让你们的组织在遇到灾难时可以或许尽快上线
4.3. 开始跟厂商沟通之前，肯定要先搞清楚操作恢复与灾难恢复这两个方面的需求
4.4. 编写DR运行手册

• 4.4.1. DR手册通常以电子书的形式制作
  

5. DR运行手册

5.1. 需要设计一份DR运行手册，让某个懂IT的人可以或许依照这份手册，从头到尾执行你的灾难恢复操持

• 5.1.1. 可否做到这一点，正是判断手册质量是否合格的标准
  

5.2. 所要实现的目标

• 5.2.1. 权势巨子(Authoritative)
  
  
  
  • 5.2.1.1. DR运行手册只能有一份
    
  • 5.2.1.2. 必须是最新版
    
  
  
• 5.2.2. 精准(Accurate)
  
  
  
  • 5.2.2.1. 根据不正确的信息做灾难恢复，是相称困难的
    
  
  
• 5.2.3. 易于获取(Accessible)
  
  
  
  • 5.2.3.1. 最容易让大家访问到运行手册的办法就是把它放在网上
    
  • 5.2.3.2. 电子版的运行手册应该保存在许多地方，本组织内部与云端都要有
    
  • 5.2.3.3. 这些手册之间的版本要同步，以便让访问者总是能获取到最新版本，这应该是比力容易做到的
    
  • 5.2.3.4. 打印一份纸质的版本
    
  
  
• 5.2.4. 易于明白(Absorbed)
  
  
  
  • 5.2.4.1. 每个人都要把这份手册给吃透(everyone needs to grock it)
    
  
  
• 5.2.5. 及时更新(Active)
  
  
  
  • 5.2.5.1. 这份手册应该持续更新，并纳入你们一样平常的变动控制流程
    
  • 5.2.5.2. 通过自动编目机制把这些东西添加到运行手册里
    
  • 5.2.5.3. 无论通过哪种方式更新手册，都必须确保该方式总是能让手册的内容保持最新
    
  
  
• 5.2.6. 灵活(Adaptable)
  
  
  
  • 5.2.6.1. DR操持肯定要灵活，肯定要有备用的办法
    
  
  
• 5.2.7. 可审计(Auditable)
  
  
  
  • 5.2.7.1. 外界应该能根据你的这份运行手册来验证它是否有效
    
  
  
• 5.2.8. 可确认(Affirmed)
  
  
  
  • 5.2.8.1. 凡是未经测试的DR手册，都不能称为有效的DR手册
    
  • 5.2.8.2. 没有做过测试的DR手册仅是一份理论上的手册而已
    
  • 5.2.8.3. 必须执行通例的DR测试，让工作职员按照这份手册上设计的步骤去做灾难恢复
    
  • 5.2.8.4. 多执行这样的DR测试，会资助你把运行手册写得更好
    
  • 5.2.8.5. 备份做测试是很重要的，而对DR操持做测试则尤为重要
    

    5.2.8.5.1. DR测试做得越频繁，将来真正执行DR时就越容易乐成
    

    5.2.8.5.2. 测试时要假设全部深知DR操持的人都无法到场，你们只能通过那些平常不做DR的人来执行灾难恢复
    

    5.2.8.5.3. 必须把不得不请教专家的地方给记录下来，因为这意味着你的手册在这些地方没有讲清楚
    

    5.2.8.5.4. 平常测试得比力充实，而且可以或许根据测试结果及时更新这份手册以及与之相关的系统，那么到了必须紧急启动DR操持时，你们就不会那么慌张了
    

    
    
  
  

5.3. DR流程概述

• 5.3.1. DR手册的开头应该概述本组织的DR流程
  
• 5.3.2. 应该以一份执行纲要(executive summary)开头，这个纲要可以明白为对概述所做的概述
  

5.4. 技能清单

• 5.4.1. 灾难恢复过程中用到的每个产品都应该列在“技能清单”部分，而且要写上提供该产品的每个公司的联系信息
  
• 5.4.2. 最好能让阅读手册的人知晓相关条约
  
• 5.4.3. 肯定要知道自己能联系到谁，并了解到这些人应该提供什么样的设备或服务
  

5.5. 联系信息

• 5.5.1. 需要把组织里可以或许到场或指导恢复流程的每一个人都考虑到
  
• 5.5.2. 灾难发生之后，时间很紧急，以是多写几种联系方式是很有资助的
  
• 5.5.3. DR流程的指挥者（或者说高管）也相称重要
  
• 5.5.4. 多存几份，放在各种地点
  
  
  
  • 5.5.4.1. 即便有好几个地方同时受灾，你们也照旧能通过这样的信息联系到符合的人
    
  
  

5.6. 具体步骤

• 5.6.1. 重点在于，你写的这套流程是给那种熟悉IT并且知道怎样登录与管理系统的人看的
  
• 5.6.2. 在你们的组织里，全部做IT的人都应该到场培训，以便在需要执行DR操持时，可以或许从容地执行该操持
  

5.7. 上报异常状况

• 5.7.1. 操持赶不上变化
  
  
  
  • 5.7.1.1. 总会有你操持不到的东西
    
  
  
• 5.7.2. 如果网络无法按照预先设想的方式予以初始化，那么就应该将其上报给首席网络管理员
  
• 5.7.3. 如果联系不到，就应该上报给IT部门的主管
  
• 5.7.4. 如果还不可，就应该继续上报给CIO（首席信息官）​，依次类推
  
• 5.7.5. 肯定要提前定好，不要让执行DR操持的人到了真正遇见异常状况时，再去想到底应该联系谁
  
  
  
  • 5.7.5.1. 按照手册里预先定好的流程上报即可
    
  
  

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

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4