如何免费备份 Supabase 数据库

Supabase 是一个开源的后端即服务（BaaS）平台，提供实时数据库、身份验证、文件存储等功能，且提供了慷慨的免费计划。

但有一个关键问题：整个数据库仅存在于Supabase的云中，备份功能被锁定在付费计划后面。

虽然大厂一般情况下还是值得信赖的，但是在一些特殊情况下，比如：进行危险操作前、不可抗力因素、偶发性事件等等发生的时候，有一个备份还是很有必要的。

在免费计划中，我们可以借助 PostgreSQ 提供的 pg_dump 工具实现来实现备份和恢复功能。

PostgreSQ 工具

简介：pg_dump 是 PostgreSQL 提供的一个强大的命令行工具，用于备份数据库。它可以将数据库导出为 SQL 脚本或其他格式，方便数据迁移、备份和恢复。

1. 安装PostgreSQL工具

首先，需要在本地安装PostgreSQL才能访问pg_dump实用程序。

可以直接从 PostgreSQ官方 下载对应平台的安装包。如果不需要完整的 PostgreSQL 服务器可以只安装包含 pg_dump 的客户端工具。

MacOS 用户也可以通过 brew 进行安装：

brew install libpq
echo 'export PATH="/opt/homebrew/opt/libpq/bin:$PATH"' >> ~/.zshrc

修改 .zshrc 后必须重新加载才能生效，或者重启终端。

验证安装命令: pg_dump --version

2. 获取 Supabase 的连接信息

登陆 Supabase 仪表板，进入对应的项目，在顶栏找到 Connect （插头图标），点击进入寻找 Session pooler 一栏，里面的 URL 便是连接信息。

出于安全原因，数据库密码不会在这里显示。但是在创建数据库的时候你应该有保存密码，如果没有也没有关系，可以点击最下面的 Reset your database password 到 Database Settings 里面进行密码重置。

3. 执行备份

在本地终端使用 pg_dump 命令进行备份操作：

pg_dump -h db.xxxxxxxxxxxx.supabase.co \
  -U postgres \
  -d postgres \
  -F c \
  -f backup_$(date +%Y%m%d).dump

• -h: 指定数据库服务器的主机名或IP地址。
• -U: 指定连接数据库的用户名。
• -d: 指定要备份的数据库名称。
• -F c: 指定输出文件的格式为“自定义归档格式”(见参考内容)。
• -f: 指定输出文件的路径和名称。

备份完成后文件应该大于几KB。空或小文件则表示备份可能失败。

参考内容

pg_dump 的 -F (或 —format) 参数用于指定备份文件的输出格式。选择不同的格式会直接影响备份文件的大小、可读性以及恢复时的灵活性。

特性 / 维度	纯文本 (plain) -F p	定制 (custom) -F c	目录 (directory) -F d	Tar (tar) -F t
格式标识	-F p (或不指定，为默认值)	-F c	-F d	-F t
输出形式	单个 .sql 文本文件	单个 .dump 二进制文件	一个包含多个文件的目录	单个 .tar 归档文件
恢复工具	psql	pg_restore	pg_restore	pg_restore
	psql -d db < file.sql	pg_restore -d db file.dump	pg_restore -d db backup_dir/	pg_restore -d db file.tar
人类可读性	✅ 完全可读 可直接用文本编辑器查看和修改SQL命令。	❌ 不可读 二进制格式，无法直接查看。	⚠️ 部分可读 目录中的 toc.dat (内容清单) 可读，但数据文件是二进制的。	❌ 不可读 二进制归档文件。
默认压缩	❌ 不支持 文件体积最大。需手动用 gzip 等工具压缩。	✅ 支持 (默认开启) 使用 zlib 压缩，备份文件体积显著减小。	✅ 支持 (默认开启) 与 custom 格式相同，对目录内数据文件进行压缩。	❌ 不支持 Tar 仅是打包归档，本身不含压缩。
选择性恢复能力	❌ 不支持 只能完整恢复。若想只恢复部分，需手动编辑SQL文件，极其复杂且易错。	✅ 极佳 可灵活恢复指定 Schema、表、索引、函数、数据、或仅恢复结构。	✅ 极佳 具备与 custom 格式完全相同的灵活恢复能力。	✅ 支持 同样具备灵活恢复能力，但效率可能略低于 custom/directory。
并行备份 (pg_dump -j)	❌ 不支持 只能单线程导出。	❌ 不支持 因为需要写入单个文件流，无法并行。	✅ 唯一支持 可以同时导出多个表到不同文件，是备份超大数据库的最快方式。	❌ 不支持 与 custom 类似，写入单个文件流。
并行恢复 (pg_restore -j)	❌ 不支持 psql 是单线程执行SQL脚本。	✅ 支持 可并行加载数据，极大提升大型数据库的恢复速度。	✅ 支持 并行恢复效率最高，因为数据已分散在不同文件中。	✅ 支持 同样支持并行恢复。
主要优点	- 简单直观：易于理解、审查和手动修改。 - 高兼容性：便于版本控制(Git)，或少量修改后用于其他数据库。	- 功能均衡：集压缩、灵活恢复、快速恢复于一身。 - 可靠通用：是绝大多数场景的最佳选择。	- 备份速度最快：唯一支持并行备份，是超大型数据库的福音。 - 恢复同样极快且灵活。	- 单一文件：比目录格式更容易通过网络传输或管理。 - 保留元数据：Tar 格式的特性。
主要缺点	- 体积庞大：无压缩。 - 恢复死板：全有或全无，出错即中断。 - 恢复缓慢：单线程，无优化。	- 备份非并行：对于超大型数据库，备份可能耗时较长。 - 不可读：无法直接检查内容。	- 管理不便：输出为目录，传输和存储不如单个文件方便 (需手动打包)。	- 已被超越：功能上几乎完全被 custom 格式覆盖且性能更好。 - 无内置压缩。
典型应用场景	- 小型数据库备份。 - Schema 定义的版本控制。 - 教学和调试。 - 需要手动修改SQL以迁移到异构数据库。	- 日常生产备份 (95%的场景)。 - 在不同 PostgreSQL 版本间迁移。 - 需要从备份中恢复特定对象的环境 (如恢复误删的表)。	- TB 级超大型数据库 (VLDB) 的备份。 - 备份窗口时间极其有限的场景。	- 遗留系统维护。 - 有特殊工具链要求必须使用 .tar 文件的场景。

如果不确定用哪个，或者没有极端需求，建议始终选择 -F c (custom)。它在文件大小、备份可靠性、恢复速度和灵活性之间提供了最佳的平衡点，能够满足绝大多数业务需求。

定期备份

对于 Supabase 来说，绝大部分时间应该都是安全的，官方肯定也有灾容备份管理。所以，我们只要定期/危险操作前进行下备份就可以了。

高级用户则可以根据需求编写脚本实现自动化。

数据无价