小项目数据库备份：从手动导出到定时自动备份的实操记录

上个月我误删了一张表。那是一个周二下午，我在清理测试数据，命令敲下去才发现连错了数据库，生产库里一张用户反馈表被清空了。还好那张表只有两百多条记录，我花了一个晚上从旧的导出文件里拼了回来，但那次之后我明白了一件事：没有备份的数据库，迟早会用一次事故来提醒你。

这篇文章记录我给小项目搭备份的完整过程：从最开始的手动导出，到每天自动备份，再到定期演练恢复。每一步都不复杂，一个下午就能做完。

第一步：先有一次能用的手动备份

搭自动备份之前，我先确认手动备份这条路是通的。很多人的备份脚本跑了几个月，第一次真正需要恢复时才发现备份文件是空的，或者根本打不开。

我的数据库是 MySQL，手动备份用的就是自带的导出命令，把整个库导成一个 SQL 文件。导出时我加了两个习惯：第一，导出前先看一眼库的大小和表数量，导出后对照文件大小，太小就说明可能有问题；第二，导出的文件立刻用解压工具打开看一眼，确认里面确实有建表语句和插入语句，而不是只有几行报错。

备份文件存在哪里也很重要。不要只存在数据库同一台机器上，机器硬盘坏了，备份和数据库会一起消失。我现在的做法是：本地保留最近 7 天的备份，云端对象存储再保留 30 天。对象存储的费用很低，一个几十 MB 的备份文件，一个月花不了几毛钱。

还有一个细节：备份文件的文件名要带日期和时间，比如 backup-2026-11-09-0200.sql.gz。一旦出问题要找“昨天凌晨两点的那份”，靠文件名一眼就能定位，不用一个个打开看。

第二步：把手动备份变成定时任务

手动备份最大的问题不是不会做，而是会忘。我第一次手动备份之后，整整三周没再备过，直到误删那天才想起来。

所以第二步就是把它交给定时任务。我在服务器上加了一条每天凌晨 2 点执行的任务：导出数据库、压缩、按日期命名、传到对象存储、删除本地 7 天前的旧文件。凌晨 2 点是业务量最低的时候，导出时短暂锁表对用户基本没有影响。

定时任务上线第一周，我每天早上都去检查三件事：备份文件生成了没有、文件大小和昨天差不多吗、对象存储里有没有新文件。连续一周都正常，我才把它从每天检查改成每周检查一次。

这里有一个坑：定时任务失败时默认是静默的。我第一次写的任务有两天没跑，原因是导出命令的路径写错了，但没有任何人告诉我。现在我在任务最后加了一行：备份完成后发一封邮件，标题里带上文件大小；如果没收到邮件，就说明备份没跑，第二天早上第一件事就是去查。

第三步：备份文件要定期验证，别等到用时才发现是坏的

备份做出来不等于备份能用。我见过最惨的情况：备份跑了半年，恢复那天发现文件损坏，半年备份全是摆设。

验证的方法很简单：每个月找一台测试机，把最近的一份备份恢复进去，然后跑几个最关键的查询——用户表有多少行、最新的一条订单是什么时间、几个核心配置还在不在。能查出来，备份就是好的；查不出来，当天就修。

我第一次演练恢复就发现了问题：备份文件里缺了一张新加的表。原因是导出命令里写死了表名清单，新表加上之后没人更新清单。那次之后我改成导出整个库，不再逐张表列名字，新表自动包含在内。

恢复演练还有一个好处：它逼着你把恢复步骤写下来。真正出事故的时候，人是最慌的，有一份写好的步骤照着做，比凭记忆敲命令可靠得多。我的恢复文档只有半页：下载哪天的备份、解压命令、导入命令、验证哪三条查询。每次演练完就更新一次这份文档。

第四步：给备份分个级，不是什么数据都值得天天备

小项目的表不是一样重要的。用户数据和订单数据丢了是大事，日志表和临时缓存表丢了，最多损失几天的统计数字。

所以我现在是分级备份：核心业务库每天全量备份一次；日志类数据每周备份一次，只保留两周；缓存和会话数据不备份，丢了可以重建。分级之后，备份文件小了，恢复的时候也清楚先恢复哪个库、后恢复哪个库。

分级还有一个好处是省钱。对象存储按量计费，什么都天天备，一个月下来也是一笔钱。只备真正重要的数据，费用直接降了一大半。

一份可以直接照抄的清单

1. 今天就手动导一次全库备份，打开文件确认内容完整，文件名带上日期时间。
2. 备份至少存两份：本地一份、对象存储或另一台机器一份。
3. 写一条凌晨执行的定时任务，每天自动备份，并把本地旧备份只保留 7 天。
4. 备份任务完成后发一封带文件大小的通知，没收到通知就等于备份失败。
5. 每月做一次恢复演练：把备份恢复到测试机，跑三条关键查询验证数据。
6. 恢复步骤写成半页文档，每次演练后更新一次。
7. 核心数据每天备，日志类每周备，缓存类不备。

误删那张表之后，我花了一个晚上拼数据；如果当时有前一天的自动备份，恢复只需要十分钟。备份这件事，投入的是一个下午的配置时间，换来的是出事故那天不用熬夜。越是小项目，越经不起一次数据丢失，因为小项目往往没有第二个人能帮你兜底。