Postgresus 2.0 带来重大增强:数据库自动健康检查、扩展存储目标(S3、Cloudflare R2、Google Drive、Azure、NAS)、更丰富的通知选项(Slack、Discord、MS Teams、webhooks)、基于工作区的用户/访问管理、内置加密和高效压缩,以及通过 Helm 原生支持 Kubernetes。该工具仍然是一种免费、开源的方式,通过 Docker 或 Helm 来调度和管理 PostgreSQL 备份 — 现在增加了团队和企业就绪性。Postgresus 2.0 带来重大增强:数据库自动健康检查、扩展存储目标(S3、Cloudflare R2、Google Drive、Azure、NAS)、更丰富的通知选项(Slack、Discord、MS Teams、webhooks)、基于工作区的用户/访问管理、内置加密和高效压缩,以及通过 Helm 原生支持 Kubernetes。该工具仍然是一种免费、开源的方式,通过 Docker 或 Helm 来调度和管理 PostgreSQL 备份 — 现在增加了团队和企业就绪性。

备份,不是倦怠:我们在 Postgresus 2.0 中发布了什么(以及我们放弃了什么)

2025/12/11 13:42

\ Postgresus 首次发布已经 6 个月了。在此期间,项目收到了 247 个提交、新功能,以及在 GitHub 上获得约 2.8k 颗星和从 Docker Hub 下载约 42k 次。项目社区也在增长,现在有 13 名贡献者和 90 人的 Telegram 群组。

在本文中,我将介绍:

  • 项目在六个月内发生了哪些变化;
  • 出现了哪些新功能
  • 接下来的计划是什么。

\

什么是 Postgresus?

对于第一次听说这个项目的人:Postgresus 是一个带有 UI 的开源 PostgreSQL 备份工具。它运行多个数据库的定时备份,将它们保存在本地或外部存储中,并在备份完成或失败时通知您。

该项目可以通过 Docker 中的单个命令部署。它可以通过 shell 脚本、Docker 命令、docker-compose.yml 安装,现在还可以通过 Kubernetes 的 Helm 安装。 更多关于安装方法的信息。

除了"创建备份"的主要功能外,该项目还可以:

  • 在本地、S3、CloudFlare R2、Google Drive、Azure Blob Storage 和 NAS 中存储备份。 更多详情请点击这里。
  • 向 Slack、Discord、Telegram、MS Teams 发送状态通知,通过电子邮件和可配置的 webhook 发送通知。 更多详情请点击这里。
  • 通过工作区分离数据库,授予其他用户访问权限并保存审计日志。 更多详情请点击这里。
  • 加密备份和凭据。 更多详情请点击这里。
  • 可以与自托管数据库和云托管数据库一起使用。

网站 - https://postgresus.com/

GitHub - https://github.com/RostislavDugin/postgresus (感谢给个星星 ⭐️)

项目界面如下所示:

概览视频:https://www.youtube.com/watch?v=1qsAnijJfJE

对于那些想参与开发的人,文档中有一个单独的 页面。如果有人想帮助这个项目但不想编码 — 只需告诉你的同事和朋友这个项目!这也是对项目的巨大帮助和贡献。

我知道如何开发,但即使是开源项目的推广也相当困难。该项目获得认可要感谢那些制作视频评论并在社交媒体上谈论该项目的人。谢谢你们!

2.0 版本中出现的新功能

这六个月来发生了很多变化。该项目在四个方向上得到了改进:

  • 扩展了基本功能;
  • 改进了用户体验;
  • 为团队(DBA、DevOps、团队、企业)提供了新功能;
  • 改进了保护和加密以满足企业需求。

让我们逐一了解。

1) 数据库健康检查

除了备份外,Postgresus 现在还监控数据库健康状况:它显示正常运行时间并在数据库不可用时提醒您。

健康检查可以禁用和配置。

如果数据库不可用 — 系统将发送有关它的通知。

2) 存储备份和发送通知的新来源

最初 Postgresus 只能在本地和 S3 中存储备份。现在添加了 Google Drive、CloudFlare R2、Azure Blob Storage 和 NAS。计划包括添加 FTP,可能还有 SFTP 和 NFS。

