最好的备份，是没有需要备份的东西

2024 这一年，我把自己的博客弄丢了两次。

一次丢的是图，一次丢的是数据库里的字。两次的现场都很狼狈，事后复盘却尴尬地指向同一个原因——根本不是手滑，也不是运气差。这篇就记一下这两次翻车，以及它逼我想明白的一件事：我一直在想着怎么把博客备份得更勤，但真正该做的，是让它没有需要备份的东西。

第一次：一个叫「学术垃圾」的桶

三月那次，是我自己亲手删的。

当时在清腾讯云的 COS，看到一个桶叫 academic-trash——这名字是我当年自嘲「学术垃圾」随手起的。我看着这名字，心想：垃圾嘛，留着干嘛。一键清空，删得干干净净，还挺有成就感。

邪门的地方在这儿：删完我打开博客，图全都在，一切正常。我就以为删对了。

过了几天再看，图片集体 404。

我排查了半天才回过神：那是博客的图床桶。删的当下没事，是因为 CDN 边缘节点还缓存着旧图——源站早被我抹了，缓存却还在替我撑着场面。等那批缓存陆续过期，回源一看源站空空如也，才一张张变成 404。

那次的教训我当时记成了一句很表面的话：别给重要的东西起一个像垃圾的名字。 现在看，这只是症状，不是病根。

第二次：到期的数据库

八月那次更惨，因为这回是真把数据丢了，而且没法甩锅给「名字起得不好」。

腾讯云学生套餐里那个 MySQL 到期了。系统提前好几次提醒我续费，我每次都很淡定地想：「反正有备份，过期前导出一份就完事了。」

然后我就忘了。

等想起来的时候，库已经被回收，整个没了。WordPress 那些文章正文、评论、设置，全在那个库里。万幸我之前往 360 云盘传过一份旧备份，不全，但博客好歹没有整个蒸发——靠一份过期的存档把自己捞了回来。

我盯着那句「反正有备份」看了很久。问题就出在这句话上：它是一句承诺，承诺一个「未来的我」会去做导出。可我刚刚用事实证明了，那个未来的我并不靠谱。

两次其实是同一个错

把这两次摆在一起，共同点其实很刺眼。

一次是误删，一次是忘续费，看起来是两种毛病。但它们丢的是同一类东西：我的博客把价值散在了一堆「我管不住」的地方——一个云上的桶、一个按月续费的库。这些东西的存活，依赖「我记得去维护它」。

只要存活依赖「我记得」，丢失就不是会不会的问题，只是早晚的问题。

flowchart TD
  W["WordPress 站点"] --> DB["MySQL 数据库<br/>(正文/评论)"]
  W --> COS["COS 图床桶<br/>(图片)"]
  W --> SRV["按月续费的服务器"]
  DB -.->|忘了续费 → 回收| X1["💀 八月丢库"]
  COS -.->|名字像垃圾 → 误删| X2["💀 三月丢图"]

每一个「方块」都是一个会过期、会被误删、会忘记导出的点。我维护得越久，踩中其中一个的概率就越接近 1。这不是运气问题，是结构问题。

备份不是答案

翻完车，我的第一反应当然是：那我以后好好备份不就行了。设个定时任务，每周导出，多存几个地方。

想了想，我把这个念头按了下去。

因为备份对抗的是事故——硬盘坏了、机房着火、误操作。它对抗不了惰性。而我这两次，根上都是惰性：我不是没条件备份，是我不会持续地去做这件事。给一个「不会坚持备份的人」加一套「需要坚持执行的备份方案」，等于没加。

这句话才是这两次翻车真正换来的东西。

把博客变成「无状态」

想通这点，方向就很清楚了：把博客从一个「有状态的应用」，改成一堆「没状态的文件」。

我搬到了 Hexo。整套东西的形状变成这样：

一篇文章，就是一个 .md 文件；
整个博客，就是一个 Git 仓库；
git push 到 GitHub，CI 把它编译成纯静态 HTML 托管出去。

# 写完一篇 = 三行命令，没有后台，没有数据库
git add source/_posts/new-post.md
git commit -m "新文章"
git push        # 剩下的交给 CI 构建 + 部署

对照着两次翻车的根，逐条看：

	有状态（WordPress）	无状态（静态 + Git）
正文存哪	MySQL 数据库	仓库里的 `.md` 文本
副本数	1 份（就那个库）	本地 + GitHub + 每台 clone 过的机器
误删了	看运气有没有备份	`git` 历史里翻得回来
会过期吗	续费断了就回收	文本文件丢哪都行
图片	单独一个云桶	也进仓库 / 进版本管理

最关键的是「副本数」那行。内容是纯文本之后，它天然就有无数份：我本地一份、GitHub 一份、我每台 clone 过它的电脑上各一份。我不需要「记得备份」，因为日常写作这个动作本身，就在不停地制造副本。可靠性不再挂在我的自律上，而是长在了工作流里。

顺手，我把域名也换成了现在的 yenharvey.com——丢了两次之后，索性当成一次重起炉灶。

代价：它只能是「只读」的

当然，静态化不是白拿的，得诚实讲代价。

静态站没有后端，意味着那些动态功能全没了：评论、私信、后台管理、按用户实时生成的页面——这些都依赖一个活着的服务器和数据库，而我刚把它们连根拔了。静态站本质上是「只读」的。

我犹豫的点也在这儿。但盘下来发现：博客对我来说，需求其实就一句话——我写，别人读。真正需要私信、需要实时交互的是 ACGHub 那种社区，博客不是。我之前那套 WordPress 的复杂度，一大半是为我用不上的功能准备的，顺带还赔上了「会丢」的风险。

把不需要的复杂度删掉，换来「丢不了」，这笔账我算得很乐意。

后来

这套「内容即文件、站即仓库」的想法，我后来一直没再变过。

2026 年我又折腾了一轮，把 Hexo 换成了 SvelteKit（那是另一篇的事）。技术栈换了，渲染方式换了，但最里面那层内核一点没动：博客不该有需要我亲手去守护的状态。 文章还是 .md，站还是一个 push 上去的仓库。

回头看 2024 那两次翻车，丢东西的时候是真肉疼。但要不是被删得这么干净，我大概还会在「下次一定好好备份」的自我安慰里再待上好几年。它逼我承认了一件事：靠谱的系统，不是建立在「我会记得」之上的——而是让我不记得也不会出事。