计算巢备份的使用场景，实现方式，费用与使用方法。
背景介绍
在实际使用中，用户经常遇到需要对数据做备份的场景，例如：
幻兽帕鲁游戏的私服，因游戏本身原因经常会出现掉档情况，为解决这个问题，需要按时备份。
某数据库服务，为保证数据安全，需要进行备份，降低可能发生的故障损失。
某服务，需要做升级，但是升级过程中可能导致数据丢失。因此在升级操作前做数据备份。
在过去，计算巢用户遇到需要备份服务实例数据的场景，需要自行在各云产品的控制台做备份。例如，如果服务实例部署于ecs，则用户需要登录ecs控制台，筛选找到服务实例部署的ECS，手动给该ECS的云盘打快照；而恢复则需要用户自行查找自己做备份用的云盘快照，并在ECS控制台做数据回滚。很显然，当需要备份的云盘或RDS实例较多时，会因操作非常繁琐而不便于用户使用。而且，恢复时，用户需要自行记录哪个名称的云盘快照或RDS实例的备份是自己需要的，比较容易出现错误。为解决这个问题，计算巢上线了备份管理功能，以实现在计算巢控制台，一键为服务实例的云资源数据做备份或恢复。
实现原理
计算巢的备份与恢复功能，主要依赖底层云资源的备份与恢复能力。因此，计算巢是否支持某个云产品的备份与恢复，一方面取决于计算巢是否针对该云产品开发了相关功能，另一方面也取决于该云产品是否支持对自己的数据最备份与恢复。当前计算巢支持备份和恢复的云产品有：
阿里云块存储（云盘）。
引擎为MySQL、Sql Server、PostgreSQL的阿里云RDS实例。
备份
在数据备份前，计算巢会生成一个空的备份记录。该记录会存储备份开始时间、备份结束时间、备份状态以及本次备份涉及到的各云产品的实例ID及其备份状态。
在做数据备份时，计算巢会根据服务实例ID，利用云资源上的tag标签筛选出隶属于该服务实例的所有云资源，并筛选出其中的块存储（云盘）与前文所述类型引擎的RDS实例。而后会逐个调用各云产品的api以实现数据的备份。调用api成功后，计算巢会循环扫描各云产品的备份结果。当备份状态为终态时（成功or失败）会记录下结果并展示给用户。一般情况下，一次计算巢的备份会涉及到多个云产品的多个实例。只要还有一个实例处于“备份中”，计算巢的备份记录就会处于“备份中”。当所有云产品的所有实例都完成备份后，只要有任意云产品的任意实例备份失败，计算巢的备份记录会被标记为“备份失败”；只有所有云产品的所有实例都备份成功，计算巢的备份记录才会被标记为“备份成功”。
恢复
与备份类似，在恢复前，计算巢会生成一个空的恢复记录。该记录会存储恢复开始时间、恢复结束时间、恢复基于的备份的ID、整体恢复状态以及本次恢复涉及到的各云产品资源id及其恢复状态。
由于云盘在做数据恢复时，必须保证其挂载的ECS实例是停机状态。因此，在恢复前，计算巢会将服务实例整体关机。关机完成后，会查询恢复基于的备份数据ID，逐个调用各云产品的api做数据恢复。api调用成功后，计算巢会循环扫描各云产品的恢复结果。当恢复状态为终态时（成功or失败）会在恢复记录中记录下结果并展示给用户。一般情况下，一次计算巢的恢复会涉及到多个云产品的多个实例。只要还有一个实例处于“恢复中”，计算巢的恢复记录就会处于“恢复中”。当所有云产品的所有实例都完成恢复后，只要有任意云产品的任意实例恢复失败，计算巢的恢复记录会被标记为“恢复失败”；只有所有云产品的所有实例都恢复成功，计算巢的恢复记录才会被标记为“恢复成功”。当恢复完成后，计算巢会再次将服务实例开机。需要特别指出的是，由于恢复机制原因，MySQL引擎或PostgreSQL引擎的RDS实例在恢复过程中库表会被重命名，进而引起原库或原表找不到。为了解决这个问题，在遇到上述两个引擎的RDS实例恢复时，计算巢会利用FC函数向RDS实例执行库表重命名的SQL，将库名或表名重新命名为原值。因此，如果您的服务实例中包含MySQL引擎或PostgreSQL引擎的RDS实例，在恢复过程中可能产生FC的费用。
费用
计算巢备份功能本身不会产生费用。由于计算巢备份功能是依赖各云产品的备份能力，因此费用的产生主要是各云产品备份所产生的。主要有以下三部分：
使用方式
如果您的服务需要开启备份与恢复功能，您需要做两步操作：
在服务运维（选填）栏目下，添加运维操作，基础运维项。
打开备份与恢复按钮。
至此，备份与恢复已经开启，该服务的服务实例可进行备份与恢复。