对于通知,最初项目有 Telegram 和电子邮件(SMTP)。现在还支持 Slack、Discord、MS Teams 和 webhooks。此外,webhooks 现在可以灵活配置以连接到不同的平台:

3) 工作区和用户管理

以前系统只有一个用户(管理员),数据库对整个系统是全局的。现在 Postgresus 支持创建工作区来分离数据库并向工作区添加用户。角色分离如下:

  • 仅查看 (可以查看备份历史记录,下载备份文件);
  • 编辑 (除了读取外,还可以添加\删除\修改数据库)。

因此,您现在可以分离数据库:

  • 客户 X 数据库;
  • 初创公司 Y 数据库;
  • 团队 Z 数据库;

DBA 团队和大型外包公司开始使用 Postgresus,所以这成为一个重要功能。它使项目不仅对个人开发者、DevOps 或 DBA 有用,而且对整个团队和企业也有用。

审计日志也出现了:

如果有人决定删除所有数据库或因某种原因下载了所有数据库的所有备份 — 这将是可见的 🙃

4) 加密和保护

在第一个版本中,老实说,我没有时间考虑安全性。我将所有备份文件存储在本地,没有人可以访问它们,而且我的项目也不是绝对机密的。

但当 Postgresus 开源后,我很快了解到团队经常将备份保存到共享的 S3 存储桶中,并且不希望其他人阅读它们。数据库密码也不应该存储在 Postgresus 自己的数据库中,因为许多人可以访问其服务器。 ~~而且彼此之间存在一些不信任。~~ 仅仅不通过 API 暴露机密已经不够了。

因此, 整个项目的加密和安全性成为 Postgresus 的主要优先事项。保护现在在三个层面上工作,并且有 专门的文档页面 介绍这一点。

1) 所有密码和机密的加密

所有数据库密码、Slack 令牌和 S3 凭据都以加密形式存储在 Postgresus 的数据库中。它们只在需要时解密。密钥存储在与数据库分开的文件中,因此即使有人入侵了 Postgresus 的数据库(无论如何它也不会对外暴露)— 他们仍然无法读取任何内容。加密使用 AES-256-GCM。

2) 备份文件的加密

备份文件现在也被加密(可选,但默认启用加密)。如果您丢失了文件或将其保存在公共 S3 中 — 现在就不那么可怕了。

加密同时使用盐和唯一的 初始化向量。这可以防止攻击者找到模式来猜测加密密钥,即使他们窃取了您所有的备份文件。

加密是在流模式下完成的,这里也使用 AES-256-GCM。

3) 使用只读用户进行备份

尽管有前两点,但没有 100% 的保护方法。仍然有一个微小的可能性:

  • 您的服务器将被完全入侵,他们会获取密钥和访问数据库的合法 IP 地址;
  • 黑客将以某种方式解密 Postgresus 内部数据库中的密码并找出您的数据库密码;
  • 或者更糟糕的是,它不是黑客而是内部人员;
  • 他们会破坏您的数据库,之前已删除备份。

因此,Postgresus 应该帮助用户将损害降到最低。这种黑客攻击的可能性可能接近零,但如果您是受害者,这并不能带来安慰。

现在,当您向 Postgresus 添加具有写入权限的数据库用户时,系统会提供自动创建只读用户并通过它运行备份的选项。当只需点击一下而不是在数据库中手动设置时,人们更有可能创建只读角色。

以下是 Postgresus 的提供方式:

非常坚持地提供:

采用这种方法,即使您的 Postgresus 服务器被黑客入侵,所有内容都被解密,攻击者获得了对您数据库的访问权限 — 他们至少无法破坏数据库。知道并非一切都失去了是一种相当好的安慰。

5) 默认压缩,最优化的压缩

Postgresus 的第一个版本提供了 PostgreSQL 支持的所有压缩算法:gzip、lz4 和 zstd,压缩级别从 1 到 9。老实说,我真的不明白为什么有人需要所有这些选项。我只是选择了 gzip 级别 5,因为它看起来是一个合理的中间地带。

但一旦项目开源,我不得不实际研究这个问题。所以我在所有可能的组合中运行了 21 个备份,找到了速度和大小之间的最佳平衡。

