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

1.1.1. 许多产品只支持磁盘，另一些虽然支持磁带，但仍然是以磁盘为主的

1.1.2. 产品都把磁盘作为首要的备份目标（而且通常只支持把数据备份到磁盘上）

1.2. 除了以磁盘为中心，这些产品还有一个共同之处，即它们都想要应对市场中的某些变化

1.3. 专门用来备份各种IaaS、PaaS与SaaS式产品的方案开始流行起来

1.4. 即时恢复与自动化的定期测试功能出现之后，备份领域确实产生了很大变化，许多备份方案都在考虑如何设计这两项功能

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.1. 系统一开始只有一个节点，该节点具备一定的存储空间，以后你可以给这个节点添置更多的磁盘，以提升其存储能力

3.2. 也称垂直扩展

4.1. 系统一开始就有许多节点，每个节点有自己的计算与存储资源，这些节点合起来形成一个集群(cluster)

4.2. 又称水平扩展

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.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方案最适合那种不想亲自执行备份操作，同时又想让数据免受勒索攻击的人