到现在为止，您已经掌握了一定的理论。因为生活不仅由理论组成(它可能同样重要)，是时候深入实际的工作了。

本章的目标是让您明白如何恢复数据到一个给定的时间点。当您的系统崩溃或者有人意外地删除了一个表，不重放整个事务日志，而是重放 其中的一小部分，这是非常重要的。即时恢复(PITR，Point-In-Time-Recovery)将是做这种部分事务日志重放的工具。

在本章中，您将学到关于即时恢复(PITR)的所有您需要知道的信息，并且会有实际的例子来引导您。因此，我们将应用所有您已经在第二章所学习的概念，理解 PostgreSQL 事务日志，建立增量备份或者设置一个简单的，基本的备份系统。

下面是我们将在本章讲解的主题的概述：

• 理解 PITR 背后的概念

• 配置 PostreSQL PITR

• 运行 pg_basebackup

• 恢复 PostgreSQL 到一个特定的时间点

3.1 理解PITR的作用

PostgreSQL 提供了一个可以备份一个数据库的工具，叫做pg_dump。基本上，pg_dump 会连接到数据库，读取事务隔离级别“序列化”所有的数据，并把数据以文本的形式返回。由于我们使用的是“序列化”，转储始终保持一致。所以，如果您的pg_dump 在午夜开始，结束于上午六点。您将创建一个备份，其包含截至午夜的所有数据，但没有进一步的数据。对从少量到中量的数据来说，这种快照创建是非常方便，并且是完全可行的。

[转储始终保持一致。这意味着所有的外键都完好无损；开始转储后，新添加的数据将丢失。这可能是最有可能的执行标准备份的最常见的方式。]

但是，如果您的数据是如此宝贵并且规模也是如此之大，以至于您要对它进行整理备份；对于高度关键的数据，它显然不是。除此之外，以文本形式重放20TB的数据效率也不高。已经设计了即时恢复来解决这个问题。它是如何工作的呢？基于数据库的快照，稍后，XLOG 将会被重放。这可以无限制地执行，或者到一个您选择的时间点。通过这种方式，您可以到达任何时间点。此方法打开了许多不同的方法和功能的大门。

• 还原数据库实例到一个给定的时间点

• 创建一个备份数据库，其中包含原始数据库的副本

• 创建一个所有更改的历史记录

在本章中，我们将专门研究增量备份的功能。并描述如何通过增量归档改变一个选择的媒介使您的数据更安全。

3.1.1移动到架构角度

下面的图片提供了一个使用即时恢复的通用架构图的概貌：

我们已经在前面的章节看到PostgreSQL产生16MB的事务日志段。每当这些段中的一个被填满并准备就绪是，PostgreSQL将调用所谓的archive_command。archive_command 的目的是把 XLOG文件从数据库实例传输到存档。在我们的图片中，归档在图片的右下角的小方框表示。

该设计的妙处在于，您基本上可以使用任意的shell脚本来归档事务日志。这里有一些想法：

• 使用一些简单的复制来传输数据到一个NFS共享

• 运行 rsync 来移动文件

• 使用定制脚本来校验XLOG文件并将其移动到一个FTP服务器

• 复制 XLOG 文件到磁带

可能的管理XLOG的选择值受到想象力的限制。

restore_command 准确地与archive_command 相对应。它的作用是从归档获取数据并将其提供给实例，这是为了重放它(在我们的图片中，这被标记为还原备份)。正如您所看到的，如本章所述，重放可能被用于复制或者仅仅恢复一个数据库到一个给定的时间点。同样，restore_command 只是一个简单的可以一个文件一个文件地做您所希望的事情的脚本。

[ 作为全能的管理者的您负责归档是很重要的。您必须决定保持多少的XLOG，什么时候删除它。这项任务的重要性不能被低估。]

请记住，当由于某种原因archive_command 失败时，PostgreSQL 将保持XLOG文件几秒钟后会重新尝试。如果归档从某个特定的点不断地失败，可能是master填满了。XLOG文件的顺序不能被中断；如果一个文件丢失了，您就不能继续重放XLOG了。所有的XLOG文件必须存在，因为PostgreSQL需要一个序列不间断的XLOG文件。如果一个文件丢失，恢复进行将停止在最新的位置。