谷歌数据中心都被雷劈了，你该如何做好“异地备份”？

家住北京西二旗的小张是一家互联网金融公司的运维工程师，金融行业的数据可是很值钱的，任何的损坏和丢失都不能容忍。

为此，小张选了北京品质最高的机房，买了品质最好的硬件，做了全面的数据备份容灾策略：

每 24 小时做一次全量备份，每 1 小时做一次快照备份，还有每 5 分钟的增量备份。备份的数据存于专门的备份服务器，在分布式系统中会有 3 拷贝冗余，而且还考虑了跨机架的副本放置策略。每个环节都有监控和报警，系统运转良好，各种故障都能及时锁定及时处理。

但这样，数据容灾策略可以万无一失么？

在一个炎炎夏日的傍晚，小张结束一天的工作，终于可以回家享受啤酒小龙虾了。谁想天气突变，狂风暴雨电闪雷鸣，小张电话响起：

机房被雷劈了！还被劈了三次！！！！

小张赶紧赶回去抢救，经过万般努力，得以恢复大部分数据，但是仍有少量数据无法恢复，因为这部分数据的所有副本所在的硬盘损坏了 …

这个故事看上去不可思议，但是生活往往比真实更戏剧化，这种「被雷劈」的故事真实发生过，我身边有人遇到过，连 Google 这种大公司也遇到过。

2015 年 8 月，Google 欧洲的数据中心 europe-west1-b 就遭遇了天灾，被雷劈了！尽管 Google 的灾备方案十分严密，但仍然有少量的数据永久丢失了。 Google 在官方的事故报告的最后给出了一段关于备份安全策略的建议，原文如下（链接：https://status.cloud.google.com/incident/compute/15056#5719570367119360）：

We would like to take this opportunity to highlight an important reminder for our customers: GCE instances and Persistent Disks within a zone exist in a single Google datacenter and are therefore unavoidably vulnerable to datacenter-scale disasters. Customers who need maximum availability should be prepared to switch their operations to another GCE zone.

大意是 Google 云平台上一个区的计算实例和存储盘存在单一数据中心风险，无法避免数据中心级别的灾难。提醒客户做好自己的异地备份，以保证最佳的数据安全。

除了雷劈这样的自然灾害，我们的系统每天都会面临各种数据安全威胁，比如机房断电、UPS 故障、被拔网线、系统被入侵、人为误操作等等。

另一个更让人扼腕的数据是，根据资讯安全机构 Ponemon Institute 调查研究，在发生重要数据丢失之后，仅有 6% 的公司能在缺乏灾难恢复计划的情况下幸存。

灾难随时都有可能发生，面对这个现实，能最大程度降低风险系数的，不是在灾难发生后寻找解决方案，而是让「重要数据永远有备份」。

将重要数据备份到一个相对隔离的系统中（异地数据中心），是一个非常有效的备份方案，能规避上面提到的大部分风险，保障公司业务数据的安全。

如何做异地备份？

异地备份，顾名思义，就是把数据备份到物理隔离的另外一个地方。

在已有本地备份（同机房）的情况下，异地备份意味着要把数据完整地在其他地方再复制一份。根据主业务是自建机房还是使用公有云的不同，异地备份在地点选择上通常有下面几种：

有两个或以上的数据中心，数据可以在不同数据中心之间互备；

主业务系统在自己的（或者租用的）数据中心，备份数据在共有云上；

主业务系统在公有云上，备份一个副本在另一个服务区（ Region / Zone ）；

主业务系统在公有云上，备份一个副本在另一家公有云上。

自建多个数据中心并不多见，周期长、人力成本高。对于中小型公司，甚至大公司的部分非核心业务部门来说，目前的主流做法是选择公有云作为异地备份方案，因为它容易实施，能最快速保证数据安全。

那怎么用公有云来实施异地备份呢？

异地备份的理想与现实

在实施「异地备份」之前，一般会先做「本地备份」，即备份到同一个数据中心内，方便恢复。本地备份的存储方案通常有以下这些：

自建分布式文件系统

优点：大多选用 HDFS 。它是 Hadoop 生态的默认存储方案，有 3 副本冗余的策略，还有机架感知特性，对大数据分析的支持也很友好。

