凌晨两点四十，手机响。我接起来之前还在做梦，梦里正吃泡面。

「库被清了，你们备份有吧？」客户声音很急。

有，我当时是这么想的。这套托管服务卖的时候就带备份，客户还加钱买了异地同步，合同里白纸黑字写着。我一边开电脑一边想，顶多恢复慢点，天亮之前能给人家弄好。

先看备份目录。最近一个全量是 4 月 12 号的，今天 7 月 19 号——三个月零七天，中间全是增量。我第一反应是策略被人改过，查了 crontab，没动过，一周一次全量，雷打不动。

那就拿 4 月 12 号那个全量恢复。工具跑了二十多分钟，报文件头校验不过。我以为是工具版本问题，换了个老版本，照样报错。又去拉异地那份，同步状态显示正常，拉下来一比对，大小不对，少了三百多兆。

这时候才正经去翻备份日志。翻了十来分钟，三个月前某一天，凌晨三点多，一行：

[2026-04-12 03:17:44] ERROR: write failed: No space left on device

磁盘满了，全量没写进去。但脚本没退出，错误也没往上抛，记完日志接着跑"成功"的下一次。我们的监控只看任务退出码，退出码是 0，监控界面三年都是绿的。日志只留三个月的，再早的早被轮转掉了，不然估计还能翻出更多。异地那份大小对不上，也是因为全量失败那天目录没更新，同步过去的是旧的。

我盯着这行日志看了半天，脑子里就一句话：三年了，我们备份了个啥。

后面的事没啥好写的。拿 4 月 12 号之前的一个全量加 binlog 一点一点往前追，追到早上六点多，客户大部分数据回来了，最近两天新写的，丢了一部分。客户老板第二天上午来机房，脸色确实不好看，但也没说太难听的话——备份是我们承诺的服务，理亏在先，人家没拍桌子已经是给面子了。

这事之后我们把监控改了：备份任务不再只看退出码，每天备份完自动抽一个文件恢复验证，checksum 对不上就打电话。另外每季度做一次完整恢复演练，从备份里把机器整个拉起来，计时。上季度第一次演练，恢复一台机器用了 47 分钟，被客户吐槽太慢，但至少证明备份是能用的。

其实备份软件没做错什么，错的是我们这些管它的人——三年了，没有一个人真的去恢复过一次。文件躺在那里，日期是新的，大小看着正常，我们就以为它有用。三年备份，第一次真恢复，就赶上客户丢库，这运气也是没谁了。