PostgreSQL 怎么决定PG 的备份策略 （翻译）

备份数据库是一个在灾难恢复如服务器 crash， 数据库crash, 或者其他灾难发生时，你快速将你维护的数据库能进行安全恢复的重要的保证。这无关于你的数据库运行在docker ， 虚拟机，或者在云端去备份一个数据库都是十分重要的。与此同时，决定一个备份和恢复的策略无论对于公司还是个人都是一个比较难的问题。进行这个问题的考虑是需要你懂得你的应用， 以及应用所在的行业，以及成本等问题，下面我们就开始看看如何对备份的此类进行选择。

这里有一个情况，我们对其进行深入。

我有一个PG基于电商的应用，数据库的尺寸并不大，100GB。活跃的用户会持续到下午7左右，同时大部分客户是不会24小时进行持续性的访问，我们对数据库进行 full 的逻辑备份，在每天晚上12:00AM， 大约会花费2个小时左右，这是我们每天都会进行的日常工作。

在周一早上10点，我们发生一个系统级别的crash， 数据库的磁盘挂掉了，我们唯一的选择就是重新创建数据库从我们的备份集中选择曾经做过的逻辑备份。大约我们花费了3个小时来恢复数据库，同时我们在恢复完毕后，我们做了一些回归测试功能测试等，系统在下午2点开始工作。

让我来强调2点

1 数据库是恢复前一天夜间的数据，10个小时的数据库我们丢失了

2 4个小时的应用down机的时间

什么是 RPO recovery point objective 和 RTO recovery time objective ,RPO 是衡量最大丢失数据库承受力的一个维度，他帮助你来衡量，在两次备份之间，灾难发生中你没有数据库备份中遭受到的损失的问题，这主要是针对你的业务来说的。

PRO是一个重要的标志，因为在大多数的CASE 中，你会面对在灾难发生时你丢失数据的问题。即使你实时去备份数据，也有可能造成数据的丢失。大多数企业都会在固定的时间间隔内备份数据——每小时一次、每天一次，或者更少的是每周一次。RPO衡量由于灾难您可以承受多少数据丢失。

举例，你每天备份数据是在午夜进行的，灾难发生在早上8点，换句话你丢掉的是8小时夜间的数据，如果你的RPO 设定的是24小时或更长，那么丢了8小时的数据库也是OK，但是如果你的RPO 是4个小时，那么你就的考虑一下了。

RTO

Recovery time Objective 是一个度量和计算你快速恢复应用和数据库的时间，并且如何快速的恢复业务和数据库保证业务的连续性的问题。

RTO是根据业务在灾难后恢复正常之前能够存活多长时间来衡量的。如果您的RTO是24小时，这意味着您已经确定业务可以在没有正常数据和基础设施可用的情况下维持该时间的操作。如果数据和基础设施不能在24小时内恢复，业务可能会受到无法弥补的损害。

所以制定业务的RPO 和 RTO 后就直接可以确认你的备份的策略是什么，关于你POSTGRESQL 核心的备份的此类包含了：

备份的方法 （在线，离线，逻辑）

使用何种间隔来对数据库进行备份 （每周，每天，每小时）

基于以上的假设对于PG 在备份数据库方面以及最小数据丢失方面，我们有如下的建议

1 打开你的POSTGRESQL 的 archiving 功能，将你的wal 日志存储在一个安全的地方

2 在线进行FULL backup 并且基于增量和归档备份

每周全备

每天午夜进行日增量的备份

我们可以使用基于PITR 的数据库的恢复模式，基于你有全量备份和归档的增量的archive 文件的最后时间点的数据恢复模式。

基于当前的环境，常用的备份模式有那些

基于数据库工程师专业的经验，我已经认识到如果仅仅凭着数据库的大小SIZE来决定数据库的备份的策略，并不是一件明智的事情。虽然对于某些情况，将在线数据和逻辑数据(pg_dump/pg_dumpall)结合起来是一个好主意，但是应该考虑它是什么类型的数据，以及在灾难性的情况下准备损失多少数据。

1 对关键业务数据库和生产数据库进行每周在线备份和每日增量备份。 2 非关键数据库或开发数据库的逻辑备份—频率—每周或两周。

替换的方法

实际上最常见的备份方式或者说大多数的备份方式是通过pg_basebackup 或者在数据库进入到备份模式后，对文件进行COPY 的方式进行数据备份。然而，如果在磁盘界别另一个方案是针对存储管理中对磁盘进行快照的方式，这样会更快，尤其在你有一个非常大的数据库的情况下 （2T）

如何让RPO 和 RTO 达标

现在我们已经明白了RPO 和 RTO 对于我们的商业系统的重要性，下面是最常用的和比较不错的关于如何减少 RPO RTO的方法：

带故障自动转移的数据库同步复制模式

如果你不能接受丢失数据的问题如你的业务是关键的核心业务场景，如银行机构，金融机构，这里可以通过PG的同步复制的方式来帮助你确认你的数据的已经在数据库中commit ，这里备库就作为一个standby 的模式存在，实际上你可以在任何灾难的情况下，通过自动或手动转换到 standby的模式来减少RTO和RPO的问题，需要说明的是在应用事务未提交的情况下，是不保证数据不丢失的，同时还会降低应用程序的在某些情况下的性能。

异步复制中使用自动failover

流同步是常用的PG的数据库复制的方式，两个数据库之间会有比较小的延迟，在事务的执行过程中，在主库变为可见，而在从库不可见，这个时间段我们称之为延迟。

然而，这种延迟比基于文件的日志传送要小得多，而且还取决于负载/事务和网络带宽。对于流复制，不需要archive_timeout来减少数据丢失窗口。我们还看到一些客户使用延迟24小时的备用服务器来处理某些恢复情况，在这种情况下，用户不小心掉了一个表，而延迟的备用服务器可以帮助恢复它。

异地灾难恢复

Postgresql 允许你创建一个异地的灾难恢复站点基于write ahead log数据传输的模式，这对于确保在另一个区域或数据中心拥有数据库的最新副本尤其重要，以防出现整个数据中心丢失或无法访问的灾难场景。您可能或可能无法承受数据丢失的打击(恢复点目标)，但RTO将减少，即使站点完全消失。

结论：

创建一个成功的备份和恢复的策略是基于理解业务和用户的需求的基础上，你需要让你的系统在什么状态下，来面对客户重要的数据和这些数据库的恢复速度的问题。这里帮助我们来定义RTO 和RPO ，发现正确的基于backup, standby, DR 策略的正确解决方案，并且进行测试确认和最终的部署。