缺点：HDFS 需要自己维护高可用的 Name Node 集群，容量规划和扩容工作也会占消耗运维团队资源。如果你的 HDFS 集群还肩负业务计算和数据备份需求，基于 JVM 的 Name Node 在高负载工作下垃圾回收机制会造成存储系统的卡顿。存在 HDFS 的数据计算时很方便，但是在数据恢复时就复杂了，要先把对应的数据通过 HDFS CLI 拷贝到本地才行，这对运维工程师来说来说是个噩梦。

自有机房中多机互备

优点：备份在本机文件系统上，可以使用全套的 Linux 工具集，文件备份、恢复都很方便。另外还能充分利用本地磁盘空间，极大的节约成本。

缺点：机器多了以后，所有备份不在一起，对于管理和恢复是个麻烦事。另外数据安全要依赖 RAID 方案，一旦 RAID 卡损坏，数据就有丢失风险。

公有云上的云硬盘、NAS

优点：这类存储方案通常基于 NFS 协议访问，如果某台机器需要恢复数据，可以直接挂载（要求在一个 VPC 内），省去了拷贝过程。

缺点：大多有单点问题，另外很多云硬盘容量上限不大，如果你的数据量大，就需要频繁创建新盘，管理很麻烦。

公有云上的对象存储

优点：存储容量弹性扩展，按需付费，价格便宜，数据安全可靠。

缺点：存取都需要通过专用的 SDK 或 API ，没有真正的目录结构，不支持改名。很多系统不支持直接存取对象存储，数据恢复时需要先下载到本地，当数据量很大时会耽误紧急数据恢复的时间。另外，对象存储缺乏各种一致性保证，会带来难以预期的困扰。

公有云 VM 上挂载本地磁盘（强烈不推荐）

虚拟主机上的本地磁盘不保证数据安全，在 VM 重启、迁移时数据可能会丢失，通常是用来存储临时数据，强烈不建议用本地盘做备份。

总的来说，这 5 种「本地备份」方案本身各有优劣，在考虑到基于「本地备份」进行「异地备份」时候，方案 3 和方案 4 稍好，但是在实施「异地备份」时也各自的问题。方案 3 中，无论使用公有云的 NFS 存储还是基于云硬盘自建 NFS，因为协议不支持传输加密，跨公网直接挂载很不安全，需要再搭配 VPN 或者其他网关来解决。方案 4 需要额外学习所选择的公有云的 API 和 SDK。如果要换云平台，API 和 SDK 还得重新学一遍。

在设计异地备份方案时，还得考虑因备份的存储位置不在同一个高速内网内时带来的传输问题，传输会比较慢而且不稳定，还容易被窃听。如果存储系统不支持从公网直接访问（比如 HDFS 和 NAS 等），还需要设计专线或者 VPN 来连通。

我们针对这个问题很多团队的做过交流，只有少数团队实施了异地备份。他们的实施办法，大多是设定一个定期任务，使用 rsync 将本地备份的数据全量异步复制到另外一个 POSIX 兼容的存储系统中。

这种方式非常容易实施，但对存储系统有一定的要求：

兼容 POSIX ，没有额外的学习成本，方便紧急情况下做数据恢复；

配置简单，维护简单。工作中 99% 的时间，我们不需要和备份系统打交道，所以最理想的情况是不用维护又非常稳定可靠；

适用于多个公有云 / 区域，不被某个云绑定。可以根据业务的具体需求有更多的选择；

最重要的是稳定、可靠、安全，价格便宜当然更加分了。

我们在设计 JuiceFS （ 官网地址：juicefs.io ）时，充分考虑到上了上面几点，希望为异地备份提供更好的选择。简单来说，它既可以像云硬盘一样挂载到虚拟机上，又同时拥有对象存储的弹性扩容和便宜的价格。方便实用，灵活且门槛低，价格对比同类其它方案，也相当有竞争力（以单机的云硬盘的价格得到比 NAS 还好的服务）。

作者介绍

苏锐，TGO 鲲鹏会会员，Juicedata , Inc 联合创始人。2017 年联合创始 JuiceFS 分布式 POSIX 存储服务（ 官网地址：juicefs.io ），在 beta 版本阶段就获得十余个中美两地优秀互联网企业客户。