读数据保护：工作负载的可恢复性15公有云

1. 云不是万能的

1.1. 其实根本就没有所谓的云，它只不过是别人的计算机而已

1.2. 云、SaaS以及Kubernetes，都没有改变数据保护与数据所有权的基本原则

1.3. 数据是你自己的，你必须负责给它们做备份

• 1.3.1. 除非有人明确保证替你做备份，否则你还是必须自己做

• 1.3.2. 就算有人明确保证，你也得测试看看事实是否如此

2. 公有云

2.1. 许多大型组织都把大部分乃至全部的计算基础设施放置在公用云平台上

2.2. Netflix属于既通过云平台提升服务水平，又以此降低成本的应用程序

• 2.2.1. 它所需要的计算资源在数量上跟某一时刻观看Netflix的人数成正比

• 2.2.2. 它的软件能够根据需求自动调整自己占用的计算资源、网络资源与存储资源

3. IaaS

3.1. Infrastructure-as-a-Service，基础设施即服务​

3.2. 由巨大的数据中心提供的，数据中心里运行着特制的虚拟机管理器以及其他一些进程，用来为你提供近乎无限的扩展与缩减能力，要大可以非常大，要小也可以非常小

3.3. AWS Elastic Compute Cloud(EC2)

• 3.3.1. EC2是一种特制的虚拟机管理器，能够提供各种规模的虚拟机，这些虚拟机可以运行几分钟或几个小时，也可以一直运行下去

• 3.3.2. 要创建虚拟机，必须使用块存储(block storage)，因此EC2需要与EBS相搭配

  • 3.3.2.1. 绝大多数的数据都必须依赖源卷而存在，但EBS快照却不是这样，它是对需要保护的卷所做的完整复制

  • 3.3.2.2. 可以从已经制作的EBS快照里任选一份，并把原始卷（也就是你想要保护的那个或那些卷）恢复到制作该快照时的样子

  • 3.3.2.3. EBS快照的一项优势在于，它们创建时不会产生出口费用，因为这样创建出来的数据并未离开Amazon的范围

  • 3.3.2.4. EBS快照还有一个好处在于，如果虚拟机里的操作系统是Windows，那么EC2虚拟机就能够与Windows系统的VSS机制相交互，从而给运行在Windows系统中且支持VSS机制的应用程序制作application-consistent备份，这种备份方式不用在虚拟机里安装agent

• 3.3.3. 存储系统指的就是AWS Simple Storage Service(S3)

3.4. IaaS本身是不会自动做备份的

• 3.4.1. 可能会有备份数据的功能，但你必须自己触发备份流程，并把备份下来的数据管理好，你必须设法让它们免受各种破坏

3.5. 备份方案

• 3.5.1. 像备份传统的虚拟机那样来备份云端虚拟机，也就是安装一款能够跟云平台顺畅沟通的备份软件或备份服务，令其像备份远程的实体服务器那样来备份这些虚拟机

  • 3.5.1.1. 云平台通常会对传出的流量收取费用（这种费用一般叫作egress charge，即出口费用）​，因此你最好采用一种相当节省带宽的方式来备份

  • 3.5.1.2. 可以考虑从一开始就制作块级别的增量备份

• 3.5.2. 采用云厂商所提供的原生工具来备份

  • 3.5.2.1. 可能是一套API，让你自己的软件或第三方软件能够通过调用该API来实现备份

  • 3.5.2.2. 可能是一套功能齐全的备份服务，让你能够安排备份的计划

  • 3.5.2.3. 这些工具通常是专为这样的环境而设计的

    3.5.2.3.1. 能够利用云厂商所提供的原生机制以及一些附加的功能，这些机制与功能对于那些没有与云平台相集成的工具（也就是非原生的工具）来说是很难加以利用的

3.6. 对象存储(object storage)

• 3.6.1. AWS Simple Storage Service(S3)、Azure Blob与Google Cloud Storage就属于对象存储