所以现在默认情况下,如果 PostgreSQL 版本是 16 及以上,所有备份都设置为 zstd 压缩级别 5。如果更低 — 仍然是 gzip(顺便说一下,再次感谢贡献者对 PG 12 的支持)。这是 zstd 5 与 gzip 5 的比较(它在底部):

平均而言,备份相对于实际数据库大小压缩了约 8 倍。

6) Kubernetes Helm 支持

这一点很简单 — 我们添加了带有 Helm 安装的原生 k8s 支持。在云中运行 k8s 的团队现在可以更轻松地部署 Postgresus。三名贡献者帮助实现了这一功能。

7) 深色主题

我并不是深色主题的粉丝。但有很多请求,所以我添加了一个(~~感谢 Claude 的帮助和设计师的眼光~~)。令人惊讶的是,它比浅色主题更好,并成为默认主题。我甚至将网站从浅色重新设计为深色 — 它看起来非常好。

之前:

之后:

8) 放弃增量备份和 PITR(时间点恢复)

首先,一些背景:

  • 逻辑备份 — 是指 PostgreSQL 自身导出其数据(到一个文件或一组文件)。
  • 物理备份 — 是指我们连接到 PostgreSQL 的硬盘并复制其文件。
  • 带 PITR 支持的增量备份 — 是物理备份 + 变更日志(WAL),从磁盘复制或通过复制协议复制。

我相信 Postgresus 最终应该支持增量备份。毕竟,这是严肃工具所做的事情!甚至 ChatGPT 也说严肃的工具可以精确到秒和事务进行恢复。

所以我开始着手实现它。但现实打击了我:

  • 在 UX 和 DevEx 方面很难使其方便。 因为你需要物理连接到数据库所在的磁盘,或者设置复制。

对于恢复 — 没有选项不连接到数据库所在的磁盘。要从增量备份恢复,备份工具只需恢复 pgdata 文件夹(更准确地说,是其中的一部分)。

如果数据库真的很大,例如,几个 TB 或更多 — 需要在配置中进行微调。在这里,UI 更多的是一种阻碍而非帮助。

  • 大多数云 (AWS、Google、Selectel) 不会与 外部 增量备份一起工作,如果它们需要磁盘访问。理论上,通过一些变通方法,通过复制 — 它们会工作。但从这样的备份恢复到托管云仍然无法工作。
  • 所有云都提供开箱即用的增量备份。 总的来说,这是它们收费的原因之一。即使它们通常也不允许精确到秒或特定事务时刻进行恢复。如果你不在云中 — 你的项目需要这种精度的可能性就更小了。

因此,如果 Postgresus 正在备份托管数据库 — 大约每周一次就足够了。以防不可预见的紧急情况或云不允许存储足够长时间的备份。否则,依赖云自己的增量备份。

  • 对于大多数项目,增量备份并不是真正必要的。 对于小型数据库,如果需要频繁备份,备份之间一小时的粒度就足够了。对于大型数据库 — 至少每天一次。这对于 99% 的项目来说足以找回丢失的数据或完全恢复。这些需求完全由逻辑备份覆盖。

但如果你是银行或托管数据库开发人员,你确实需要为数十和数百 TB 的数据提供最精细的备份配置。在这里,Postgresus 在控制台便利性和效率方面永远无法超越 WAL-G 或 pgBackRest 的物理备份,特别是对于体积在 TB 及以上的数据库。但在我看来,这些已经是由 PostgreSQL 本身的天才和维护者制作的专门工具。

在我看来,增量备份在两种情况下确实是必要的:

  • 在过去, 当没有这么多选择的云托管数据库,大型项目需要自己托管所有内容。现在同样的银行、市场和电信公司都有内置 PITR 的内部云。
  • 你是一个托管云。 但这里的任务比仅仅进行备份和从中恢复要复杂得多。

考虑到这一切,我做出了放弃增量备份开发的深思熟虑的决定。相反,我专注于使逻辑备份对开发人员、DevOps、DBA 和公司的日常使用尽可能方便、可靠和实用。

9) 许多小改进

