PostgreSQL备份简介

数据库中的备份是必不可少的。它们是保护您免受哪怕是最小的数据丢失的安全网。备份数据的方法有很多种，这篇文章旨在解释备份涉及的基本工具，以及从刚开始到更复杂的生产系统，您有哪些选择。

pg_dump/pg_restore

Pg_dump和pg_dumpall是用来生成文件并允许恢复数据库的工具。这些备份被分类为逻辑备份，它们的大小可能比物理备份小得多。这在一定程度上是因为索引没有存储在SQL转储中。仅存储CREATE INDEX命令，从逻辑备份恢复时必须重新构建索引。

SQL转储方法的一个优点是输出通常可以被重新加载到更新版本的Postgres中，因此转储和恢复在版本升级和迁移中非常流行。另一个优点是这些工具可以配置为备份特定的数据库对象而忽略其他对象。这是有帮助的，例如，如果只需要在测试环境中提出表的某个子集，或者您希望在执行一些有风险的工作时备份单个表。

Postgres转储在内部也是一致的，这意味着转储表示进程启动时数据库的快照。转储通常不会阻止其他操作，但它们可以长时间运行(即几个小时或几天，这取决于硬件和数据库大小)。由于Postgres用于实现并发的方法(称为多版本并发控制)，长时间运行备份可能会导致Postgres在转储完成之前性能下降。

要转储单个数据库表，可以运行如下命令:

pg_dump -t my_table > table.sql

要恢复它，运行如下命令:

psql -f table.sql

 pg_dump作为损坏检查

Pg_dump在创建文件时顺序扫描整个数据集。读取整个数据库是对所有表数据的基本损坏检查，但不是对索引。如果数据损坏，pg_dump将抛出异常。Crunchy通常建议使用amcheck模块进行损坏检查，特别是在可能涉及排序规则的某种升级或迁移期间。

服务器和文件系统备份

如果您来自Linux管理世界，您习惯于使用rsync或其他工具备份运行数据库的整台机器的选项。Postgres不能在运行时使用面向文件的工具进行安全备份，也没有简单的方法来暂停写入。要使数据库进入可以保存数据的状态，您要么必须关闭数据库，要么必须完成设置更改归档的所有工作。对于支持整个数据目录快照的存储层，还有一些其他选项——但请阅读这些选项的详细说明。

物理备份和WAL归档

除了基本的转储文件，更复杂的Postgres备份方法都依赖于保存数据库的Write-Ahead-Log (WAL)文件。WAL跟踪对所有数据库块的更改，将它们保存到默认大小为16MB的段中。服务器WAL文件的连续集称为它的WAL流。在安全复制数据库之前，您必须开始归档WAL流的文件，然后执行生成“Base Backup”的过程。即pg_basebackup。WAL的增量特性使得Point In Time Recovery工具下的一系列其他恢复特性成为可能。

使用pg_basebackup创建一个basebackup:

你可以这样使用:

$ sudo -u postgres pg_basebackup -h localhost -p 5432 -U postgres \

-D var/lib/pgsql/15/backups -Ft -z -Xs -P -c fast

上面的命令有一些注释。

此命令应以postgres用户运行。

-D参数指定保存备份的位置。

-Ft参数表示应该使用tar格式。

-Xs参数表示WAL文件将流到备份。这很重要，因为在进行备份时可能会发生大量的WAL活动，在此期间您可能不希望在主数据库中保留这些文件。这是默认行为，但值得指出。

-z参数表示压缩tar文件。

-P参数表示在进程期间将进度信息写入标准输出。

-c fast参数表示立即使用检查点。如果未指定此参数，则在Postgres自己发出检查点之前不会开始备份，这可能会花费大量时间。

使用pg_basebackup进行备份恢复的步骤

它们是从官方文件中简化出来的。如果您正在使用表空间等特性，则需要针对您的环境修改这些步骤。

1.确保数据库处于关闭状态。

$ sudo systemctl stop postgresql-15.service

$ sudo systemctl status postgresql-15.service

2.删除Postgres数据目录的内容以模拟灾难。

