数据备份的烦恼:我如何用免费方案打造个人3-2-1备份策略

行业领袖访谈 区块链技术 去中心化金融 (DeFi) 新闻

数据备份这件事,几乎每个追求数字生活的人都绕不开,却又几乎每个人都觉得苦不堪言。市面上的备份方案要么收费高昂,要么体验糟糕,要么就是在你最需要的时候掉链子。我决定自己动手,用免费工具搭建一套满足3-2-1备份原则的个人存储方案。这个过程充满了折腾和妥协,但最终让我对数据管理有了更深的理解。 首先要说的是3-2-1备份原则,这是业界公认的备份黄金法则。简单来说,就是你需要保留三份数据副本,存储在两种不同的介质上,其中至少有一份存放在异地。

对于个人用户而言,这意味着需要一个实时工作的同步层、一个本地硬盘备份、以及一个云端存储方案。这三者缺一不可,共同构成数据安全的防线。我最初就是抱着这个目标开始规划和实施的。 在实际操作中,我发现最理想的状态是能够在所有设备间无缝同步文件,包括我的两台迷你主机、笔记本电脑、手机和平板。这些设备的使用场景各不相同,存储容量和性能差异也很大,因此需要针对每个设备制定相应的策略。我的主力机是一台Minisforum X1迷你主机,所有重要文件都存放在主目录下的Sync文件夹中,这个文件夹就是我所有需要同步的内容的核心。

Sync文件夹通过Syncthing与另一台作为NAS使用的GMKtec M3迷你主机保持同步。M3这台机器基本常年开机,我主要通过SSH或Tailscale远程访问它。这样的架构确保了两台主机之间的文件一致性,任何一台机器上的改动都会实时同步到另一台。 笔记本电脑的处理方式稍有不同。虽然我主要使用Linux系统,但这台联想笔记本安装的是Windows系统,安装Syncthing的过程比想象中顺利,这让我颇为意外。Syncthing的同步机制有一个关键特点需要特别注意,它本质上是同步工具而非备份工具。

每个设备本地都保存着文件的副本,但它们之间是点对点同步的关系。如果某一台设备上的文件损坏或被误修改,这个错误也会被推送到其他设备上,导致所有副本同时损坏。因此,从严格意义上说,Syncthing建立的同步网络只算作一层存储,而不是备份。这个认知非常重要,它帮助我理解了为什么还需要额外的备份层。 移动端的情况则复杂得多。手机只有128GB存储空间,根本无法容纳我所有的同步文件。

虽然Sync文件夹实际上只有12GB大小,但对于手机来说仍然是个负担。我选择采用不同的策略来解决这个问题。我的M3迷你主机上运行着Tailscale服务,手机通过Tailscale连接到主机,然后使用Runestone应用直接在手机上浏览和访问远程文件。这种方式的缺点是需要保持Tailscale连接才能访问文件,但好处是手机本地不需要存储任何数据,对于存储空间有限的设备来说这是个不错的折中方案。 平板电脑的处理让我花了不少心思。原本以为Android系统的开放性会让这件事变得简单,事实证明我错了。

iOS虽然生态封闭,但至少工具有保障。Android这边没有找到类似Runestone的完善解决方案,只能采用一个比较丑陋但暂时可用的方案。我通过Tailscale连接后,使用Total Commander文件管理器配合其LAN扩展来访问远程文件,然后用Acode编辑器来修改文本文件。这种方案的局限性很明显,Total Commander无法创建新文件,只能复制现有文件后修改。虽然不够优雅,但在找到更好的替代方案之前,这套组合拳能够基本满足需求。 从这些折腾中我得出了几个有趣的结论。

Tailscale才是真正的幕后英雄,它解决了远程访问的各种痛点。Syncthing作为同步工具表现出色,稳定性和易用性都令人满意。iOS的封闭生态虽然限制多,但在某些方面反而提供了更一致的体验。Android系统的碎片化问题确实给跨设备协作带来了不少麻烦。 第二层是本地硬盘备份。这一层的设计相对直接,就是定期将Sync文件夹备份到一块移动硬盘上。

我选择使用restic作为备份工具,它的压缩和去重能力非常出色,12GB的原始数据可以被压缩到6GB左右,而且支持加密,功能设计非常合理。备份脚本通过systemd定时服务设置为每周日晚自动执行。restic的工作方式是将文件打包成仓库格式,每次备份只增量保存变化的部分,这使得后续备份速度很快,存储空间利用率也很高。第一次恢复数据时,解压过程比预想的要久一些,但考虑到压缩率,这个时间成本是可以接受的。 硬盘的文件系统选择也值得一说。我的移动硬盘默认格式是FAT32,这导致了一个有趣的现象,明明只移动了12GB的数据,但传输速度却慢得像在复制整个Netflix资料库。

