云计算为IT环境及其备份策略和执行带来了技术转变。依赖完善的本地备份规则和模式很方便，但存在风险。这些备份策略之所以流行，是因为它们有效地解决了本地环境中的关键问题。但是，无法保证将这些解决方案原封不动地照搬到云环境中仍然有意义、适用并且经济高效。
让我们来看看两种广泛使用的本地备份策略——“祖父-父-子”和“3-2-1”策略，并探讨它们在公共云环境中是否还有意义。
“3-2-1”备份策略
备份领域中最著名的策略之一—— 3-2-1 模式由三个元素组成：
- 保留（至少）三份数据。
- 将备份存储在（至少）两种类型的备份介质上。
- 在异地保留（至少）一份副本。
架构师不应该简单地将这种策略照搬到云设计之中，而是应该问问自己：这种模式规则为什么在本地环境中至关重要？工程师和架构师想要用它们实现什么目标？
老式备份概念与云功能
老式备份概念与云功能反映了这些内容：左列里列举了模式的规则。中间列显示的是导致这种模式规则产生的需求和要求。最后，最右边一列对云时代很重要：它列举了亚马逊的AWS，谷歌的GCP或微软的Azure等公共云的变化。
几十年来，服务供应商和企业一直将自己的服务器安置在数据中心，这些数据中心的选址都经过了精挑细选。他们希望降低洪水或者山体滑坡之类环境危害的风险。而很多中小型公共或私人组织以及中小企业可能仍然会把服务器放在办公楼的地下室里。
火灾、地震或者卡车撞入建筑物——所有这些事件都可能毁坏整栋建筑物，包括服务器机房。这样一来，推荐的“一个异地备份副本”就成了唯一的救星。但是在云时代，这种备份是否还有意义？
“现场”与“异地”的概念在云时代发生了变化，但有一个风险始终存在：无论你如何仔细地选址，也无论你多么认真地对待物理安全性，都可能有一架飞机撞上你选中的建筑物，或者一场大火（以及随后的消防工作）依然可能摧毁数据中心。将生产工作负载放在一个数据中心并且至少在另一个数据中心有一个备份的做法仍然有意义。AWS跨区域复制（AWS Cross-Region Replication）或者Azure中的异地冗余存储等功能甚至让小型企业也能够为区域性或者全国性的灾难做好准备。
对“两种类型的备份介质”规则的需求不太明显。但是，让我们回顾一下公司将备份存储在磁带或光盘上的时代，看看可能出现的问题。首先，为了方便起见，工程师可能会决定将所有备份保存在一个介质上。如果此介质有缺陷或丢失，所有备份就都丢失了。一个介质显然风险太大，但是如果使用三个磁带，每个磁带都可以工作数年或者数十年，会有什么风险？
为了便于解释，我们假定一年内丢失一个备份磁带的概率为0.1%，并假设我们有三个备份。那么，丢失全部三个备份的可能性是0.1%*0.1%*0.1%=0.001%。如果觉得这个值太高，可以再增加三个备份。在一年之内丢失所有六个备份的概率是0.000001%。相比之下，你此生被闪电击中的概率是0.0065%。考虑到这些可能性，你是否会投资降低同时丢失三个或者六个磁带的风险呢？
这是一个棘手的问题，因为它建立在一个常见的错误之上：假设这些事件彼此不相关，但实际情况并非如此（统计中的因变量和自变量）。如果一盘磁带因为材料缺陷损坏，同一家工厂的同一台机器上生产的所有磁带都可能具有相同的缺陷。因此，在本地环境中，要求使用两种类型的备份介质是一种方便且易于实现的方法，可以降低所有介质同时损坏的风险。但是这条规则能怎么帮助云备份呢？
答案是：这很复杂。S3 对象存储的持久性服务水平协议为一年内 99.9999999999%。但是，由于这是服务水平协议 （SLA），因此你必须信任服务提供商，并且无法验证技术设计和实现。如果云供应商没有兑现SLA，你的公司可能会破产，但云供应商可不会破产。云供应商可能会给你的云服务帐单打一点折，但是如果你的数据丢失了，这点折扣完全无济于事。我个人的观点是：“两种介质”规则在云中几乎是不可能实现的，但是如果你信任服务水平协议，这条规则也就没有必要了。
“3-2-1”中的“3”指的是保留数据的三个版本；例如，在不同的时间点进行两次备份。该策略的一个流行的变种超出了这些要求，这就是另一个众所周知的备份策略：“祖父-父-子”模式。
了解“祖父-父-子”策略
此数据备份模式的典型实现：
- 每周进行一次备份（父）
- 执行每日备份（子）
- 每月保留一个备份（祖父）
祖父-父-子备份概念的月计划示例
展示一个每周“父”备份、每月“祖父”备份以及每日“子备份”的计划是个什么样子。
“祖父-父-子”备份策略是一个复杂的概念，涵盖了公司需要备份的各种场景。第一种情况关乎操作失误。从理论上说，管理员永远不会错误地删除生产数据库。
同样，工程师在将测试系统配置更改应用于生产系统之前，应该仔细检查。但是，如果现实偏离了理论，工程师们就必须将服务器和组件快速回滚到混乱发生之前的状态，解决方案就是使用最近的更新——例如前一天的备份。“子”备份可以满足这个要求。
如果勒索团伙或者政府资助的黑客渗透进入IT环境之中，可能在几天或者几周之内都不会被发现。因此，昨天的备份没有多大帮助。相反，工程师们必须将配置和应用程序（不是业务数据）回滚到几周之前渗透未发生时的状态。在这种情况下，“祖父”备份是理想解决方案。
上面两种示例方案对云环境也必不可少。不同之处在于云中新的数据备份功能，例如对象版本控制或者时间点恢复。
时间点恢复（PITR）在各种数据库中已经存在了一段时间了，但是公共云加速了推广并将其集成到企业备份策略之中。PITR 是一种时间旅行工具，允许管理员和工程师将数据库状态回滚到某时间段内（比如上周或者一个月内）的任何给定时间。如果可用并激活，PITR将让每日备份和每周备份变得过时。根据特定云服务的具体要求、风险偏好和功能，企业在PITR 之外还需要“祖父”备份。
对象版本控制是另一个概念，对对象存储特别有帮助。当用户、脚本或者应用程序将对象替换为较新的版本时，云会将旧版本按照定义保留一段时间。在此期间，不需要进行额外的备份（例如每天或者每周），不过架构师可能还要额外配置长期备份。
高级云备份功能示例——Azure Cosmos DB（左）和 AWS S3（右）
传统备份规则今天仍然适用
在云端配置备份前所未有地容易。只要点击几下，就完成了——然而，存储的巨额账单可能会毁掉你的业务案例。为了防止成本飙升，架构师在制定云备份策略的时候必须考虑成本效益关系。将每月备份保留一年意味着你有十二个备份。将每周备份保留一个月还会增加四个备份。然后，如果你严格执行每日备份并将其存储一周，就还会增加七个备份。因此，备份存储的体积是生产存储的21倍。
既定的传统备份规则（如“3-2-1”和“祖父-父-子”）在当今的云架构中仍然有意义。它们的意义更多地来自战略背后的要求，而不是它们具体的规则和技术。然而，云也具有新的功能，包括冗余和云备份功能，这是大多数中小型公司几年前做梦都想不到的。
因此，云工程师的任务不是照搬以前的模式。他们应该用今天的云功能来满足以往要求中仍然有意义的部分。这样，IT部门就可以定义并执行兼具成本效益和前瞻性的云备份策略。
