只有意外失去过数据才会意识到备份的重要性，之前经历过一些硬盘爆炸导致数据丢失的惨痛事故，所幸没有损失关键文件。重复的亏吃不得，于是就尝试着在已有的存储体系内增加了备份机制，效果良好。最近又微调了一下数据备份的方案，这里就稍微记录一下吧。
为了高速的进行照片预览和图片处理，我将 CaptureOne 的完整照片目录（Catalog）都保存在了我的 M1 MacBook 中。为了节约体积，我会在导入前用自己的脚本将所有的 ARW 文件转为 Adobe DNG 文件，单单是经过一轮 zip 也能省下不少空间。数据放在 Mac 里显然是高危操作，众所周知 T2 开始的 MacBook 一旦出现问题数据必然是灰飞烟灭，指望着这么一个一定会坏的东西尽可能晚点坏是不现实的，所以我会周期性的将我的 Catalog 通过 rsync 复制到我的 NAS 中。
至于 NAS，其实是一个很普通的 Debian Server，直通了三块 6TB 的 HGST Ultrastar HC310，全都格式化为 ext4 后用 GitHub: mergerfs 合并成了一个 18TB 的 union filesystem，并在其中创建若干目录来分类存放文件：
1
2
3
4
5
6
7
8
|
% mount
/dev/sdc1 on /media/HGST2 type ext4 (rw,relatime,data=ordered)
/dev/sdd1 on /media/HGST1 type ext4 (rw,relatime,data=ordered)
/dev/sde1 on /media/HGST0 type ext4 (rw,relatime,data=ordered)
0:1:2 on /srv/NAS type fuse.mergerfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other)
% ls /srv/NAS
ISCSI REDACTED NTZYZ PUBLIC TIME_MACHINE
|
很显然这个 总容量 = SUM(硬盘容量) 的存储方案没有提供任何冗余，本质其实是和 RAID0 一样。不过 mergerfs 相较于 RAID0 仍然有一点点优势：用 mergerfs 时，所有的下层文件系统和磁盘都是独立的 ext4，因此可以很便捷的扩容；另外，当任何一个硬盘故障离线时，也不至于导致所有数据都灰飞烟灭，在有合理备份的情况下，只需要恢复损坏磁盘中的数据即可。代价也不算太高，损失一点性能罢了，这种个人用途的文件存储其实也没有多少性能要求（何况家里还只是 1GbE 呢）。
那么问题就在这个合理备份了：选择用 mergerfs 而不是 RAID 目的就是降低成本，在家里弄弄个机架塞上 4U 的机器再弄一大堆 HDD 成本太高还太吵，而且 RAID 是冗余不是备份，万一手滑/内网中了勒索病毒数据一样遭殃。而自己搭建异地备份的话成本也没有低多少，依然需要在一个地方塞上若干高速旋转的硬盘。所以最后将目光转向了云服务商提供的类似对象存储之类的方案。
经过调研之后，发现 Restic 这个工具完美的满足了我的诉求：
- 支持多种数据存储方案，包括自己的文件系统或者是 S3 之类的对象存储；
- 提供快照式的备份模式，相同目录的多次备份可以用快照查看历史版本；
- 支持增量备份，在同一目录多次备份中只上传差异；
- 支持加密，承载数据的云服务商无法感知我上传了啥；
寻找工具的问题解决了后就是找存到哪里了。一开始我看到 restic 可以通过 rclone 支持世纪互联的 OneDrive for Business，于是咬咬牙开了一年的 Office E3，毕竟 1500CNY/年的成本怎么算都比单独买阿里云/腾讯云的对象存储便宜（需要备份的数据大概有 1TB，用 S3 的话就要每个月 35USD 了）。用各种网盘的话成本会低很多，不用百度云的理由很简单，单纯的讨厌百度就是了；而剩下的那些服务里 OneDrive/Google Drive 在国内基本没法好好用。后来阿里云加入了网盘行列，提供了阿里云盘这么一个产品，掏钱的话大概可以用 168CNY 买到 8TB 的存储空间，同时也可以很方便的找到将阿里云盘桥接成 WebDAV 的工具，比如我用的是这个：GitHub: aliyundrive-webdav。而 Resitc 支持的 rclone 也支持 WebDAV 后端，这下整个流程就都满足了～
所有的依赖问题都解决之后，剩下的工作就只剩下将这一整套大礼包都部署到 NAS 了，整个过程并不麻烦，部署和启动 aliyundrive-webdav 好后用 rclone config 新增一个 remote，最后再用 restic init -r rclone:xxx:xxx 初始化仓库即可。后续在配合 systemd timer 和自己写的脚本就可以完成定时的增量备份了。当然不可避免的首次上传会很慢，后续则会好很多。
附一个首次上传的刺激现场，三天上传了 1.31TB 了已经，希望上海电信不要杀了我：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
|
ntzyz@nas-v2 ~ % vnstat -h
ens18 / hourly
hour rx | tx | total | avg. rate
------------------------+-------------+-------------+---------------
2023-02-14
15:00 606.69 MiB | 34.45 GiB | 35.04 GiB | 83.62 Mbit/s
16:00 610.81 MiB | 34.25 GiB | 34.85 GiB | 83.16 Mbit/s
17:00 623.61 MiB | 33.99 GiB | 34.60 GiB | 82.56 Mbit/s
18:00 566.85 MiB | 29.15 GiB | 29.70 GiB | 70.87 Mbit/s
19:00 7.76 GiB | 34.40 GiB | 42.16 GiB | 100.60 Mbit/s
20:00 58.64 GiB | 35.24 GiB | 93.88 GiB | 224.01 Mbit/s
21:00 43.52 GiB | 35.01 GiB | 78.52 GiB | 187.36 Mbit/s
22:00 38.33 GiB | 35.04 GiB | 73.37 GiB | 175.07 Mbit/s
23:00 576.09 MiB | 27.50 GiB | 28.06 GiB | 66.96 Mbit/s
2023-02-15
00:00 560.47 MiB | 26.72 GiB | 27.27 GiB | 65.06 Mbit/s
01:00 652.31 MiB | 31.49 GiB | 32.13 GiB | 76.66 Mbit/s
02:00 646.58 MiB | 32.78 GiB | 33.41 GiB | 79.73 Mbit/s
03:00 628.83 MiB | 31.41 GiB | 32.02 GiB | 76.41 Mbit/s
04:00 670.06 MiB | 33.76 GiB | 34.42 GiB | 82.12 Mbit/s
05:00 675.27 MiB | 34.27 GiB | 34.93 GiB | 83.34 Mbit/s
06:00 677.09 MiB | 34.08 GiB | 34.74 GiB | 82.90 Mbit/s
07:00 699.17 MiB | 33.83 GiB | 34.52 GiB | 82.36 Mbit/s
08:00 579.34 MiB | 26.45 GiB | 27.02 GiB | 64.46 Mbit/s
09:00 524.03 MiB | 23.60 GiB | 24.11 GiB | 57.54 Mbit/s
10:00 600.53 MiB | 29.05 GiB | 29.64 GiB | 70.73 Mbit/s
11:00 662.55 MiB | 32.28 GiB | 32.93 GiB | 78.58 Mbit/s
12:00 695.57 MiB | 33.62 GiB | 34.30 GiB | 81.83 Mbit/s
13:00 715.18 MiB | 33.52 GiB | 34.22 GiB | 81.64 Mbit/s
14:00 58.99 MiB | 2.78 GiB | 2.84 GiB | 81.31 Mbit/s
------------------------+-------------+-------------+---------------
|