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

标题: 读数据保护：工作负载的可规复性29新式的数据保护方案 [打印本页]

---

作者: 一给    时间: 2025-1-8 10:57
标题: 读数据保护：工作负载的可规复性29新式的数据保护方案

1. 新式的数据保护方案

1.1. 产品都是围绕着磁盘计划的

• 1.1.1. 很多产品只支持磁盘，另一些虽然支持磁带，但仍旧是以磁盘为主的
  
• 1.1.2. 产品都把磁盘作为首要的备份目的（而且通常只支持把数据备份到磁盘上）​
  

1.2. 除了以磁盘为中心，这些产品还有一个共同之处，即它们都想要应对市场中的某些变化
1.3. 专门用来备份各种IaaS、PaaS与SaaS式产品的方案开始盛行起来
1.4. 即时规复与自动化的定期测试功能出现之后，备份领域确实产生了很大变化，很多备份方案都在考虑如何计划这两项功能
2. 专注于虚拟机的办理方案

2.1. VMware

• 2.1.1. 很多人都用VMWare来虚拟x86架构
  
  
  
  • 2.1.1.1. 可以大概让多个虚拟机共用同一台实体服务器上的CPU、内存与I/O资源
    
  
  
• 2.1.2. VCB
  
  
  
  • 2.1.2.1. VMware Consolidated Backup, VMware整合备份
    

    2.1.2.1.1. Very Crappy Backup（很糟糕的备份）​
    

    
    
  • 2.1.2.2. 很多公司在这套API上浪费了大量的研发精力，VMware最终放弃了VCB
    
  
  
• 2.1.3. VADP
  
  
  
  • 2.1.3.1. vSphere Storage API for Data Protection
    
  • 2.1.3.2. 含有CBT（Changed-Block Tracking，数据块修改追踪）机制
    
  • 2.1.3.3. 不再需要给虚拟机里安装agent了，备份软件可以大概通过VADP给这些虚拟机做备份，而且还能实现块级别的增量备份
    
  • 2.1.3.4. 在VADP还没出现的这段时间里，传统的备份方案并没有拿出可以大概真正办理虚拟机备份问题的办法
    
  
  

2.2. 只支持磁盘，而且只支持Windows操作系统，这意味着备份软件只能运行在Windows系统上，而且不能把数据备份到磁带中

• 2.2.1. 把研发重点放在怎样让客户可以大概较为轻易地使用该方案上
  
• 2.2.2. 只打算针对虚拟机做计划，因此它们不用处理与其他架构及操作系统有关的那些复杂问题
  

2.3. 今天的数据中心里，用的基本上全都是虚拟机，而虚拟化技术也是各种云端技术的底子
2.4. 把关注范围收窄，可以大概让本身给产品里添加很多先进的功能，假如还像传统的备份方案那样覆盖很大的范围，那就没办法实现那么多功能了
2.5. 优点

• 2.5.1. 一般是通过Windows系统里的UI步调（也就是带有图形界面的步调）来操作的
  
• 2.5.2. 用户可以大概更加直观地访问到他们所保存的备份数据，与传统方案所制作的那种备份相比，这些备份更像是副本或快照
  
• 2.5.3. 自动的备份测试
  

2.6. 挑战

• 2.6.1. 所有东西都可以通过GUI（图形化的用户界面）来操作，而这意味着你必须有一套console（鼠标、键盘、显示器）用以操控这个这套图形界面
  
  
  
  • 2.6.1.1. 入侵者同样可以大概相当轻易地访问并破坏这些数据
    
  
  
• 2.6.2. 很多运行于headless模式或连接到KVM虚拟机的系统，都共用同一套显示器、键盘与鼠标
  
• 2.6.3. 最常使用的是RDP（Remote Desktop Protocol，远程桌面协议）
  
  
  
  • 2.6.3.1. RDP很轻易受到勒索攻击
    
  
  
• 2.6.4. S3的object lock功能很适适用来制作离站的备份副本，而让介质服务器运行Linux系统，则可以令保存在本构造内的那些备份数据更加安全
  

2.7. 接纳默认的配置方式制作备份是不安全的，因此绝对不应该这么做

