个人重要数据自动化冷备份解决方案

背景

由于我使用自己的部署 GitLab，而仅仅使用一台从 ESXi 上虚拟化的 VM——我相信许多人都是这样的，甚至有些人会使用树莓派去搭建自己的 GitLab。但是这样做可能会产生数据安全问题，尤其是当存储意外损坏。我整理了一下需求，大概有以下几点：

1. 自动化，无需人工干预；
2. 冷备份，存储服务器无需持续开机，省电也省磁盘寿命；
3. 可观测，即备份结束后主动推送结果；
4. 易回滚，每次备份自动做一个快照，可以回滚到任意时间点，也可以直接查看数据。

架构

我采用了 TrueNAS 作为备份服务器，在需要备份的服务器上加载了 TrueNAS 的证书以使用基于 SSH 的 rsync 进行拉取。我单独编写了一个程序，首先在局域网里通过 WoL 唤醒 TrueNAS，再用 SSH 连接上 TrueNAS 执行 rsync，结束后调用 TrueNAS 的 API 打一个 snapshot，完成后自动关机，最后通过飞书的 webhook 推送备份结果。

需要注意的是，我备份了 /var/lib/docker 和 /home/ubuntu，原因是我的服务器都采用 Docker 管理各种服务，因此挂载点无非是 /var/lib/docker/volumes 或在 /home/ubuntu/<deployment>/data，而备份整个 Docker 文件夹的潜在目的是把镜像也备份一下，防止到时候因为找不到正确版本的镜像而被迫想办法对数据升级以匹配新的镜像。

另外，所有的 Docker 启动指令也应备份下来，这样恢复的工作流就简单许多，甚至可以启一台新的 VM，安装 Docker 后，只恢复 /var/lib/docker/volumes 和 /home/ubuntu，然后直接用原来的命令去启动新的容器即可。

讨论与展望

折腾这些的意义？

任何电子零件都是有寿命的，我们的确可以在其寿命耗尽前定期更换，但却不能预测它的意外损坏。

高可用 vs 备份？

许多人会采用 RAID 来避免因存储单点损坏造成的数据丢失，但我想说这和做备份并不冲突。

一致性问题

单纯的使用 rsync 可能会出现一致性问题，容易造成一些问题，这是当前方案的缺陷。由于在备份的同时服务器极有可能还在写入，所以最好的办法是在备份前先把 Docker 服务停掉，虽然会造成备份期间业务不可用，但确保了一致性。要想理解如何产生一致性问题并不难，因为 ext4 文件系统不是写时复制（Copy On Write, COW）的，因此不能像 zfs 或者 btrfs 一样直接对某个时刻进行快照。当然对于 GitLab 和 Webdav 来说是低风险的，因为最重要的是 volumes 里的 Git 文件夹，这些的更新都不是很频繁，因此出现一致性问题的风险不大。

针对写时复制，它通过不修改原始数据块，而是将修改后的数据写入新的位置，从而确保文件在写入过程中始终处于一致状态，并能轻松创建数据快照和历史版本。由于 zfs 是写时复制的，我们在 TrueNAS 上创建的快照就具有一致性。

解决这个问题有两个思路，一个是把服务器或者备份更换成支持写时复制的文件系统，然后备份当前的镜像，还有一个方法是在备份前停止写入，例如加锁或者关闭服务。未来我解决了这个问题还会再写博文分享。