上面的几点远非全部。80% 的工作通常是不可见的。我能想到的一个简短列表:

  • 缓冲和 RAM 优化。Postgresus 不再尝试缓冲 pg_dump 发送的所有内容,同时等待 S3 赶上(从数据库下载通常比上传到云更快)。每个并行备份的 RAM 使用现在限制为 32 MB。
  • 各种稳定性改进和小错误修复。
  • 添加无用户名和无密码的 SMTP。我甚至不知道这种情况会发生...
  • 为向 Telegram 群组发送通知添加主题。
  • 文档出现了!
  • PostgreSQL 12 支持。

还有更多。

什么没有成功?

当然,并非所有事情都能成功,有些事情必须放弃。我在业余时间构建 Postgresus,而这几乎不存在。所以我不能分散自己太多或用不必要的功能使 UX 复杂化。 太多功能也是不好的。

1) 完整的数据库资源监控

我想让 Postgresus 也成为一个 PostgreSQL 监控工具。包括运行 PostgreSQL 的服务器的系统资源:

  • CPU
  • RAM
  • ROM
  • IO 速度和负载

我甚至为收集指标(任何指标)和图表模板创建了基础:

结果发现 PostgreSQL 只开箱即用地暴露 RAM 使用和 IO 指标。

监控其他资源需要扩展。但并非每个数据库都能安装我需要的扩展,所以我只能收集部分指标。然后我发现云数据库通常根本不允许安装扩展。

然后我意识到指标应该存储在 VictoriaMetrics 或至少 TimescaleDB 中,而不是在 Postgresus 自己的 PostgreSQL 中,这会使镜像构建复杂化。

最终,这个非必要功能会增加:

  • 显著的代码复杂性,意味着更难维护;
  • 更多的镜像构建要求(额外组件);
  • 复杂的 UX(正如我所说,太多功能是不好的);
  • ~~不明确的定位:我们是备份工具、监控工具,还是试图做所有事情?~~

所以我放弃了资源监控,专注于使 Postgresus 成为它能成为的最好的备份工具。

2) SQL 控制台

我还想添加一个 SQL 控制台。既然 Postgresus 已经连接到数据库,为什么不直接从它运行查询呢?这会很方便 — 不需要每次都打开 PgAdmin、DataGrip 或 DBeaver。

我从未找到时间来开发它,只是计划。一位贡献者开始了这个功能并 提交了 PR。但正如复杂功能所预期的那样,出现了许多需求和边缘情况:

  • 需要添加 SQL 语法支持;
  • 添加自动完成和提示;
  • 实现懒加载,使即使 100MB 的行也不会全部加载到浏览器中;
  • 至少添加几个导出到 CSV 和 XLSX 的功能。

这基本上是一个完整的项目,而不仅仅是一个标签页。

我们决定放弃这个功能并节省精力。这被证明是正确的决定,因为我们添加了不允许 INSERT、 UPDATE 和 DELETE 的只读角色。

结论

这就是 Postgresus 在六个月内走过的旅程。它从一个小众项目成长为一个企业级工具,帮助个人开发者和整个 DBA 团队(顺便说一下,我很惊讶地了解到这一点是在第一次发布后约 2 个月)。我真诚地感到高兴,成千上万的项目和用户依赖 Postgresus。

项目并没有止步于此。我现在的目标是使 Postgresus 成为世界上最方便的 PostgreSQL 备份工具。有大量的功能和改进正在逐步推出。

我的主要优先事项仍然是:

  • 项目安全性 — 这是至关重要的,没有它一切都没有意义;
  • 在使用项目本身方面的便捷 UX,没有过多的功能(我们只做一项任务,但做得非常好);
  • 在部署方面的便捷 UX:使一切都能用一个命令部署,开箱即用不需要配置;
  • 项目开放性 — 完全开源,对任何人或公司都是免费的。

如果你喜欢这个项目或发现它有用 — 我会感谢在 GitHub 上给个 星星 或与朋友分享 ❤️

\

免责声明: 本网站转载的文章均来源于公开平台,仅供参考。这些文章不代表 MEXC 的观点或意见。所有版权归原作者所有。如果您认为任何转载文章侵犯了第三方权利,请联系 [email protected] 以便将其删除。MEXC 不对转载文章的及时性、准确性或完整性作出任何陈述或保证,并且不对基于此类内容所采取的任何行动或决定承担责任。转载材料仅供参考,不构成任何商业、金融、法律和/或税务决策的建议、认可或依据。