$ sudo rm -rf var/lib/pgsql/15/data/*

3.将base.tar.gz解压到data目录中。

$ sudo -u postgres ls -l var/lib/pgsql/15/backups

$ sudo -u postgres tar -xvf var/lib/pgsql/15/backups/base.tar.gz \

-C var/lib/pgsql/15/data

4.将pg_wal.tar.gz解压到数据目录之外的一个新目录中。在本例中，我们在备份目录中创建了一个名为pg_wal的目录。

$ sudo -u postgres ls -l var/lib/pgsql/15/backups

$ sudo -u postgres mkdir -p /var/lib/pgsql/15/backups/pg_wal

$ sudo -u postgres tar -xvf /var/lib/pgsql/15/backups/pg_wal.tar.gz \

-C /var/lib/pgsql/15/backups/pg_wal/

5.创建recovery.signal文件

$ sudo -u postgres touch /var/lib/pgsql/15/data/recovery.signal

6.设置postgresql.conf中的restore_command命令来复制备份过程中的WAL文件流。

$ echo "restore_command = 'cp /var/lib/pgsql/15/backups/pg_wal/%f %p'" | \

sudo tee -a /var/lib/pgsql/15/data/postgresql.conf

7.启动数据库。

$ sudo systemctl start postgresql-15.service sudo systemctl status

postgresql-15.service

8.现在，基于之前basebackup中包含的信息，数据库已经启动并运行了。

自动化物理备份

在pg_basebackup的基础上，您可以编写一系列脚本来使用此备份，向其添加WAL段，并管理完整的物理备份场景。有几个工具，包括WAL-E, WAL-G和pgBackRest，可以为你做所有这些。WAL-G是WAL-E的下一代，适用于相当多的其他数据库，包括MySQL和Microsoft SQL Server。WAL-G也被广泛用于企业级的一些大型Postgres环境，包括Heroku。当我们第一次创建Crunchy Bridge时，我们在WAL-G和pgBackRest之间做出了选择，因为我们雇佣了两者的维护者，而且每个都有自己的好处。最后，我们选择了pgBackRest

pgBackRest

pgBackRest是同类中最好的备份工具。有许多非常大的Postgres环境依赖于pgBackRest，包括我们自己的Crunchy Bridge, Crunchy for Kubernetes, Crunchy Postgres以及Postgres生态系统中的无数其他项目。

pgBackRest可以执行三种类型的备份:

完全备份——将数据库集群的全部内容复制到备份。

差异备份——仅复制自上次完全备份以来更改的数据库集群文件

增量备份——仅复制自上次完整备份、差异备份或增量备份以来更改过的数据库集群文件。

pgBackRest有一些特殊的功能，比如:

1.允许您回到一个时间点- PITR(时间点恢复)

2.创建Delta还原，它将使用已经存在并基于WAL段更新的数据库文件。这使得潜在的恢复更快，特别是如果你有一个大的数据库，不想恢复整个东西。

3.允许您拥有多个备份存储库—例如一个本地存储库或一个远程存储库以实现冗余。

关于存档，用户可以设置archive_command参数，使用pgBackRest将WAL文件复制到外部存档。根据组织的数据保留策略，这些文件可以无限期保留或过期。

要在安装后启动pgBackRest，您将运行如下命令:

$ sudo -u postgres pgbackrest --stanza=demo --log-level-console=info stanza-create

要做增量恢复:

$ sudo systemctl stop postgresql-15.service

$ sudo -u postgres pgbackrest \

--stanza=db --delta \

--type=time "--target=2022-09-01 00:00:05.010329+00" \

--target-action=promote restore

恢复完成后，重新启动数据库并验证users表已经恢复。

$ sudo systemctl start postgresql-15.service

$ sudo -u postgres psql -c "select * from users limit 1"

备份时间

pgBackRest具有相当广泛的设置和配置，可以根据您的需要设置特定的策略。备份策略取决于几个因素，包括恢复点目标、可用存储和其他因素。正确的解决方案将根据这些需求而变化。为您的用例找到正确的策略是在恢复时间、使用的存储、源数据库上的IO开销和其他因素之间取得平衡的问题。

我们通常的建议是结合pgBackRest的备份和WAL归档功能。我们通常建议客户在连续归档WAL文件之外，每周进行一次完整的基础备份，并考虑其他增量备份形式(甚至可能是pg_dump)是否适合您的需求。

结论

为您的用例选择备份工具将是基于您的需求、恢复时间的容忍度和可用存储的个人选择。通常，最好将pg_dump视为执行特定数据库任务的实用程序。如果您对特定时间的单个物理备份没有问题，Pg_basebackup可以是一个选项。如果您有一个规模较大的生产系统，并且需要创建灾难恢复场景，那么最好在基础备份之上使用WAL段实现pgBackRest或更复杂的工具。当然，也有完全管理的选项，如Crunchy Bridge，它将为您处理所有这些问题。

PG考试咨询