7.10 数据库备份策略
Tip
数据是无价的，而硬盘是有价的。用最廉价的硬盘空间，换取最宝贵的数据安全。
1. 为什么要学这个?
深夜 2 点，你在清理垃圾数据时，手抖敲错了一个命令：
DELETE FROM User; (忘了加 WHERE 条件)。
回车敲下的瞬间，屏幕显示：50,000 rows affected。
整个网站的用户数据瞬间归零。
你颤抖着联系云服务商客服，对方只回了一句冷冰冰的："数据责任在您 (Data responsibility is yours)"。
学会这套策略，下次面对误删事故时，你只需要执行一条回滚指令，就能在几分钟内让数据完好如初。
2. 核心概念
在数据安全领域，有一个被称为黄金法则的 "3-2-1 原则"。这不是三个步骤，而是三道保命防线。
第一道防线：3 份数据
永远不要只保留一份孤本。你至少应该拥有 3 份 同样的数据：1 份正在使用的原件，加上 2 份备份。这就好比"狡兔三窟"，堵死一个口还有别的路。
第二道防线：2 种介质
这两份备份不能放在同一个篮子里。比如，你可以一份放在 Supabase 的云端服务器上，另一份放在你家里的移动硬盘（或另一个云服务商 S3）里。 这样，即使 Supabase 倒闭了，或者你的账号被封了，你在家里还有一份底牌。
第三道防线：1 个异地
至少有一份备份必须在 物理位置 上是隔离的。 如果你的原件和备份都在同一个城市的机房里，一旦发生地震或火灾，它们会一起消失。异地备份就是防止这种物理层面的"团灭"。
3. 实战方案
对于 Supabase 用户，你有两种选择：钞能力方案和穷人方案。
钞能力方案：PITR
Supabase Pro 版提供 Point-in-Time Recovery (PITR) 功能。 这就像给数据库装了一个行车记录仪，它记录了每一秒钟的变化。你可以随时在控制台拖动进度条，把数据库回滚到"昨天下午 3:00:00"的状态。这是最省心、最强大的后悔药。
穷人方案：GitHub Actions 自动脚本
如果你不想花钱，可以利用 GitHub Actions 写一个定时脚本，每天凌晨运行 pg_dump 命令。
pg_dump 就像一个打印机，它能把你的整个数据库"打印"成一个巨大的文本文件 (SQL)。然后你把这个文件偷偷传到另一个云存储（如 AWS S3）里。
备份流转图
graph LR
DB[("Supabase 数据库")] -->|"每日快照"| PITR["云端历史备份"]
DB -->|"脚本导出"| Dump["SQL 文本文件"]
Dump -->|"传输"| NAS["异地硬盘 / AWS S3"]
style PITR fill:#fff9c4,stroke:#fbc02d
style NAS fill:#c8e6c9,stroke:#388e3c
4. 避坑指南
| ❌ 错误做法 | ✅ 正确做法 | 💡 为什么 |
|---|---|---|
| 只备份不验证 | 定期演练恢复 | 很多人的备份脚本其实早就报错了（生成了 0KB 的空文件），但直到没人看的日志里躺了半年。等到要救命时才发现备份是坏的。 |
| 把密码写在脚本里 | 用环境变量 | 千万别把数据库密码直接写在备份脚本里推送到 GitHub。那样黑客都不用攻破你的数据库，直接去 GitHub 拿钥匙就行了。 |
| 覆盖旧备份 | 带时间戳归档 | 备份文件名必须带上日期（如 backup_2023_10_01.sql）。如果你只用 backup.sql，新备份会覆盖旧的。万一新备份是坏的，你就彻底完了。 |
5. 真实案例
Story
玩具总动员 2 的消失危机 (1998)
这是一个电影史上最著名的惊魂时刻。皮克斯的一位员工在清理文件时，误输入了删除命令，导致《玩具总动员 2》90% 的制作文件在服务器上凭空消失。 当这一幕发生时，大家并未惊慌，因为他们有完善的磁带备份系统。 然而，当技术人员试图从磁带恢复数据时，绝望地发现：由于软件的一个 Bug，过去几个月的备份其实全是失败的。备份系统在一个文件达到 4GB 后就默默停止了工作，且没有发出任何警报。 这就是传说中的**"薛定谔的备份"**：在你尝试恢复它之前，你永远不知道备份是否真的存在。 所幸，一位在家休产假的技术总监偶然把一份拷贝带回了家里的电脑上。这台家里的旧电脑，最终拯救了这部价值数亿美元的电影。
Vibe 心法：没有经过恢复验证的备份，只是一个安慰剂。遵循 3-2-1 原则，并定期演练"起死回生"。不要等到 ICU 里才发现呼吸机没插电。
6. 本章小结
- 🛡️ 3-2-1 法则：3 份拷贝，2 种介质，1 个异地，缺一不可。
- 🕰️ 验证机制：定期检查备份文件的大小，并尝试恢复一次。
- 🤖 自动化：把备份交给机器去跑，人的记性是最不可靠的。