• 2.7.1. 绝对不要让装有Windows操作系统的服务器，把放置在当地存储设备中备份数据，通过C:\BACKUPS这样的路径展示出来
  

2.8. 只需要使用Windows这一种系统，以是，操作系统的数量确实降下来了，但与此同时，你所要面临的安全风险却比原来有所增长
3. 纵向扩展

3.1. 系同一开始只有一个节点，该节点具备肯定的存储空间，以后你可以给这个节点添置更多的磁盘，以提升其存储本领
3.2. 也称垂直扩展
4. 横向扩展

4.1. 系同一开始就有很多节点，每个节点有本身的计算与存储资源，这些节点合起来形成一个集群(cluster)
4.2. 又称水平扩展
5. 超聚合备份设备

5.1. 用一个可以大概横向扩展的存储系统来专门负责辅助存储与备份方面的工作
5.2. Hyper-Converged Backup Appliance, HCBA
5.3. 其中某些设备专门用来做备份与规复，另一些则是既能做备份与规复，又能充当辅助存储
5.4. 未必所有人都喜欢用实体设备做备份

• 5.4.1. 它让用户可以大概把注意力集中到这一个设备上，如果有什么问题，那么在这一个设备上找原因就行了
  

5.5. 优点

• 5.5.1. 接纳横向扩展方案时，你可以轻松地扩充服务器、RAID阵列或目的去重系统的规模，而这正是那些接纳纵向扩展架构的方案很轻易出问题的地方
  
• 5.5.2. 具备肯定的防勒索攻击本领
  
  
  
  • 5.5.2.1. 基于Linux操作系统的架构，这一点与专注于虚拟机的方案以及很多传统的备份方案差异
    
  
  

5.6. 挑战

• 5.6.1. 使用了横向扩展架构而具备很强的扩展本领，但它们的收缩本领却不像其扩展本领那样强大
  
• 5.6.2. 如何得当地配置资源
  
  
  
  • 5.6.2.1. 备份需要使用肯定的资源，规复也需要使用一些资源
    
  • 5.6.2.2. 如果你想复用这些备份数据，让它们发挥别的效果，比方说探测病毒或勒索攻击，或是从中寻找某种你所关注的趋势等，那么必须为此再配置一些计算资源与I/O资源
    
  • 5.6.2.3. HCBA在不执行这些扫描流程时，你为此配置的这些资源会处在闲置状态
    
  
  
• 5.6.3. 无法单独扩展存储资源或计算资源，而是必须同时扩展这两方面
  

5.7. HCBA方案接纳基于Linux操作系统的架构，这降低了安全风险，也让本钱变得比以前稍微低了一些
5.8. HCBA厂商通常会提供一个镜像，让你可以大概通过该镜像同时升级操作系统与应用步调，这有点像给硬件更新固件(firmware)时的效果
5.9. 还能接纳云技术做灾备(DR)，并且具备电子取证功能
5.10. HCBA方案要求你们一开始必须投入大量资金购买该方案，从这一角度看，它跟传统的IT系统很像

• 5.10.1. 在使用这种方案时，你无须为了担心将来不够用而提前配置过多的资源
  

5.11. HCBA方案所具备的优点比其他几种适用于构造内部的备份方案要多，而其缺点则比那些方案要少
6. DPaaS

6.1. Data-Protection-as-a-Service，数据保护即服务
6.2. 适合那种想做备份，但又不想亲身处理备份变乱的人
6.3. 根本不需要客户去购买、租用或维护任何的备份底子设施
6.4. 实现备份与DR（灾难规复）方面的需求
6.5. SaaS产品以服务的情势来提供IT办理方案，它不需要用户去购买、租用、配置或管理运行该服务所需的底子设施
6.6. SaaS还有一项重要的特征在于，公司会持续升级软件背后的服务，而用户则只需要继续使用这个在线版（大概说网页版）的软件，而不用去管提供该服务的那台服务用具体怎么升级
6.7. 如果你购买的是DPaaS产品（这可能是一个只做日常备份的BaaS产品，也可能是只一个做灾备的DRaaS产品，还有可能是一个同时具备这两项功能的产品）​，那么这款产品的使用方式应该跟其他的SaaS产品类似
6.8. 云平台都会向你收取出口费（egress charge，也叫出站费用）
6.9. 与存储有关的各个方面可能都会引发开销

