我的双端备份策略：只同步"纸"，不同步"货"

昨晚差点干了件蠢事：把两本电子书往服务器上推。

推之前我停了一下——那台阿里云的盘本来就紧，两本书 30M 不算多，但按这个逻辑走下去，下一步就是电影、再下一步是生图原图，一年后我得为"备份"再买一块盘。

于是给自己定了条规矩，一句话：只同步"纸"，不同步"货"。

先说清楚我家这两头是什么

我手机上跑着一套 Hermes，云服务器上也跑着一套。两边各有一个「任务处理」文件夹，长得很像：技能、手册、清单、定时任务、操作记录，都是同一套目录名。

以前我的理解是"备份就是把两边搞得一样"。结果特别难受：改了一头忘了另一头；两边都改过就开始互相覆盖；过半年打开一看，同一个文档有五个版本，标题里带日期的那个反而不是最新的。

真正的问题不在同步工具，在于我没分清什么东西该走。

纸和货的分界线

我现在的分法很土：

纸——清单、手册、规范、检查标准、技能。特点是小，几十 KB，几秒钟传完，而且它回答的是"有什么、在哪、怎么用"。

货——电子书、影视文件、音频、图片、压缩包。特点是几百兆起，回答的是"东西本身"。

纸默认两头都留。我在手机上一写完，就同步到服务器同一路径，目录没有就自动建。不用问、不用确认，这是默认动作。

货永远只在手机。服务器上不落地，一个字节都不放。

这条一划清，很多纠结自动消失了：服务器不会因为我要备份而被塞满，手机丢了货确实没了——但清单上写着它在哪个网盘、什么规格、多大、怎么重新拿，重下比恢复快得多。

清单要写到"多有用"的程度

既然货不同步了，清单就得扛起来。我给自己加了个要求：清单不能只写"有"或"没有"。

今天找一部动画，我拿聚合接口扫了 38 条候选，逐条去取分享凭证、列目录。结果只有 3 段是有效的：1 到 75 集、136 到 163 集、还有最新的 159 到 163。中间 60 集这一段没有可用的，其余候选点开基本都是分享已取消或已失效。

这个"缺哪一段"必须写进清单。因为下次我会问同样的问题，而一年后的我不会记得今天试过什么。只写"有资源"，下次还得重扫一遍。

所以清单里现在有这几样：链接、判定（有效/弱验证/失效）、规格（4K 还是 1080p）、体积、目录结构、按设备挑版本的建话、以及缺口。

技能也分两种，但两种都要留

技能比文档麻烦一点，因为有些技能天生带平台属性。

我手机上有 184 个技能（不算归档），服务器上 137 个。比完发现两边各有独占的：手机上有 Termux 专属的、安卓存储清理的、快剪的；服务器上有 Docker、防火墙、面板运维的。

做法是：通用的 74 个直接推过去，两边都有 175 个，逐个核对文件内容一致。手机专属那 9 个不装到服务器上——装了也用不上，还会让那边的助手每次启动都背着一堆无关条目。

但打包存了一份档，44 KB，扔在服务器的任务处理目录里。占位小到可以忽略，真哪天要抄一个思路，解压就有。

校验这件事，比想象中重要

同步最烦的不是传，是"到底哪边是新的"。

我现在的规矩粗暴但有效：md5 不一致，就等于没同步。传完当场比一次，一样就打勾，不一样就重传。不靠时间戳、不靠文件名、不靠"我记得我改过"。

今天把整个换机迁移包（426M）传到对象存储，也用了同一招：让服务器从桶里把整包拉回来算一遍 md5，跟本地对上才算完。上传工具说"完成"不算，得有个能验的数。

最后

这套规矩没技术含量，无非是把"该走什么、走完怎么验"写下来。

但省下的是两样东西：服务器上几个 G 的空间，和每次打开文档前那句"这版是不是最新的"。

写文档的时候多写一行，恢复的时候少熬半天。这话我以前听过很多次，今天才真的照做。