李明，熟悉数据库逻辑复制场景，基础软件国产化拥泵，现就职于瀚高基础软件股份有限公司逻辑复制组。
崔鹏,任职于海能达通信股份有限公司,数据库开发高级工程师,致力于postgresql数据库在专网通信领域、公共安全领域的应用与推广。
对数据库进行备份，是数据库管理的基本要求，是从数据库灾难场景（例如服务器宕机、数据库崩溃或损坏）中恢复数据的基本保证。无论数据库是运行在Docker，VM或云上，数据库备份都至关重要。话虽如此，但无论对于个人还是组织，如何决定数据库的备份恢复策略，都是一个难题。这要求对于你所用的应用程序、业务逻辑以及成本有个较为深入的了解。那么，让我们开始学习，如何理清头绪，从哪里开始以及如何选择PostgreSQL数据库的备份策略。
这里有一个以PostgreSQL为后台数据库的电子商务应用程序。数据库大小约100GB左右。大部分用户活跃到晚上7点左右，此后业务系统基本处于空闲状态。我们设置的备份策略为每天凌晨12点进行逻辑全备，备份大约耗时2小时，然后我们会进行一些日常的数据库清算操作。不幸的是，在星期一早上10点，系统崩溃了，导致数据磁盘损坏。我们唯一的选择就是从头开始，重新创建数据库，并使用最近的逻辑备份进行数据恢复。恢复数据库耗费了约3小时。在进行了一系列整理和基本功能测试后，应用程序在下午2点恢复正常。1. 该数据库从夜间的备份恢复。即，有10个小时的数据丢失。->丢失数据的多少，或者说能恢复到的时间点，对你来说有多重要？2. 4个小时的业务宕机时间。->可以多快恢复数据库并使业务可用？
何为还原点目标（RPO,Recovery Point Objective）和恢复时间目标（RTO,Recovery Time Objective）？
还原点目标（RPO）
还原点目标是对于能够容忍的最大丢失数据量的度量。也用以衡量在最新数据库备份与故障发生之间的时间差。RPO用以决定PostgreSQL的备份频率。RPO很重要，因为在大部分场景下，当故障发生时，很有可能会造成数据丢失。即使数据备份是实时的，也有丢失数据的风险。而大部分业务系统会周期性备份数据，比如每小时一次、每天一次，更有甚者，每周一次。RPO衡量了当故障发生时，你能承担的数据丢失量。例如，假设在每天的半夜备份数据库，而在某天的早晨八点，故障发生了。那么，你就会丢失八个小时的数据。如果RPO设定为24小时或更长时间，那么还能接受；但是如果RPO设定为4小时或更少，那么这就是不能接受的了。恢复时间目标（RTO）
恢复时间目标是用以衡量在故障后需要多快速恢复业务（应用程序及数据库）和服务的指标，用以维持业务的持续性。RTO用以衡量，在故障发生之后恢复正常业务所需的时间。例如，RTO设定为24小时，则意味着，企业可以在没有正常数据及基础架构可用的情况下，在该时间段维持运转。但是如果数据及其基础架构在24小时内未恢复正常，那么企业将遭受无可挽回的损失。需要根据设置的目标（RPO及RTO）决定备份策略。请谨记，PostgreSQL备份策略包含以下方面：在上例中，若想实现最小数据丢失，可采用以下备份策略：然后在故障发生时，就可以进行时间点还原，即，通过使用全备还原数据库，然后使用增量备份（归档的WAL文件）恢复到最近的时间点。最常用的PostgreSQL备份策略（视具体情况而定）
基于多年的数据库管理经验，我发现仅仅根据数据库的大小而制定备份策略是不明智的。在某些场景下，同时结合在线备份和逻辑备份（pg_dump/pg_dumpall）是一个不错的策略，但是，需要同时将数据的类型以及在灾难故障情况下能够容忍的数据丢失考虑在内。1. 关键数据库以及生产数据库，每周在线备份+每天的增量备份；2. 非关键或开发数据库，每周或每两周一次逻辑备份；其他备份方法
其中一种较为常用的备份方法，是在将数据库更改到备份模式后，使用pg_basebackup进行在线备份或者进行文件系统级别的备份（直接拷贝整个数据文件目录）。另外，如果对磁盘使用存储管理，那么可以使用磁盘级别的快照进行备份。且对于大数据库（超过2TB）来说，卷级别的快照会更快、更有用。如何缩减RPO及RTO？
现在，我们对于RPO及RTO的用法及其对于业务系统的重要性有了较为初步的了解。以下为在数据库级别缩减RPO及RTO的最佳实践：l 具有自动故障转移的同步复制：如果无法承受数据丢失（关键业务、银行业、金融组织），那么使用PostgreSQL的同步复制绝对能够提供帮助，它能确保在备节点有业务库所有已提交的数据备份（取决于具体的同步模式）。一旦故障发生，可以自动或者手动切换到备端，以显著缩短RTO及RPO。可以通过设置应用程序等待提交成功后再结束事务，以确保没有数据丢失。不过，PostgreSQL的这种同步复制的设置可能会增加应用程序性能的额外开销。l 具有自动故障转移的异步复制：流复制默认复制方式为异步复制，此种方式下，主库已提交事务与该事务在备库执行之间会有一段较小的延迟。该延迟大小取决于压力/事务以及带宽，但该延时比基于文件的日志传输要小很多。使用流复制时，无需设置archive_timeout来减小数据丢失窗口。我们还见过客户使用具有24小时延迟的备库以应对某些特殊的恢复场景，比如用户不小心删掉了一张表，那么延迟的备库可以用来恢复该表（需要在24小时内发现该意外行为）。
l 考虑设置灾难恢复站点：PostgreSQL可通过使用WAL在另一区域设置灾难恢复站点。对于当整个数据中心不可用或无法访问的任何灾难故障情况下，确保在另一个区域或数据中心拥有最新的数据库副本，至关重要。您可能会或可能无法承受数据丢失（RPO），不过即使数据中心完全丢失，也能缩短RTO时间。
总结
一个备份策略成功的关键是理解终端用户以及业务。这可以帮助你明白，当灾难故障发生的时候，你的数据有多重要以及需要多快恢复业务系统正常。这能帮助我们确定RTO及RPO目标。并据此找到正确的解决方案（无论是备份、主备或任何灾难恢复策略），且确保进行充分的可用性测试并最终进行部署实施。
请点击文章底部“阅读原文”查看原文
