1.1. 许多计算环境采用的都是混合云(hybrid cloud)模型，这种模型会把适合放在云端处理的任务移动到云端，同时把那些适合在本地处理的任务留在数据中心
1.2. NFS/SMB网关
1.2.1. 最经典的混合云产品，就是那种通常称为云网关(cloud gateway)的东西
1.2.2. 让应用程序与用户去使用数据中心里的某台设备，该设备看上去好像跟其他设备一样，但实际上，此设备会将数据保存到云端（而不是保存在本地的数据中心里）
1.2.3. 比较常见的云网关是NFS或SMB服务器，由于它把数据保存到云端，因此在存储容量方面不受限制
1.2.4. 网关设备是否仅充当云端的缓存
1.2.4.1. 要看云平台在整个存储方案里的地位
1.2.4.2. 如果本地设备会把需要保存的所有数据都发往云端，那么这个设备就仅是一个缓存
1.2.4.3. 不需要担心如何备份这些缓存数据，要考虑的只是云端的数据副本，至于那些数据副本是否需要备份，则要看它们是如何受到保护的
1.2.4.4. 如果云端只是整个存储体系里的一层，那就完全是另一回事了
1.2.4.5. 有一些数据是保存在本地的，而且这些数据只出现在你的本地设备里面，因此，你必须像备份数据中心里的其他数据那样来备份这些数据
1.2.5. 网关设备是否具有版本管理机制
1.2.6. 网关设备自身的存储策略
1.2.6.1. 如果网关设备会把目前的所有数据（也就是目前每一个文件的最新版本）都保存到本设备里，那么意味着这些数据都会在云端留有一个备份副本（也就是备用的副本），而本地设备里保存的这个副本则是我们的主要副本
1.2.6.2. 如果网关设备只会保存活跃的文件（比方说，只会保存在过去30年内使用的文件），那就是另一码事了
1.2.6.3. 不活跃的文件只会保存在云端（那些文件在本地设备里是没有副本的），因此，你必须按照上一条所说的来考虑云端文件的备份方案
1.2.7. 网关设备是否将数据复制到多个云平台
1.2.7.1. 如果你能将每个文件的所有版本都分别在AWS S3与Azure Blob上保存一份，那么从数据保护的角度来看，就很难挑出毛病了，在启用WORM特性之后，这种方案会更加可靠
1.2.7.2. WORM特性对某些对象存储系统来说是相当重要的
1.2.7.2.1. 该特性能够防止入侵者或本组织的雇员恶意删除整个账号中的内容
1.2.7.2.2. 如果不启用此特性，那么他们只需要敲几下键盘就能把数据全删掉
1.2.7.2.3. 启用WORM特性之后，就连你自己都没办法在保留期还未到时删除数据，至于那些想要破坏数据的人，自然也就同样无法删除数据了
1.3. 云盒
1.3.1. cloud in a box，也称盒中云
1.3.2. 可以从云提供商那里租借这样的硬件设备，把它放在你的数据中心里面，并在其中运行云提供商的某些服务或全部服务
1.3.3. 由于这种设备只不过是把云提供商所提供的那套服务搬到你这里来运行，因此备份云端数据时所遵循的那套原则现在依然需要遵守，而且其中有些资源可能需要保护得比云端更加严密
1.3.4. 安装了云盒设备的数据中心，也会作为一个availability zone出现在可选名单中
2. Docker与Kubernetes2.1. 容器与编排器（orchestrator，也叫协调器）
2.2. Docker与Kubernetes给传统的备份与恢复流程所带来的变化，比以前好长一段时间里发生的变化都要大
2.3. 容器就是一个轻量级的虚拟机
2.3.1. 通常只具备某一种功能
2.3.2. Docker是一个容器运行时环境(container runtime environment)
2.3.2.1. 负责在运行于Docker中的这些容器与Docker所处的这台主机上的操作系统之间对接（这个操作系统通常是Linux系统）
2.3.2.2. Docker所在的主机运行的基本上都是Linux系统
2.3.2.3. 它只需要负责把自己应该具备的功能呈现出来
2.3.3. 虚拟机专门运行在某种特定的虚拟机管理器里，而虚拟机管理器又专门运行在某一套特定的硬件之上，与虚拟机相比，容器要灵活得多
2.3.4. 容器可以运行在任何一种Linux系统上，如果安装了适当的软件，那么它也能运行在Windows系统上
2.3.5. 容器的存在时间远比虚拟机短暂
2.3.5.1. 一般的虚拟机可能会运行几个月乃至几年时间
2.3.5.2. 大多数容器的存留时间都不会超过一星期
2.4. Kubernetes
2.4.1. 在生产环境中运行大量容器是需要做出编排的，这也正是Kubernetes派上用场的地方（Kubernetes通常简写为K8s）
2.4.2. K8s能够为容器分组，让它们形成多个pod，这些pod之间很容易沟通，而且能够共用某个已经挂载的卷
2.4.3. K8s pod通常称为逻辑主机(logical host)，这种逻辑主机跟虚拟机有点像，其中所容纳的一个或多个容器，就相当于虚拟机里运行着的某条线程
2.4.4. 在Kubernetes里定义应用程序的时候，你需要指定构成该程序的各种资源，还需要指定初始化、访问及销毁这些资源所需的配置信息
2.4.5. Kubernetes总是运行在集群里，容器也总是能够按照需要来创建并销毁
2.5. 从数据保护的角度来看，Docker与Kubernetes真是让人又喜欢又讨厌
2.5.1. 讨厌的地方在于，每出现一种新产品，我们的数据备份工作就有可能变得更加复杂
2.5.2. Kubernetes确实在数据保护领域取得了一些重要突破
3. 容器如何改变传统的备份方式3.1. 在虚拟化技术出现之前，我们是通过给服务器里放置agent来做备份的
3.2. 在虚拟机管理器这一层面来运行agent，并令其将虚拟机作为镜像加以备份
3.3. 到了容器时代，这两种模式都不管用了
3.4. 对于容器来说，目前还没办法将agent放在容器运行时（例如Docker）这一层运行
3.5. 不要把可用性与恢复能力混为一谈
3.5.1. 可用性高，并不意味着遇到灾难之后的恢复能力也比较高
3.5.2. 容器的基础设施，其每一部分都已经内置了相应的机制，以确保高可用性(high availability)
3.6. 除了DR（灾难恢复），你还需要确保自己能够重制整个环境，例如能够从测试/开发环境移动到生产环境（也就是正式环境），或者从生产环境移动到升级之前的staging环境（预备环境/过渡环境）
3.7. 运行在K8s集群里的应用程序可能也需要备份，以便处理用户错误及软件bug，并与相关的法律法规相符
3.8. 无论你选用什么样的备份方案，都必须保证有待保护的数据确实全都得到了保护
4. Dockerfile4.1. Docker容器需要根据镜像运行，而镜像则需要根据Dockerfile构建
4.1.1. 通过Docker image history命令，根据当前的镜像创建一个Dockerfile出来
4.2. 如果你想配置一套合理的Docker工作环境，那么首先应该考虑用GitHub这样的代码仓库来做版本管理系统，以控制所有的Dockerfile
4.2.1. GitHub，它提供了许多种方式，让你能够备份其中的库
4.2.2. 可以使用第三方的收费工具来备份GitHub
4.3. 应该先把所有的Dockerfile都存放到代码仓库里，这样的话，如果当前构建的这一版有问题，那你就可以把这个Dockerfile过去的版本pull（拉取/提取）出来，并根据那一版去构建
4.4. 即便是第三方的Docker镜像，也应该这样管理，因为那些镜像的制作者未必会保留以往的版本
4.5. 如果你需要回滚到某个旧的版本，那么在自己管控这些镜像的场合里操作起来会更加方便
4.6. 与每个K8s deployment有关的YAML文件也应该纳入代码库
4.6.1. 属于文本文件，把它们纳入版本控制系统是有好处的
4.7. Docker镜像
4.7.1. 你运行容器所依据的那些镜像也应该保存在某个库里
5. Kubernetes etcd5.1. Kubernetes的etcd配置数据库相当重要
5.2. 把这个数据库备份下来，能够帮助我们对整个集群做元数据恢复(metadata recovery)，因为它既保存了集群的状态，还保存了配置信息
5.3. 通过etcdctl snapshot save snapshot.db命令来备份
6. 持久卷6.1. 容器可以通过各种方式来访问用于存放或创建数据的持久存储
6.2. 传统的方案是Docker卷，它是以Docker环境中的子目录形式存在的
6.3. 从备份的角度看，传统的卷与刚说的bind mount在本质上是一样的
6.4. 持久卷(persistent volume)的备份方式取决于你在容器里面是怎样使用它们的
6.5. 持久卷里的数据可能在不断地变化，你必须解决好这一点，才能创建出application-consistent镜像
6.5.1. 一种解决办法是把使用这个卷的容器全都停掉
6.5.1.1. 虽然有点老派，但绝对管用
6.5.1.2. 把容器关停之后，你就可以备份这个卷了
6.5.1.3. 如果这是一个传统的Docker卷，那就在开始备份时把它挂载到另外一个不会改变该卷数据的容器，然后，你可以在一个以bind mount形式挂载的卷里给你要备份的卷创建tar镜像，最后，你可以用你的备份系统所支持的办法来备份这个bind mount
6.5.2. CSI（容器存储接口）
6.5.2.1. CSI的好处在于，它是一种标准的插件，让K8s管理员能够通过这套标准的API来申请存储空间，同时又允许每个存储提供商采用不同的方式来实现这套API
6.5.2.2. CSI还内置了数据保护功能
7. 数据库7.1. 一个办法是直接连到数据库引擎，让它把数据备份到一个文件里，然后你去把那个文件备份下来
7.2. 另一种办法是在另一台主机上运行数据库备份命令，让该命令针对容器里的那个数据库做备份
