备份 PostgreSQL 数据库管理系统

在 potgresql 备份问题中，有两种基本的可能性：

逻辑备份

常规实用程序pg_dump和pg_dumpall. 逻辑备份是将重新创建数据库的查询文本。由此得出：

• 恢复缓慢。数据将很快被复制，但将在不知道此备份是什么的情况下构建索引和其他限制，并将检查限制的有效性
• 只有在开始复制每个数据库时才能通过pg_dump（pg_dumpall调用pg_dump集群的每个数据库）进行恢复
• 袖珍的。通常，数据库卷的很大一部分被索引占用。逻辑转储中的哪些仅由用于创建这些索引的命令表示。此外，文本压缩得很好。因此，逻辑转储很容易比数据库大小小 10 倍
• 只能保存一些数据库，不能保存一些表
• 文本格式plain- 只是请求的文本，即使使用文本编辑器也可以从中获取数据。
• 格式custom，directory另一方面，您可以在多个流中并行恢复（directory并在多个流中拍摄） - 这减少了恢复时间。并且还可以从这些格式中恢复单个数据库对象，例如，只有一个表。

pg_dump并且pg_dumpall可以通过网络工作。唯一的要求是备份机器上的实用程序版本必须与 DBMS 本身相同或更新。此外，对主要版本没有限制。pg_dump11.4 版可以有条件地从 9.3.12 版正确备份（通常在 7.0 版本之前）

您还可以在不同版本的 postgresql 上恢复。

物理备份

另一种可能性是使用数据库的物理副本。pg_basebackup或其他实现。

• 可以选择将数据库恢复到特定事务​​的时刻。这需要将基本备份带到所需的恢复点和连续的 WAL 存档
• 此备份占用大量空间。如果您有兴趣恢复到任意时间点 (PitR)，那么 WAL 归档文件会占用更多难以预测的容量
• 它只是整个 postgresql 实例的副本。严格来说，此实例中的所有碱基都不能排除。并且体积正好等于底座的体积。
• 恢复是简单的文件复制然后启动数据库。数据量方面有很多要复制的，但操作简单，多为大文件
• 但是，恢复到任意时间点需要处理从 basebackup 开始到所需点的所有 WAL。而且它可能不会很快。
• 只能使用基础的相同主要版本并且不低于相同的次要版本进行恢复

它也可以毫无问题地通过网络工作。通常，除了备份之外，它们还会生成副本。

然后数据库的所有者会考虑是否需要恢复到任意时间点，是否准备好备份如此大量的数据，或者例如每天的逻辑转储是否足够。然后你决定要保留多少份。

您可以使用这两种方法，例如，在周一/周四删除基本备份的情况下制作一周深度的 WAL 存档，在周六制作pg_dump并存储一个逻辑转储，再保存六个月。

直接设置选定的备份计划：

• pg_dump 通常只从 cron 发送错误通知到邮件很方便。
• 对于basebackup，手动编译正确的存档维护程序并不是那么简单，使用专门的系统是有意义的wal-g（如果你需要备份到非常简单S3）pgbackrest，，barman