让 JuiceFS 帮你做好「异地备份」

Photo credit: Images by John ‘K’ / CC BY-NC-ND

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

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

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

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

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

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

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

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

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

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% 的公司能在缺乏灾难恢复计划的情况下幸存。

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

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

如何做异地备份？

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

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

1. 有两个或以上的数据中心，数据可以在不同数据中心之间互备；
2. 主业务系统在自己的（或者租用的）数据中心，备份数据在共有云上；
3. 主业务系统在公有云上，备份一个副本在另一个服务区（Region/Zone）；
4. 主业务系统在公有云上，备份一个副本在另一家公有云上；

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

如何用公有云实施异地备份？

异地备份的理想与现实

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

1. 自建分布式文件系统；
   1. 优点：大多选用 HDFS。它是 Hadoop 生态的默认存储方案，有 3 副本冗余的策略，还有机架感知特性，对大数据分析的支持也很友好。
   2. 缺点：HDFS 需要自己维护高可用的 Name Node 集群，容量规划和扩容工作也会占消耗运维团队资源。如果你的 HDFS 集群还肩负业务计算和数据备份需求，基于 JVM 的 Name Node 在高负载工作下垃圾回收机制会造成存储系统的卡顿。存在 HDFS 的数据计算时很方便，但是在数据恢复时就复杂了，要先把对应的数据通过 HDFS CLI 拷贝到本地才行，这对运维工程师来说来说是个噩梦。
2. 自有机房中多机互备：
   1. 优点：备份在本机文件系统上，可以使用全套的 Linux 工具集，文件备份、恢复都很方便。另外还能充分利用本地磁盘空间，极大的节约成本。
   2. 缺点：机器多了以后，所有备份不在一起，对于管理和恢复是个麻烦事。另外数据安全要依赖 RAID 方案，一旦 RAID 卡损坏，数据就有丢失风险。
3. 公有云上的云硬盘、NAS：
   1. 优点：这类存储方案通常基于 NFS 协议访问，如果某台机器需要恢复数据，可以直接挂载（要求在一个 VPC 内），省去了拷贝过程。
   2. 缺点：大多有单点问题，另外很多云硬盘容量上限不大，如果你的数据量大，就需要频繁创建新盘，管理很麻烦。
4. 公有云上的对象存储：
   1. 优点：存储容量弹性扩展，按需付费，价格便宜，数据安全可靠。
   2. 缺点：存取都需要通过专用的 SDK 或 API，没有真正的目录结构，不支持改名。很多系统不支持直接存取对象存储，数据恢复时需要先下载到本地，当数据量很大时会耽误紧急数据恢复的时间。另外，对象存储缺乏各种一致性保证，会带来难以预期的困扰。
5. 公有云 VM 上挂载本地磁盘（强烈不推荐）：虚拟主机上的本地磁盘不保证数据安全，在 VM 重启、迁移时数据可能会丢失，通常是用来存储临时数据，强烈不建议用本地盘做备份。

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

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

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

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

1. 兼容 POSIX，没有额外的学习成本，方便紧急情况下做数据恢复；
2. 配置简单，维护简单。工作中 99% 的时间，我们不需要和备份系统打交道，所以最理想的情况是不用维护又非常稳定可靠；
3. 适用于多个公有云/区域，不被某个云绑定。可以根据业务的具体需求有更多的选择；
4. 最重要的是稳定、可靠、安全，价格便宜当然更加分了；

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

如何用 JuiceFS 来做异地备份？

JuiceFS 是专为公有云而生的分布式 POSIX 文件系统，它将数据保存在你自己的公有云对象存储中，通过由我们维护的强一致高性能的元数据服务变成一个 POSIX 兼容的分布式文件系统。

无论你的主业务在自建机房还是公有云上，都可以利用 JuiceFS 来做异地备份。参照 JuiceFS 使用指南将 JuiceFS 挂载到你主机房或者所用的公有云主机上，然后使用 rsync 等工具将备份数据直接写入即可。JuiceFS 的传输都是加密的，并且会自动将大文件分块并行传输，即使通过不可靠的公网进行备份也可以获得很好的性能和体验。

如果你使用 JuiceFS 来直接存储数据或者做本地备份，它还有个更厉害的功能支持你轻松完成异地备份：复制（Replication），它会自动将写入的数据异步复制到指定的另一个对象存储中（可以是任意公有云和服务区）。假设你的主业务在 AWS 北京区，数据需要备份到 UCloud 广州区，只需要创建一个在 AWS 北京区的文件系统，再启用复制功能（并选择 UCloud 广州区），所有写入到 AWS S3 的数据（包括启用复制功能前）都会被自动复制到 UCloud 广州区的 UFile 中。当你需要在 UCloud 广州区进行数据恢复时，它会直接从 UFile 读取数据，速度快且不需要付流量费。

企业版 JuiceFS 的另一个大杀器是全球数据镜像，它可以帮你实现超远距离的近实时数据镜像（只读），比如从美国镜像到中国，或者反过来。相比上面说的数据复制功能，数据镜像还会建议元数据的只读镜像，以保证在超远距离的镜像数据也能获得很好的性能。我们在测试中发现，从 AWS 美东区同步到腾讯云上海区，元数据只有秒级延迟，绝大部分数据在 30 秒内完成同步，偶尔被某墙阻断加密连接导致数据同步滞后，客户端也会主动修复同步，保证数据的正确和一致访问（访问时会略慢）。目前数据镜像功能只开放给企业客户，感兴趣的同学可以联系我们了解更多技术细节。

我们相信，JuiceFS 是目前市场上能找到的最好的数据备份方案，没有之一，因为它：

1. 支持全球 13 个公有云平台近 100 个服务区间自动复制，支持平台还在陆续增加；
2. 保证数据一致性，和 99.95% 的高可用性；
3. 传输加密，企业版支持存储加密；
4. 兼容 POSIX，JuiceFS 可以通过 FUSE 挂载到 VM 上，使用体验和本地磁盘一致；
5. Serverless，完全由我们和公有云维护，客户无需维护；
6. 提供丰富的监控数据，可集成在客户自己的监控系统中；
7. 复制（Replication）功能可帮你实现轻松的跨云跨服务区备份或者迁移；
8. 回收站机制，有效防止误删除，可以自己设置回收站保存时间；
9. 节省大量成本。综合考虑人力和时间成本，比其他方案节省 50% 至 80%。

对了，如果你是 Linux 和 Mac 的个人用户，JuiceFS 可以直接挂载到你自己的电脑上，上面的方法同样适用于备份你的个人数据，我们还提供了1TiB 永久免费容量（对象存储可能不是免费的）。

像这样的使用指南文章，我们会快马加鞭的出更多，也希望大家大开脑洞，想出更多 JuiceFS的好玩用法，或者投稿 success@juicedata.io 给我们，或者通过 JuiceFS 网站 右下角的客服在线聊天窗口告诉我们。