备份恢复之后数据少了好几天，三处时间点需要逐个核对

备份做完看到成功两个字，很少有人再去打开文件看一眼。等到真出事要恢复，才发现数据比预期少了好几天。或者干脆恢复出来的是更早的一份。这类情况不是备份没做。是三处时间点没对齐。任务实际执行的时间。文件内容真正生成的时间。恢复时选中的那一份。三处任意一处错位，缺口就出来了。而且从备份列表上完全看不出来，文件都在，名字正常，大小也对。备份列表看着整齐，最容易让人放心。实际缺口就藏在这些看起来正常的东西里。

任务有没有真的跑过，得从日志里确认。面板显示成功，可能是上一次的记录。crontab里写了，也可能因为环境变量缺失中途退出。日志里要有每次执行的开头和结尾。两样都没有，就只能靠猜。

文件本身也要打开看，文件名带日期不代表内容是那天的。覆盖写失败会留下旧文件，只是名字被更新过。用ls -l看大小，跟历史同期比。突然小一截就是没写完。gzip压缩的可以用gzip -t校验完整性。tar包用tar -tzf把内容列一遍，能看出有没有截断。截断的包解压到一半会报错，比恢复完才发现强得多。

命令通过管道接到gzip的时候，mysqldump导出中途报错，管道最后一个进程仍然返回成功。脚本判断成功就继续往下走，缺口就这么留下了。脚本开头加上set -o pipefail，前面失败整条链就失败。pipefail要写在脚本最前面，整条链才管用。

第三处是恢复时选的哪一份。面板一般保留最近若干份，按文件名排序取第一份。命名规则一变就取错了。有的是日期在前，有的是序号在前，混着用最容易出错。保留策略也要跟恢复目标对上。只留七份，想回到十天前就没有了。恢复之前先把可用文件的时间列一遍。跟缺口对一下再动手，比恢复完再发现不对省得多。文件名排序不等于时间排序，这条要单独记。

恢复完了，表数量、最新一条记录的时间、自增ID的当前值、关键表的行数，这四样要一起核。行数跟备份时间点接近就对上了。差得远说明中间有表没导出来。自增ID对不上，说明表结构或数据顺序有差异。四样全对得上，才算恢复完成。

挑一台测试机，按真实流程恢复一次，把耗时也记下来。备份可用性只能靠这个证明，真出事的时候心里有数。这件事半年做一次，比看一百次成功提示管用。演练也会暴露流程本身的问题。