经过研究才发现,FAT32在处理大量小文件时效率很低。如果想使用更高效的ext4文件系统,在需要兼容Windows的场景下又会有麻烦。exFAT是个折中选择,性能比FAT32好但仍不如ext4。权衡再三后,我选择了继续使用FAT32,因为主要的使用场景并不需要频繁在Windows和Linux之间交换数据,兼容性对我来说不是首要考虑。 第三层是云端存储,这也是最让我头疼的部分。既然不想付费订阅,免费的云存储选项就成了必选项。

Google Drive提供15GB免费空间,看起来是个不错的起点。但问题在于Gmail也占用这个配额,为了腾出足够空间,我花了些时间清理不需要的邮件。最终腾出了10GB以上的空间用于备份。 照片的处理方式稍有不同。我原本使用iPhone原生 Photos应用配合Google Photos进行备份,这种方案在我愿意付费的时期运行良好。现在想要迁移到自建的备份体系中,但跨平台的照片管理比文档同步要复杂得多。

我采用的方案是使用PhotoSync应用将手机照片同步到Sync文件夹中的Photos子文件夹,这个子文件夹会通过Syncthing同步到所有设备,并通过restic备份到硬盘和Google Drive。PhotoSync的同步过程需要手动触发,这是个小缺陷,但考虑到我对照片管理的需求并不频繁,这个方案暂时可以接受。 将Google Drive挂载到M3上并用restic备份的过程并不顺利。传输速度很慢,而且经常因为请求频率限制而中断。我尝试将Sync文件夹拆分成更小的子文件夹分别备份,但仍然效率低下。最终我放弃使用restic,转而采用更简单粗暴的方法:用rclone将Sync文件夹压缩后直接上传到Google Drive。

虽然这个方法不够优雅,但至少可行。每次需要恢复时,重新执行这个流程即可,第一次全量上传后,后续的增量更新会快很多。自动化这部分我暂时搁置了,因为整个过程太折腾,手动执行反而更可控。 除了主要的Sync文件夹,还有一些其他重要的数据需要妥善保护。dotfiles即配置文件对于长期使用的系统来说至关重要。想象一下丢失了花了很多时间优化的Neovim配置,那将是多么痛苦的体验。

我选择使用chezmoi来管理这些配置文件,它的设计简洁高效,支持将配置推送到GitHub托管。这种方式不仅实现了备份,还便于在多台设备间同步配置。 邮件的备份至今没有找到完美的解决方案。邮件的格式和存储方式比较特殊,没有现成的工具能够简单地将其纳入备份体系。直接放入Sync文件夹会导致备份到Google Drive,这对于隐私来说不是个好选择。这个问题只能留待以后探索。

操作系统层面的保护也很重要。作为Arch Linux用户,我清楚系统的脆弱性。一次更新可能就会导致系统无法启动。Timeshift是Arch生态中常用的系统快照工具,它类似于Windows的系统还原点或macOS的时间机器,可以快速将系统恢复到之前的状态。我已经完成了基本配置,虽然还没有实际需要使用它的时候,但有备无患总是好的。 整个备份方案的构建过程中,有些工具表现出色,有些则不得不做出妥协。

Syncthing在设备间同步方面几乎完美,restic的备份压缩能力令人印象深刻,Tailscale解决了远程访问的大问题。但同时,云端备份的各种限制、Windows系统的兼容性、跨平台工具的匮乏,这些都让人不断感叹技术世界的不完美。 这套系统目前运行基本稳定,但某些环节仍然比较脆弱。同步层相对可靠,硬盘备份有定时任务保障,云端备份则需要手动触发。如果遇到需要使用云端副本的紧急情况,可能丢失最近几周的更改。但考虑到不想在这个事情上投入更多精力,这个风险在可接受范围内。

也许随着时间推移,我会进一步完善某些环节,或者干脆推到重来,谁知道呢。 回顾整个过程,我最大的感受是数据备份没有完美的解决方案。每个选择都是权衡的结果,每个工具都有其局限性。Syncthing提供了便利但不是真正的备份,restic强大但配置有门槛,Tailscale解决了网络问题但增加了复杂度,Google Drive免费但处处受限。这些年来,我被Google One的订阅服务坑过,不想再为查看自己的文件付费。这种对数据自主权的追求,驱动着我不断折腾和优化自己的备份方案。

对于想要建立自己备份系统的人,我的建议是先明确自己的需求。备份策略没有标准答案,关键是找到适合自己的方案。如果你不介意付费,专业的备份服务会省心很多。如果你想像我一样追求免费和自主,就需要投入时间学习和调试。12GB的数据量对于备份来说其实不大,真正的挑战在于建立可靠的流程和养成定期检查的习惯。数据安全是一场持久战,工具和方法只是起点,持之以恒的维护才是关键。

。