数据库备份

数据库备份是任何灾难恢复计划中不可或缺的组成部分。灾难的形式多种多样，可能是简单的误删表字段，也可能是数据库崩溃，甚至是自然灾害摧毁了数据库运行的底层硬件。这些场景带来的风险和影响永远无法完全消除，只能尽量减小或缓解。拥有数据库备份就像购买了一份保险，它们本质上是数据库在不同时间点的快照。当灾难发生时，数据库备份可以让项目回退到这些时间点中的任意一个，从而避免危机。

备份类型

数据库备份可分为两种类型：逻辑备份和物理备份。您可以通过此链接了解更多相关信息。

一般来说，项目会根据计划方案、数据库大小和附加组件采用逻辑备份或物理备份：

您可以通过导航至数据库备份 > 计划备份确认项目的备份类型：如果能够下载备份文件则为逻辑备份，否则为物理备份。

如果项目启用了时间点恢复(PITR)附加组件，则备份均为物理备份，您可以在数据库备份 > 时间点中查看这些备份。

备份频率

在决定数据库备份频率时，关键业务指标恢复点目标(RPO)应作为首要考量。RPO衡量的是灾难发生时企业可承受的数据丢失时间阈值。这个数值完全取决于具体业务及其底层需求。较低的RPO意味着需要以更高频次执行数据库备份。每个Supabase项目都支持两种备份形式：每日备份和按时间点恢复(PITR)。确定的RPO值将成为选择最适合项目备份方案的决定性因素。

每日备份

所有Pro、Team和企业版Supabase项目均默认执行每日自动备份。就恢复点目标(RPO)而言，每日备份适合能够承受在最不利时间点丢失最多24小时数据的项目。如需更低RPO，则应考虑启用按时间点恢复功能。

备份流程 #

我们使用Postgres工具pg_dumpall执行每日备份。系统会生成一个SQL文件，将其压缩后发送至我们的存储服务器进行安全保存。

您可以在控制台的计划备份设置中访问每日备份。专业版项目可访问最近7天的每日备份，团队版项目可访问最近14天的每日备份，而企业版项目最多可访问30天的每日备份。用户可以将项目恢复到任意一个备份点。如需自行生成逻辑备份，可通过Supabase CLI实现。

大型数据库的备份流程

对于超过15GB¹的数据库，如果运行在较新版本²的Supabase平台上，系统会自动切换³为使用每日物理备份。物理备份是一种性能更高的备份机制，能降低对被备份数据库的负载影响，同时避免长时间锁定数据库对象。虽然恢复操作不受影响，但通过此方法创建的备份无法从控制台的备份部分下载。

这类物理备份仅支持恢复到每日固定时间点，与每日备份类似。您可以升级至时间点恢复(PITR)来获取更细粒度的恢复选项。

一旦数据库切换为使用物理备份，即使数据库大小回落到切换阈值以下，仍会继续使用物理备份机制。

恢复流程 #

选择要恢复的备份时，请选择最接近但早于期望恢复时间点的可用备份。您也可以选择更早的备份，但需考虑可能丢失的数据天数。

仪表板会在执行恢复前提示确认。此后项目将无法访问，因此请确保事先预留停机时间。停机时长取决于数据库大小，数据库越大，停机时间越长。确认后，所选备份的底层SQL将在项目上执行。Postgres工具psql用于辅助恢复。恢复完成后，仪表板将显示通知。

如果您的项目使用了订阅或复制槽，需要在恢复前删除它们，并在恢复后重新创建。Realtime使用的槽不受此限制，会自动处理。

时间点恢复

时间点恢复(PITR)允许以更短的时间间隔备份项目。这为用户提供了以秒级粒度恢复到任意选定时间点的选项。即使有每日备份，仍可能丢失一天的数据。而PITR可以实现灾难发生时的精确备份。

备份流程 #

正如这篇文章所述，PITR（时间点恢复）是通过结合项目物理备份和归档预写日志(WAL)文件实现的。物理备份提供数据库底层目录的快照，而WAL文件则包含数据库中所有变更的记录。

Supabase使用开源归档和恢复工具WAL-G来处理PITR的两个方面。每天会对数据库进行一次快照并发送到我们的存储服务器。在一天中，随着数据库事务的发生，WAL文件会被生成并上传。