• 3.6.2. 对象存储系统跟文件系统一样，也会将文件存放到块存储设备上，但它并不会把存储的这个东西叫作文件

• 3.6.3. 对象既可以是普通用户所使用的那种类似于文件的东西​，也可以是其他东西

• 3.6.4. 对象存储系统完全是扁平的，它把每个对象都存储到bucket（也就是所谓的“桶”​）里面，这些对象全都位于同一个名称空间之中

• 3.6.5. 对象存储与文件系统还有一个区别，就是其中的对象绝不会改变

  • 3.6.5.1. 你能做的仅是保存一个新版的对象，让它替代原来的对象，如果想要做版本管理，那可以把旧版的对象也记录下来

  • 3.6.5.2. 当你通过这样的界面来编辑所谓的文件时，它只不过是把修改之后的文件当成新版对象存了进去

  • 3.6.5.3. 让用户随时都能验证每个对象目前的状态是否与它们刚进入对象系统时一致

3.7. 文件系统

• 3.7.1. 文件系统是一种有层次的存储系统，它用目录与子目录的形式来确定文件的层级

• 3.7.2. 文件系统把文件存放在块存储设备上，每个文件的身份会由文件名与该文件所处的目录来确定，这两个因素只要有一个不同，就不是同一份文件

3.8. 如果磁盘上的文件保存得太久，那么其内容（也就是其中的二进制位）可能会因为介质衰变而发生变化

• 3.8.1. 会造成修改时间虽然没变但文件内容却已改变的现象，这就是位衰减(bit rot)

3.9. 许多组织把IaaS供应商提供的对象存储当成一种廉价的空间，用以保存某些类型的数据，那些数据不会像块存储或文件存储里的数据那样频繁变动

• 3.9.1. 使用S3、Azure Blob或Google Cloud Storage来存放备份或档案

3.10. ⑩主流的这几种对象存储系统提供的许多数据保护功能，都符合3-2-1原则所提出的备份要求

• 3.10.1. 都会把三份数据副本保存到三个不同的位置

• 3.10.2. 可以启用WORM（Write-Once-Read-Man，单写多读）功能，让你自己都无法删除需要保护的数据

  • 3.10.2.1. 可以防止入侵者在获得账户访问权之后删除你的数据

  • 3.10.2.2. 还是一种自我修复机制，能够探查并修复由于位衰减而受损的数据

4. PaaS

4.1. 大多数的云提供商不仅提供计算与存储等基础设施服务，而且还能提供PaaS式的服务

4.2. AWS RDS(Relational Database Service)的用户可以指定自己需要的MySQL版本、数据库的大小，并把某些账号设为管理员账号

4.3. 与IaaS产品类似，许多PaaS产品也提供自动备份机制

4.4. AWS允许Oracle RDS的用户通过RMAN工具自行备份他们的RDS Oracle数据库，但却没有提供从RMAN备份里恢复Oracle RDS数据库的功能

5. serverless服务

5.1. 这种服务的抽象层次比PaaS高。这样的应用程序不需要你配置或管理任何东西，你只需要开始使用就行了

6. SaaS

6.1. Software-as-a-Service，软件即服务

6.2. SaaS应用程序是指为了某种目标而专门构建的全方位应用程序

6.3. 不要求用户自己去搭建基础设施

• 6.3.1. 搭建SaaS服务所需的基础设施并不是用户的责任，用户既不需要管理这些基础设施，也不需要为此付费

• 6.3.2. 用户在购买SaaS产品时，不需要关心该产品所依赖的基础设施（而且SaaS厂商也不应该让用户去关心这个问题）​，用户无须自己去划分并配置服务器与存储空间，而且也不用负保护责任

6.4. 经常自动更新

• 6.4.1. 大多数SaaS应用程序都有敏捷开发模型，总是会把已经做好的新功能按时添加到产品中

• 6.4.2. 你不需要自己去维护或升级这个服务，这会由SaaS厂商为你完成

