从一次误删说起：我给个人项目做的三份备份与一次恢复演练

上周三晚上，我在清理一台旧笔记本的磁盘时，差点把一个跟了两年的个人项目删掉。那是一个用 Node.js 写的读书笔记小工具，前端是静态页面，后端只有一个 SQLite 文件，数据不大，只有 86 MB，但里面是我从 2024 年开始陆续记的 1400 多条笔记和 300 多张配图。命令敲下去之前，我习惯性地先看了一眼路径，才发现自己把项目目录和一个同名的临时目录搞混了。那一刻我没有庆幸太久，反而意识到一个问题：如果那天真的删错了，我能不能在半小时内把它完整找回来？答案让我不太满意：本地只有一个一周前的旧压缩包，云盘里还有一份更旧的，数据库的最新一周记录根本不在里面。

这件事之后，我给自己定了一条规则：备份不能只看有没有，而要看能不能恢复、恢复要花多久、恢复出来的东西对不对。于是我把备份拆成了三份，放在三个不同的地方。第一份在项目所在的电脑上，每天凌晨 1 点用定时任务打一个带日期的压缩包，保留最近 7 天，方便随手找回误删的文件。第二份在对象存储里，每周日凌晨把当周的最新压缩包上传一次，保留最近 4 周，防的是电脑本身坏掉或者被盗。第三份最土也最关键：每个月第一天，我把压缩包拷到一块 500 GB 的移动硬盘上，拷完就拔掉离线存放，防的是勒索软件和云端账号出问题。三份备份里，至少有一份是离线的，这一点我现在看得很重。

光有文件还不够，我在备份脚本里加了两道校验。第一道是压缩完成后立刻算 SHA256，把哈希值写进同目录的一个文本文件里，下次恢复前先比对，哈希对不上就直接报警，不再往下走。第二道是每周随机抽一天的备份做解压测试，只解压不覆盖，检查目录结构和文件数量是不是和源目录对得上。最开始我嫌这一步麻烦，觉得压缩成功就等于备份成功，后来一次演练打了我的脸：一个压缩包因为磁盘空间不足只写了一半，解压到一半就报错，如果不是演练，我可能要到真正需要恢复的那天才发现。

恢复演练我定在每个月最后一个周六，流程固定在 20 分钟以内。10 月的演练我特意换了一台电脑：先从对象存储下载最近一周的压缩包，核对哈希，然后解压到一个全新的空目录，再用 SQLite 的完整性检查命令验证数据库，最后启动服务看首页和搜索能不能正常打开。整个过程用了 11 分钟，数据一条没少，但还是暴露了两个问题。第一个是环境变量文件 .env 不在备份里，因为我当初把它写进了排除列表，恢复后服务起不来，只能临时从密码管理器里找回。第二个是定时任务里的绝对路径写的是旧电脑的用户名，新电脑上跑不起来。演练之后，我把 .env 单独加密后放进离线硬盘的备份，并把脚本里的路径改成了相对路径加一个可配置的根目录变量。