默认情况下，WAL文件每两分钟备份一次。如果这些文件超过特定的大小阈值，则会立即备份。因此，在事务量大的时期，WAL文件备份会更加频繁。相反，当数据库没有活动时，则不会进行WAL文件备份。总体而言，这意味着在最坏情况或灾难发生时，PITR能够实现两分钟的恢复点目标(RPO)。

您可以在Dashboard的时间点恢复设置中访问PITR功能。项目的可恢复周期由显示在您首选时区中的最早和最晚恢复点表示。如果需要，可以相应调整这个恢复周期的最大时长。

请注意，项目的最新恢复点可能与当前时间相差较大。这种情况发生在数据库近期没有任何活动时，因此最近没有生成WAL文件备份。这是完全正常的，因为如果在最新恢复点和当前时间之间没有发生任何事务，那么最新恢复点的数据库状态仍然能准确反映当前时间的数据库状态。

恢复流程 #

点击开始恢复按钮后，系统将提供日期和时间选择器。只有当选择的日期时间处于最早和最晚可恢复点之间时，流程才会继续。

锁定要恢复到的目标时间点后，控制面板会要求您进行审查确认，然后才会继续执行恢复操作。此后项目将无法访问。因此，请务必提前预留停机时间。停机时长取决于数据库大小——数据库越大，停机时间越长。确认后，系统会下载项目可用的最新物理备份并部分恢复数据库。接着下载从该物理备份到指定时间点之间生成的WAL文件，将这些文件中记录的事务重放到数据库中以完成恢复。恢复完成后，控制面板会显示通知。

定价

定价取决于恢复保留期，该期限决定了您可以将数据恢复到过去多少天内的任意选定时间点，精确到秒级。

有关费用计算的详细说明，请参阅管理时间点恢复用量。

恢复到新项目

Supabase 提供了一种便捷的方式，可将现有项目的数据恢复到全新的项目中。无论您使用物理备份还是时间点恢复(PITR)，此功能都能轻松复制项目数据、安全执行测试或恢复数据进行分析。该功能仅限付费计划用户使用，且要求源项目已启用物理备份。

首先切换到源项目（包含您要恢复数据的项目），进入数据库备份页面，选择恢复到新项目选项卡。

系统将显示可用备份列表。选择您要使用的备份并点击"恢复"按钮。对于已启用PITR的项目，可使用日期和时间选择器指定要恢复数据的确切时间点。

完成选择后，Supabase会自动处理后续流程。系统将创建一个新项目，复制原始项目的关键配置，包括计算实例大小、磁盘属性、SSL强制设置和网络限制等。数据将保留在源项目所在区域，以确保符合数据驻留要求。整个过程完全自动化。

"恢复到新项目"流程存在一些重要限制需要注意：

• 目前通过恢复流程创建的项目不能作为进一步克隆的源项目
• 该功能仅对已启用物理备份的付费计划用户开放，确保恢复过程具备必要的资源和基础设施

开始恢复前，系统会显示创建新项目相关费用的概览。新项目将根据从源项目镜像的资源产生额外的月度费用。建议在继续操作前仔细核对这些费用。

恢复完成后，新项目将出现在您的仪表盘中，包含所选备份源的所有数据、表、模式及选定设置。建议全面检查新项目并进行必要测试，确保所有内容已按预期恢复。

新项目完全独立于其源项目，因此可以根据需要进行修改和使用。

恢复到新项目是更有效管理环境的绝佳方式。您可以使用此功能创建测试用的预发布环境、无风险地实验变更方案，或从意外数据丢失场景中快速恢复。

故障排除

逻辑备份问题

search_path 路径问题#

在执行 pg_restore 恢复过程中，为了确保可预测性和安全性，search_path 会被设置为空字符串。如果在SQL代码中使用非限定引用的函数或关系，可能导致逻辑备份恢复失败，因为数据库无法定位被引用的函数或关系。这种情况即使在正常操作时数据库运行良好也可能发生，因为在常规操作中 search_path 通常包含多个模式(schema)。因此，您应该始终在SQL代码中使用模式限定的名称。

您可以参考这个示例PR了解如何更新SQL代码以使用模式限定名称。

无效的检查约束

PostgreSQL要求检查约束必须满足：

1. 不可变性
2. 不能引用被检查行之外的表数据

违反这些要求可能导致多种故障场景，包括在逻辑恢复过程中出现问题。

常见的可能导致此类故障的检查约束示例包括：

• 针对当前时间进行验证，例如验证插入的行是否引用了未来的事件
• 根据另一个表的内容验证行的内容