数据库备份、迁移和恢复

一句话：数据库备份、迁移和恢复就是保护项目最重要的数据资产，让你在改表、误删、服务器故障时还有办法救回来。

本篇学完你会什么：知道为什么备份不等于安全，迁移前要检查什么，恢复流程怎么演练，以及生产数据库变更为什么要分阶段。

1. 数据库为什么是系统的命根子

代码坏了，可以重新部署。

服务器坏了，可以重新创建。

但数据库里的用户、订单、文章、配置、权限如果丢了，很多时候不是重新发版就能解决。

常见事故：

所以要记住一句话：

没有验证过的备份，不算真正的备份。

2. 备份有哪些类型

全量备份

把整个数据库备一份。

优点：

恢复简单
适合小项目

缺点：

数据越大越慢
占空间

增量备份

只备上次之后变化的数据。

优点：

节省空间
适合数据量大

缺点：

恢复流程更复杂

逻辑备份

导出 SQL 或结构化数据。

PostgreSQL 常见：

pg_dump -h localhost -U app -d appdb -f backup.sql

这个命令导出的是单个数据库的普通 SQL 文件，适合入门理解和小项目演练。

它不等于“整个数据库服务器都备份好了”。如果你的系统依赖角色、权限、扩展、定时任务等全局对象，需要另外记录，或者用 pg_dumpall --globals-only 导出全局对象。数据量变大后，也可以考虑 pg_dump -Fc 生成自定义格式，再用 pg_restore 恢复。

物理备份

备数据库底层文件或使用数据库专门的备份机制。

生产大库更常见，但对初学者来说，先理解逻辑备份和恢复就够用。

3. 备份要检查什么

备份不是“命令跑完”就结束。

要检查：

先认识两个词：

下面只是一个小项目的简单备份策略，不是所有生产系统的标准答案：

每天一次全量备份
保留最近 7 天
每周保留一个月度备份
备份上传到独立存储
每月至少恢复演练一次

4. 迁移前要做什么准备

改表前先问 6 个问题：

这次改动会影响哪些表？
表里有多少数据？
会不会锁表？
代码是否兼容新旧结构？
失败后怎么回滚？
迁移前有没有备份？

Alembic 迁移脚本也要人工看一遍。

自动生成的脚本不一定完全安全，特别是：

5. 生产改表怎么更安全

新增字段

比较安全：

先加 nullable 字段
代码开始写新字段
补历史数据
确认都有值
最后再改成 not null

删除字段

不要一步删。

更安全的流程：

代码先不读这个字段
观察一段时间
确认没有地方使用
备份
再删除字段

字段改名

字段改名看起来简单，其实容易影响代码。

稳一点：

新增 new_name
代码同时写 old_name 和 new_name
迁移历史数据
代码只读 new_name
最后删除 old_name

6. 恢复演练怎么做

恢复演练不是在生产库上试。

可以这样做：

1. 准备一个空测试数据库。
2. 找最近一次备份文件。
3. 把备份恢复进去。
4. 跑关键 SQL 检查数据量。
5. 启动应用连这个恢复库。
6. 打开登录、列表、详情等关键页面。

PostgreSQL 逻辑恢复示例：

createdb -O app appdb_restore
psql -d appdb_restore -f backup.sql

执行前先确认 appdb_restore 不存在，避免覆盖已有恢复库。恢复完成后，也要确认应用连接的是恢复库，而不是误连生产库。

恢复后检查：

SELECT count(*) FROM users;
SELECT count(*) FROM roles;
SELECT count(*) FROM user_roles;

大白话：备份像降落伞，不是背在身上就行，要确认真能打开。

7. 常见错误

8. 检查清单

[ ] 有定期备份任务
[ ] 明确 RPO 和 RTO
[ ] 备份文件不在同一台机器
[ ] 备份有保留策略
[ ] 备份包含结构和数据
[ ] 定期做恢复演练
[ ] 迁移脚本人工 review
[ ] 危险迁移已拆成多步
[ ] 迁移前有最新备份
[ ] 回滚或修复方案写清楚

9. 小结

上一篇建议：先看《后端安全加固实战》。

下一篇建议：继续看《接口契约、版本管理和文档》，把前后端长期协作管住。