如何在一台服务器上制定多个数据库的备份策略

当数据库损坏、损坏或变得不可用时，根本没有备份会导致更多的挫败感。

这是一个非常简单的计算：

无备份

• 停业
• 管理不满意
• 客户不满意
• 很棒的演出

备份

• 备份期间性能略有下降
• 业务继续
• 管理愉快
• 客户满意

pg_basebackup

pg_basebackup以下是PostgreSQL 附带的工具的摘录：

_{（强调我的）}

pg_basebackup用于对正在运行的 PostgreSQL 数据库集群进行基本备份。这些是在不影响数据库的其他客户端的情况下进行的，并且可以用于时间点恢复（参见第 25.3 节）和作为日志传送或流复制备用服务器的起点（参见第 26.2 节）。

pg_basebackup制作数据库集群文件的二进制副本，同时确保系统自动进入和退出备份模式。总是对整个数据库集群进行备份；无法备份单个数据库或数据库对象。对于单个数据库备份，必须使用诸如此类的工具。pg_dump

通过常规 PostgreSQL 连接进行备份，并使用复制协议。必须使用超级用户或具有 REPLICATION 权限的用户建立连接（参见第 21.2 节），并且 pg_hba.conf 必须明确允许复制连接。服务器还必须配置为 max_wal_senders 设置得足够高，以使至少一个会话可用于备份，一个会话可用于 WAL 流（如果使用）。

可以同时运行多个 pg_basebackups，但从性能的角度来看，最好只进行一次备份，然后复制结果。...

^{pg_basebackup (PostgreSQL 12 文档}

进行基本备份

配置完所有内容后（阅读整个文档），您可以使用以下命令执行基本备份：

bash #> pg_basebackup -D \postgresql\backup\ -F t -R -z -h yourhost -p 5432 -U root -W

这可以在交互式 bash 提示符下使用。设置 crontab 作业时，您必须创建一个.pgpass文件。这将允许您将命令作为 crontab 作业运行，而无需输入密码。

请阅读33.15。密码文件（PostgreSQL 文档）了解更多详细信息。

持续 WAL 归档

第25.3 条。连续存档和时间点恢复 (PITR)包含有关如何存档 PostgreSQL 创建的 WAL（预写日志）文件的信息。将 PostgreSQL 集群恢复到某个时间点需要这些文件。

PostgreSQL 在任何时候都在集群数据目录的 pg_wal/ 子目录中维护一个预写日志 (WAL)。日志记录对数据库数据文件所做的每一次更改。该日志的存在主要是出于崩溃安全的目的：如果系统崩溃，可以通过“重放”自上次检查点以来所做的日志条目来将数据库恢复到一致性。但是，日志的存在使得使用第三种备份数据库的策略成为可能：我们可以将文件系统级别的备份与 WAL 文件的备份结合起来。如果需要恢复，我们会恢复文件系统备份，然后从备份的 WAL 文件中重播，以使系统恢复到当前状态。这种方法管理起来更复杂与之前的任何一种方法相比，它都有一些显着的好处：

• 我们不需要一个完全一致的文件系统备份作为起点。备份中的任何内部不一致都将通过日志重放来纠正（这与崩溃恢复期间发生的情况没有显着不同）。所以我们不需要文件系统快照功能，只需要 tar 或类似的归档工具。

• 由于我们可以组合无限长的 WAL 文件序列进行回放，因此只需继续归档 WAL 文件即可实现连续备份。这对于大型数据库特别有价值，因为在这些数据库中经常进行完整备份可能不方便。

• 没有必要一直重播 WAL 条目。我们可以在任何时候停止重播，并获得数据库当时的一致快照。因此，该技术支持时间点恢复：可以在进行基本备份后的任何时间将数据库恢复到其状态。

• 如果我们不断地将一系列 WAL 文件提供给另一台已经加载了相同基本备份文件的机器，我们就有了一个热备用系统：在任何时候我们都可以启动第二台机器，它会有一个几乎最新的副本数据库。

然后，您只需将WAL目录的内容复制到您选择的目标位置或备份这些文件，并在旧文件备份到安全位置后删除旧文件。

一般建议

阅读官方 PostgreSQL 文档中的第 25 章备份和恢复部分。如果您无法理解如何实施备份策略，请联系可以支持您实施解决方案的顾问。没有什么比没有数据库备份更糟糕的了。

拥有基本备份将部分覆盖您。如果您可以每天运行它，那么您就成功了一半。但如果这不可行，那么您至少必须设置 WAL 归档。