Hi，大家好。这是一篇介绍 JuiceFS 如何做数据保护，实时恢复数据的文章。
从我的经历说起
说起数据保护，每个人可能都有自己的故事，先讲讲我的。多年以前，我大四临近毕业，经过三个月的实习，一个月的论文撰写，在最后收关时刻不知道为什么，论文的 Word 文件坏掉了 …… 当时的我还很傻很天真，没有任何备份，无奈之下凭着记忆在两天之内重新敲了一份出来，但质量肯定是打了折扣。
换到企业数据管理中，误操作和意外带来的数据损失也不少，一个多月前我们就帮客户解决了一次数据被勒索病毒污染的问题。我们想如果企业的海量数据也能有一个 macOS 那样的 TimeMachine 或者能像 Git 一样做版本管理，是不是可以很大程度上减少数据损失？
然后我们就把它做出来了，JuiceFS 实时数据保护，让你的数据瞬间回到任意时刻的状态。
首先介绍下什么是 JuiceFS？它是一个云原生的共享文件系统，支持 POSIX、HDFS、NFS 多种访问接口。在全球十多家云服务上都有全托管服务，是企业海量数据管理的理想选择。
接下来是一段视频，请看 JuiceFS 实时数据保护的功能演示 ~（请忽略主播的肤色，认真听功能演示，还有好听的 BGM）然后再给各位讲讲实现原理和使用场景。
技术原理
存储系统大多需要人工设定规则来创建快照作为备份，在两次快照之间的数据变化是无法找回的，这是一个数据安全风险。如果每次快照间隔时间长，可能会造成中间状态的数据丢失。如果间隔时间短，创建快照的开销会影响到系统性能，也会消耗大量空间。
JuiceFS 的数据实时保护不存在这个问题。首先，它是真正的实时保护，不需要人工设定任何规则，所有数据可以回到任意一次更新时的状态。
如果把数据恢复比作出行，快照的方式就是做公交车，一公里一站，到站下车后往往还要往前或往回走上一段路，如果刚好赶上大暴雨，这段路也够变成落汤鸡了。JuiceFS 的实时数据保护就是坐专车，门到门接送，精准上下车。
同时，JuiceFS 实时保存每一秒的状态，会影响性能么？这就要从实现原理讲起，分两个方面。
首先是元数据恢复能力。JuiceFS 是元数据与数据分离的架构设计，元数据服务使用 Raft 协议来保证高可用和一致性，对文件系统的所有修改操作都会以 Raft Log 的形式被保存下来，这个 Raft Log 类似于 MySQL 的 binlog，这样通过回放 Log 就可以让元数据停在任意时刻。
然后看数据恢复能力。JuiceFS 在数据持久化时会分成多个 block 保存。所有的数据修改操作都不会修改原来的数据块，而是创建新的，再通过元数据管理正确的映射关系。这样保证所有数据都是不可更改的，当恢复元数据后，只要对应的数据块没被删除，文件的数据也同样会恢复。类似于标记删除文件的回收站功能，实时数据保护是对数据块也采取了标记和延后删除的策略，这样就可以将整个文件系统的状态恢复到任意时刻。
那启用数据保护是不是会消耗很大空间？数据保护通常是为了应对突发风险，只需要有一定时间窗口的保护就够了（比如24小时），被标记删除的数据块在过来时间窗口后就会被删除，因此它的需要的存储空间只是一个保护时间窗口内被删除或者覆盖的数据量。
使用场景
依靠 JuiceFS 提供的实时数据保护能力，可以轻松应对以下两种风险：
第一个，勒索病毒。勒索病毒感染快，变异快，想做逆向修复大多无解，如果能在存储系统上做到数据保护是更安心的思路。JuiceFS 做数据实时保护也是因为一个客户的数据被勒索病毒感染，损失惨重。当时 JuiceFS 还不支持实时数据保护，我们利用元数据 Log 抢救了大部分数据（当时的救灾过程我们写了一篇博客记录技术原理）。这次经历之后，我们觉得应该用技术手段更彻底的保护数据。现在，如果 JuiceFS 中的数据被病毒感染，只要恢复到感染前的时间，把正确的数据内容拷贝出来即可。
第二个，删库跑路。这事不止出现过一次，每次出现后都有一波讨论如何在管理上杜绝？用管理方法解决通常是用增加流程、权限分离到多人等方法，降低风险的代价是牺牲效率。我们 JuiceFS 团队相信技术可以解决这个问题，也专门写过一篇文章来讲数据安全的保护体系建设。JuiceFS 实时数据保护在不增加任何使用负担的情况下，完全透明地把数据保护起来。因为 JuiceFS 在云上提供全托管服务，所以它的元数据客户是不可能接触到的，负责存储数据的对象存储需要开启多版本功能，这样即使直接把对象存储里的数据删掉，也一样可以恢复。
数据安全是每一位技术管理者的责任，能通过产品和技术完美实现数据保护，希望可以释放管理者的压力，同时减少流程，提升团队效率。JuiceFS 的实时数据保护就像是特效药，万一中招也能安然无恙。
与其他产品的比较
以公有云环境举例，常见存储产品有三种：云盘（块存储）、对象存储、网络文件系统。这三种产品都有多副本冗余，不用担心因为硬件损坏带来的数据丢失。
但是，硬件损坏之外的数据风险却容易被大家忽略。
先说云盘，有两种风险最容易被忽略：第一，云盘是在块设备上格式化一个单机文件系统，如果块设备出现少量数据错误，可能导致文件系统出现逻辑损坏，会造成整个文件系统里的数据丢失！第二，如果云盘遭到恶意破坏，因为单机文件系统的复杂性和覆盖写特性，恢复数据是非常困难的。而云盘的快照通常滞后很多，使用快照无法恢复新写入的数据。
再说对象存储，一些厂商的对象存储支持多版本功能，在重要数据的存储上强烈建议打开此功能，这样防止数据误写，即使是删除操作也可以延迟一定时间再物理删除，再结合 JuiceFS 数据实时保护，可以高枕无忧了。但有另外一方面要注意，一些备份数据要用于灾难恢复，比如数据库备份，如果保存在对象存储，使用时必须先下载，再解密、解压缩，没几小时是完不成的。如果保存在 JuiceFS，可以直接启动应用读取数据，即使拷贝出来使用也能快很多倍。
最后说说网络文件系统，常见产品有 HDFS，CephFS 等。比如 HDFS 的回收站是可以跳过的（JuiceFS 的回收站不可以被绕过），也很容易绕过权限检查。如果是自己搭建维护的服务，一旦这些服务器被入侵，可以从存储节点上直接删除，面对恶意破坏无能为力。如果使用全托管服务，通过隔离的环境可以为客户带来多一层保护。
使用方法
在网站控制台的回收站页面，提供了数据恢复的入口，
实时数据恢复的入口
之后选定想回溯到的具体时间（可以精确到秒，也可以联系我们帮忙定位到某个具体的更新操作），然后会创建出一个以 .snapshot 结尾的新文件系统，它就是你指定那个时刻的状态。
指定恢复时刻，创建出一个 .snapshot 结尾的文件系统
这个快照的使用跟普通 JuiceFS 文件系统的方法相同，里面的数据是只读的。挂载后，找到需要的数据可以拷贝回原文件系统中，也可以将它恢复到读写状态用来取代原来的文件系统实现回滚。
挂载好普通文件系统和 .snapshot 结尾的数据恢复文件系统
数据恢复方法讲完了。
目前公测阶段，我们统一设置为可恢复到过去 24 小时的任意时刻，未来会支持用户自定义。
我们已经为所有 JuiceFS 专业版和企业版客户开启了这个保护，但尚未向客户开放功能入口，如果你想体验一下，请联系我们。