• 6.9.1. 存储量
  
  
  
  • 6.9.1.1. 每个月都要为本身的数据在对象存储里所占据的空间付费
    
  
  
• 6.9.2. API哀求
  
  
  
  • 6.9.2.1. 每次通过PUT哀求添加对象、通过GET哀求获取对象，或通过LIST哀求查询对象时，都需要付费
    
  
  
• 6.9.3. 获取数据
  
  
  
  • 6.9.3.1. 如果打算使用冷存储（cold storage）来存放数据，那么你在从中获取数据时，还需要根据获取量付费（通常以GB计算）​
    
  
  
• 6.9.4. 传输数据
  
  
  
  • 6.9.4.1. 只要你把对象存储里的数据传输到别处，就得根据传输量付费
    

    6.9.4.1.1. 出口费或出站费
    

    
    
  • 6.9.4.2. 从对象存储里执行数据规复，或是要把对象存储中的数据转移到冷存储，就会引发这样的开销
    
  
  
• 6.9.5. 提升传输速率
  
  
  
  • 6.9.5.1. 可以哀求把某些数据放到离规复场地比较近的地方，这样以后需要规复时，在传输数据上花的时间就会少一些
    
  • 6.9.5.2. 就得为需要运用该功能的这些数据付费（按照数据量收费）​
    
  
  
• 6.9.6. 数据管理
  
  
  
  • 6.9.6.1. 数据名录与扫描等，这些功能同样要收费
    
  
  

6.10. SaaS方案应该不需要由用户管理方案背后的底子设施
6.11. 优点

• 6.11.1. 便于使用
  
• 6.11.2. 会把所有的备份数据都保存到你们的数据中心之外，而且是用一个与你们的账号毫无关系的账号来保存的
  
• 6.11.3. 数据在传输过程中会加密，而且储存时，也是以加密的情势存放的
  
  
  
  • 6.11.3.1. 如果你使用的是本身的存储机制，而不是厂商所提供的存储机制，那么就必须本身保护这些备份数据了
    
  
  
• 6.11.4. 不要求前期必须投入一大笔资金来购买
  
• 6.11.5. 很多接纳DPaaS方案的用户都会一次购买一到两年的服务
  

6.12. 挑战

• 6.12.1. 看不到它的具体计划方式
  
  
  
  • 6.12.1.1. 不知道后端系统是什么样子，也不知道这个系统是如何计划的
    
  • 6.12.1.2. 不清楚该系统能不能根据需求自动扩展，也不清楚数据放在那里是否安全
    
  • 6.12.1.3. 多向对方提问，并了解对方有没有获得相关的认证
    
  
  
• 6.12.2. 要了解他们的去重系统是如何运作的，并对此执行一些测试
  
  
  
  • 6.12.2.1. 必须做测试，除此之外没有别的办法
    
  
  
• 6.12.3. “球鞋网络”(sneakernet)
  
• 6.12.4. 当地缓存
  
• 6.12.5. 规复到云端
  
  
  
  • 6.12.5.1. 寻常并不需要为这套机制付费，只有在你测试它大概因为碰到数据变乱而需要启动该机制时，你才需要付费
    
  • 6.12.5.2. 带宽能不能迅速传输日常的备份
    
  • 6.12.5.3. 如果可以，接下来还要考虑首次制作的完全备份如何存放到云端，以及如何执行规模较大的规复
    
  
  
• 6.12.6. 反向seed
  

6.13. 数据保护是一种很适合以服务的情势来做的事情，因为这种事情比很多人想的要复杂得多，而且没有谁愿意揽这个活儿，更没有谁愿意专门花钱雇人来计划并维护这样一个备份系统
6.14. 防止备份数据因主数据遭遇勒索攻击而一并为攻击者所加密
6.15. DPaaS方案最适合那种不想亲身执行备份操作，同时又想让数据免受勒索攻击的人

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

---

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

Powered by Discuz! X3.4