6.5. 按用量付费

• 6.5.1. 传统的硬件与软件产品总是要求用户提前付费，因此用户需要预先判断自己将来可能要用到多少空间及资源，无论将来是否真的用了那么多，用户都必须在刚开始购买产品时付费

  • 6.5.1.1. 为了确保用户以后有足够的资源可以使用，这些产品通常都配置得比实际需求更高，导致用户必须为那些将来不一定会用到的空间及资源付费

• 6.5.2. SaaS系统允许用户按照实际的使用量来付费

  • 6.5.2.1. 可能要求用户必须提前支付一年左右的费用，过了这段时间，用户就可以按照实际用量来付费了

6.6. 不包含备份机制

6.7. Salesforce

• 6.7.1. SFDC(SalesForce DataCenter)是一种客户关系管理(Customer Relationship Management, CRM)服务

• 6.7.2. SFDC实际上是一个有专门用途的巨型数据库

  • 6.7.2.1. 你不能像使用普通的数据库那样来访问它

  • 6.7.2.2. 你必须使用一套跟普通数据库稍有区别的术语来描述相关的事物

6.8. Microsoft 365

• 6.8.1. 回收站也是一种便捷的手段，让你能够把还没有彻底删除的东西给找回来

• 6.8.2. 要想适当地备份Microsoft 365，唯一的办法还是去购买支持自动备份功能的相关产品或服务

6.9. Google Workspace

• 6.9.1. Google Vault，这是Google Workspace的电子取证与保留系统

  • 6.9.1.1. 能用来给经过该系统的每封电子邮件或每个文件存留副本，而且这种形式的档案很容易通过网页界面来搜索

• 6.9.2. Google Archive同样算不上备份系统

  • 6.9.2.1. 无法把收件箱或Google Drive（Google云端硬盘/Google网盘）里的某个文件夹，恢复到某个具体的时间点

  • 6.9.2.2. 顶多能把账号里存在过的所有文件和邮件全都还原回来

    6.9.2.2.1. 跟你在遇到故障时所要执行的精准恢复相差很远

• 6.9.3. 从能够备份Google Workspace的收费工具里选择一款

6.10. Slack

• 6.10.1. 很多组织都把Slack当作默认的沟通工具，因此他们觉得这个工具对于本组织来说是一个重要的知识库

6.11. GitHub

• 6.11.1. GitHub的服务条款里可没写它会负责备份

7. 云数据也需要保护

7.1. 云并不是一种能够解决所有问题的万能方案

7.2. 公用云走的还是以前的老路，也就是说，​“我们从来都没有打算去解决IT问题，我们只是要把这些问题转移到别处”

7.3. 公用云对服务器与数据的保护水平要比普通数据中心更高

7.4. 你的数据丢失之后，云厂商没有法律义务帮助你恢复这些数据，因为服务协议里没有约定云厂商必须这么做

• 7.4.1. 服务具备可用性(availability)、冗余机制(redundancy)与数据弹性(data resiliency)等说法

• 7.4.2. 看看里面有没有明确出现backup（备份）​、restore（恢复）​、recovery（复原）等词

• 7.4.3. 还可以找找有没有提到如何应对勒索攻击(ransomware attack)或骇客入侵(hack)等问题

• 7.4.4. 经常使用的那款IaaS/PaaS/SaaS产品，其厂商在服务协议里或许根本就没提这些内容

7.5. 一定要把备份数据放在另一个账号里，而且那个账号不能跟主账号位于同一个地区

7.6. 最好的办法是把备份数据全都发往这样一个地区

• 7.6.1. 该地区没有你所使用的任何一种云端服务

7.7. 最好是有多人认证(multiperson authentication)功能，这样可以确保例行删除操作之外的那些删除行为都必须经过多人授权

7.8. 某些对象存储系统所提供的WORM（单写多读）功能，它可以确保备份在保留期之内不会遭到篡改或删除