家庭数据备份方案

自从大二装国产 Linux 误删了硬盘中积累了多年的照片，我对数据的存储和备份有了敬畏之心，这可能也是我后来投身存储领域的潜在动因吧。

于我们家庭而言，照片视频是最宝贵的数字资产。从 2005 年至今，我们一直会比较认真的归档每个月的照片，目前累计 800GB 左右。

昨天下午江苏盐城海域发生了 5.0 级地震，上海有很明显的震感，虽然的确如网上所说，大家都觉得是自己疲劳过度导致的眩晕，但地震过后，我不时的会联想到地震毁掉了 NAS，就是那个存有 800GB 数据的服务器。

其实家庭相册并不是只有 NAS 里这一份，我和老婆真的很担心它发生意外，所以在很久很久以前，老婆用 USB2.0 的移动硬盘做过离线备份，硬盘放在苏州我父母的家里。我还额外用一个 1TB 的硬盘对它做了另外一个离线备份，会定期的接到 NAS 上同步最新的数据。但这个 1TB 的盘也放在上海家里，它只是 NAS 的一个灾备。保险起见，从前年开始，我开始尝试用各种工具把数据备份上云，阿里云 OSS，腾讯云 COS、Backblaze B2 都用过，备份工具也换过很多种 Duplicati、Restic、Rclone，目前的云上副本在腾讯云的深度归档存储，使用 Rclone 的加密备份功能。

Rclone 是神器，功能简单且强大，但是它更适合做数据同步，让本地和云上保持数据一致，而像我的这种定期存储数据到云上的深度归档存储还是有些问题。深度归档存储的特点是数据一旦存入，就要收取 3～6 个月的存储费用，而且所有数据必须先解冻才能读取，但文件元数据比如文件名、大小、创建和修改时间这些信息是可以实时读取的，只不过读取请求要计费。

初次使用 rclone 备份到深度归档存储是不会有问题的，但文件发生了变化需要二次同步的时候问题就来了，rclone 需要遍历云上已经存储的文件，从而确保只上传新增的文件，文件规模少的话不要紧，但要遍历几十万的文件，会产生一定的 API 请求费用不说，主要是会花费很多时间。随着同步的次数增多，对数据存储的可靠性就越会存疑。其实这些也都不算什么，最可怕的是一旦 NAS 的数据源发生了变化，比如我之前尝试过把照片从 NAS 迁移到本地自建的 minio，文件从一台机器复制到另一台机器，元数据就发生了变化。这时候再用 rclone 同步就会灾难性的发生所有数据重新上传到深度归档的情况。

深度归档存储的一个很要命的问题是，存入一个文件，在没有达到约定的存储时长时，你重新上传相同的文件覆盖它，平台会认为这是两个文件，对象存储的覆盖操作本质上是删除旧文件上传新文件。旧文件的删除需要收取剩余承诺时间所需的存储费用，新文件则需要从头开始计算文件的承诺存储时长。本地的小小变化，可能造成云上大量的开销和浪费。

总之，rclone + cos 深度归档存储的方案实践证明是不理想的。等腾讯云上资源包到期，就准备把它清理掉了。

接下来可能会尝试 restic + Scaleway 对象存储。Scaleway 的对象存储同时提供标准存储和 C14 归档存储，数据可以在标准和归档之间免费转换，而且没有请求费用。使用 restic 上传数据，然后用 rclone 或 s3cmd 将 data 目录批量转换成 Glacier 归档类型，因为没有数据解冻的费用，灾难恢复的时候付出的代价可能是最小的。当然，这也只是设想，具体的使用体验还要等用过再去评断。

经过了简单的测试，发现中国移动宽带访问 Scaleway 对象存储的速度不太理想，分别测试了法国和荷兰两个数据中心，连接都不太稳定，上传和下载速度基本在几 kb/s 左右，这样看来可能它也不是我的理想选择。

目前已经开始用 restic 往 Backbalze B2 上备份数据了，比较让我意外的是上传和下载速度基本都能维持在 5～10 MB/s 左右。虽然相比 C14 归档存储的价格差了将近一倍，B2 很可能成为家庭数据的长期归档存储。

其实早前也用 B2 归档过这份重要数据，当时用的备份工具是 Duplicati，之后放弃也主要是 Duplicati 的原因。

Duplicati 是一个基于 PHP 开发的加密备份工具，支持着很广泛的云端存储。它的备份规则是把文件拆块压缩在固定大小的文件中（比如 50MB ），相对于大小不一的源文件，把它们打包压缩成固定大小的文件的最大优势就是可以节省对象存储的请求费用，也能提升文件的存储效率。

由于涉及到对源文件的拆块和二次打包，Duplicati 会在本地用 sqlite 数据库保存所有文件的元数据。对于我这 800G 左右的文件来说，印象中是产生了一个 10GB 左右的数据文件。众所周知，sqlite 并不擅长管理如此大规模的数据，所以在此后的使用过程中，经常会出现程序卡顿，任务不能正常执行等情况，似乎每次备份增量数据时，它验证本地的数据库，同时也不可避免地因为校验元数据而产生一些请求费用。

随着使用，对云端数据的完整性越来越没底，中途试过几次模拟灾难恢复，但效果都不太理想。一方面是 B2 当时的访问速度真的没有现在这么快，印象中之前上传速度还不错，下载文件几百 KB 到几 MB 每秒不等，连接还经常会受到干扰而中断。加之 Duplicati 处理 800G 左右数据所表现的那种“不堪重负”，不断的发生界面反应迟钝、操作无响应等情况，最终导致我决心放弃这套备份。

对于现在来说，B2 上这份不定期增量备份就是灾备，用它恢复数据的时候肯定就是本地这些七七八八的存储设备都挂掉的时候。当然，也可能连我也跟着一并挂掉了。所以我在创建这个备份的时候认真的记录着每一个操作细节，日后管理时也会遵循记录的规则和各种结构进行增量备份。需要确保家人只要找到一个懂技术的人，按图索骥就可以把数据从云端恢复到本地。