9.1第二十四章

第24章.备份和恢复

目录

24.1．SQL 转储

 24.1.1．恢复转储
 24.1.2．使用 pg_dumpall
 24.1.3．大型数据库的处理

24.2．文件系统级备份

24.3．连续归档和point - in - time恢复（PITR）

 24.3.1．设置的WAL归档
 24.3.2．制作基础备份
 24.3.4．时间表24.3.3．使用连续存档备份恢复
 24.3.5．技巧和范例
 24.3.6．注意事项

正如一切都包含有价值的数据， PostgreSQL的 数据库应定期备份。 虽然过程基本上很简单，重要的是但是对基础技术和假设有一个清醒的认识。

基本上有三种不同的方法来备份 PostgreSQL的 数据：

  .SQL 转储
  .文件系统级别的备份
  .连续归档

每个都有自己的长处和短处，在接下来的几节将依次讨论。

24.1． SQL 转储

这个转储方法的想法是生成一个SQL命令文本文件，当反馈到服务器，将创建一个同转储时刻相同状态的数据库。 PostgreSQL提供了使用的程序pg_dump来实现这一目的。这个命令的基本用法是： pg_dump dbname >outfile

如你所见， pg_dump把其结果写入到标准输出。 接着我们将看到它如何能派上用场。

pg_dump是一个普通 的PostgreSQL 客户端应用程序（尽管是特别聪明的一个）.这意味着你可以在已连接上数据库的任何远程主机执行此备份程序。 但是请记住 pg_dump的运行并不具有特殊的权限。 特别是，它必须具有你要备份的所有表的读取权限，所以在实践中你几乎总是要作为一个数据库超级用户来运行它。

要指定pg_dump要连接的数据库服务器 ，使用命令行选项 - h host 和 - p port 。 缺省主机是本地主机或任何你指定了PGHOST 环境变量的。 同样，默认端口是PGPORT的 环境变量所指定的 ，如果不能，则是编译时默认值。（方便快捷，服务器通常有相同的编译时默认值。）

像任何其它的PostgreSQL 客户端应用程序，pg_dump的将默认用与目前的操作系统的用户名一样的数据库用户名进行连接。 要取消这个，或指定 - u 选项或设置环境变量 PGUSER 。记住 pg_dump的连接都必须遵照正常的客户端认证机制（这是在第19章介已经介绍了。）。

pg_dump和在后面介绍的其他备份方法相比的一个重要的优势就是： pg_dump的导出文件一般都可以重新加载到新版本的PostgreSQL，而文件级备份和连续归档都是因服务器版本而异。 pg_dump也是唯一一个将一个数据库转移到不同的计算机体系结构的方法，如从32位到64位服务器。

通过创建转储 pg_dump的 是内部一致的，也就是说，转储展现的是一个在 pg_dump开始运行时的数据库快照。 当pg_dump在运行时不会妨碍数据库上的其他操作。（例外的是那些需要具有排他锁来运行的操作，如大多数的ALTER TABLE ）。

    重要： 如果您的数据库模式依赖于OIDs(例如，作为外键)您同样必须指示pg_dump转储OIDs。 要做到这一点，使用-o 命令行选项。

24.1.1. 恢复转储

pg_dump创建的文本文件 旨在让psql程序能读取。 用来还原转储文件的一般的命令格式：

   psql  dbname <  infile

其中的infile是由pg_dump命令输出的文件。该数据库 dbname将不会被这个命令创建，所以你必须自己在执行psql之前从template0创建它 （例如，用 createdb - T template0 dbname）。 psql支持类似 pg_dump用于指定要连接的数据库服务器与要使用的用户名的参数选项。 请参阅 psql的参考页面来获取更多信息。

在恢复一个SQL转储前，拥有对象或在对象上被赋权的所有用户必须已经存在于转储的数据库中。 如果他们不这样做，恢复将在重建原始的所有权及权限的对象时失败。（有时这是你想要的，但通常事实并非如此。）

默认情况下，在遇到一个SQL错误后psql脚本将继续执行。 当一个SQL错误发生时，你可能希望运行 psql的 ON_ERROR_STOP 变量设置来改变这种行为并让 psql在退出状态为3的时候退出。

    psql  --set ON_ERROR_STOP =on  dbname  <  infile

总之，你只会有一个部分恢复数据库。 另外，您可以指定整个转储用一个但单事务来恢复，所以恢复要么全部完成或全部回滚。 这种模式可通过传递 -1 或 –single-transaction 的命令行选项给psql来指定。当使用此模式时，要意识到，即使是轻微的错误也可能让恢复回滚，不管是否已经运行了很多个小时。 不管怎样，在转储部分恢复后，手动清理一个复杂的数据库可能仍然是可取的。

pg_dump和 psql从管道写入或读出的能力，这使得直接从一台服务器到另外一个转储数据库成为可能，例如：

    pg_dump – h  host1  dbname | psql  -h  host2  dbname

要点： pg_dump产生的转储是与template0相关的。 这意味着，任何语言，程序等，通过template1添加的，也会被pg_dump转储 。 因此，当恢复时，如果您使用的是自定义的template1 ，你必须从template0创建空的数据库，如上面的例子。

在还原备份后，，在每个数据库中运行ANALYZE是明智的，这样查询优化器就会获取一些有用的统计数字，见 第23.1.3节 和 第23.1.5节来获取更多信息。 为了获取更多关于如有效的在PostgreSQL中加载较大数据的意见，参考14.4节 。

24.1.2. 使用 pg_dumpall

pg_dump同一时间只能转储一个单一数据库，并且它不会转储角色或表空间信息（因为这些都是集群范围内，而不是每个数据库）。 为了支持方便转储一个数据库集群的全部内容，该 pg_dumpall 程序被提供。 pg_dumpall 在某个集群中备份给每个数据库中，并保留像角色和表空间的定义等群集范围内的数据。 这个命令的基本用法是：

  pg_dumpall> outfile

由此产生的转储可以用psql来恢复：

  psql  - f  infile  postgres

（实际上，您可以指定任何现有的数据库名称来开始，但如果你加载到一个空的集群，这样postgres 通常就会被用到。）当还原 pg_dumpall 的转储时，总是需要有数据库超级用户访问，因为这是需要恢复角色和表空间的信息。如果您使用表空间，确保在在转储中的表空间路径是适合新安装。

pg_dumpall 的工作原理是靠发出命令来重新创建角色，表空间，空数据库，然后为每个数据库调用 pg_dump。 这意味着，当每个数据库会内部一致，不同的数据库快照可能不完全同步。

24.1.3．处理大型数据库

有些操作系统具有最大的文件大小限制，导致创建大型pg_dump输出文件c产生问题。 幸运的是， pg_dump可以写入到标准输出，所以你可以使用标准的Unix工具来解决这个潜在的问题。 有几种可能的方法：

使用压缩的转储。 您可以使用你最喜欢的压缩程序，比如gzip：

  pg_dump dbname | gzip > filename.gz

重新加载：

  gunzip -c filename.gz | psql dbname

或：

  cat filename.gz | gunzip |  psql doname

使用split 。这个split 命令允许您将输出文件分割到小文件，这样在当下的文件系统变的可接受。 例如，为了生存一个1m的块：

  pg_dump doname | split -b 1m -filename

重新加载：

  cat filename* | psql doname

使用pg_dump的自定义转储格式。 如果PostgreSQL安装到系统中是用zlib的压缩包安装的，压缩数据会按自定义转储格式写入到输出文件。 这将产生转储文件大小类似于使用 gzip ，但它有额外的好处，表可以选择性地恢复。 以下命令使用自定义格式转储转储数据库：

  pg_dump - Fc  doname> filename

自定义格式转储是不是psql的脚本 ,而是必复用pg_restore来须恢 ,例如：

  pg_restore -d dbname filename

请参阅pg_dump和pg_restore参考页获取细节详情。

对于非常大的数据库，您可能需要结合split和其他一个或两个。

24.2． 文件系统级别的备份

另一种可选的备份策略是直接复制在数据库中PostgreSQL 用来存储数据的文件; 第17.2节说明这些文件的位置。 你可以使用任何你喜欢的方来作文件系统备份，例如：

  tar -cf backup.tar  / usr/local/pgsql/data

有两个限制，然而，这使这一方法不切实际，或至少不亚于 pg_dump方法：

1.数据库服务器必须被关闭以获得一个可用的备份。 中途措施，不准所有的连接将无法工作（部分原因是 tar 和类似工具不会获取文件系统的器原子快照，而且还因为还有内部缓冲在服务器中）。 有关停服务器相关资料可以在17.5节中找到。 不用说，你也需要在数据恢复之前关闭服务器。

2.如果您有深入挖掘据库文件系统数布局的细节，你可能总想尝试从各自的文件或文件夹中备份或还原某些单个表或数据库。这将不会起作用，因为这些文件中包含的信息如果没有提交的日志文件是无法使用的， pg_clog / * ，其中包含所有事务的提交情况。 表文件只有拥有这些信息才是可用的。 当然，只恢复一个表和相关 pg_clog 数据也是不可能，因为这会使数据库集群中所有其他表作废。因此，文件系统备份仅适用于整个数据库集群的完整的备份和恢复。

另一种可选的文件系统的备份方法近似于给数据目录做一个“一致的快照”，如果文件系统支持这个功能（而且你愿意相信这是正确的应用）。典型的过程是对包含数据库的卷做一个“冻结快照” ，然后从快照复制整个数据目录（不只是部分，见上文）到备份设备，然后释放被冻结的快照。 这个方法在当数据库服务器正在运行的时候也能用。 然而，用这种方式创建的备份就像把数据库文件保存在一个数据库服务还没完全关闭一样的状态下;因此，当你从备份数据上启动数据库服务时，它会认为以前的服务器实例崩溃了而且会重新运行WAL日志。这不是一个问题，只是意识到它（并且确保WAL文件包含在您的备份中）。 您可以快照之前运行CHECKPOINT以减少恢复时间。

如果你的数据库是分散在多个文件系统，则可能没有任何方式来获得所有卷的精确同时的冻结快照。 例如，如果您的数据文件和WAL日志已在您外一个不同的磁盘上，或者，如果表空间在不同的的系统文件，它可能无法使用快照备份，因为快照必须是同时发生的。在这种情况下，在确信一致快照技术之前您一定要非常仔细的阅读文件系统文档。

如果同时快照是不可能的，办法之一就是关闭数据库服务器足够长时间，以建立所有被冻结快照。另一种选择是执行一个以备份为基础的连续归档（第24.3.2），因为这样的备份在备份过程中不会受到系统变更影响。这需要在备份过程中能连续归档;恢复是通过使用连续归档恢复(第24.3.3)。

另一种方法是使用 rsync执行文件系统备份。在数据库服务器在运行时第一次运行rsyn，然后关闭数据库服务器足够长的时间来做第二次rsync。第二rsync将远远快过第一次，因为它有相对少的数据传输，而最终结果将是一致的，因为服务器已经关闭了。这种方法允许一个文件系统备份用最少的停机时间进行。

请注意，文件系统备份通常会大于一个SQL转储。(pg_dump不需要转储示例索引的内容，只是来重新创建它们的命令。)不管怎么说，采取文件系统备份可能会更快些。

24.3. 连续归档和即时恢复（PITR）

在任何时候，PostgreSQL维护在群集数据目录的子目录pg_xlog /下的一个预写入日志（WAL）。这个日志文件记录了任何对数据库数据文件的更改。这个日志的存在主要目的是用于崩溃安全(crash-safety)目的:如果系统崩溃，数据库通过 “重播” 从最后检查点以来产生的日志条目可以恢复一致。 不管怎样，日志的存在性使人们有可能使用第三策略来备份数据库:我们可以结合文件系统级备和WAL文件备份。如果恢复是必要的，我们恢复文件系统备份，然后从备份WAL文件重新运行，把系统恢复到当前状态。这种方法对管理员来说比以前任意一个方法更复杂，但它有一些相当大好处：

.我们不需要一个从出发点完全一致的文件系统备份。在备份中任何内部不一致的地方将会通过在日志重做（这与崩溃恢复过程发生什么的没有什么显着不同的）被纠正。因此，我们并不需要一个文件系统快照功能，只需tar或类似的压缩工具。

.既然我们可以结合无限长的持续的重做WAL文件，连续备份可以简单的归档，只要继续归档WAL文件。这对于大型数据库而言是非常有价值的，特别当频繁去获取一个完整备份可能会很不方便。

.重做最终WAL条目一直到结束是没有必要的。我们能够阻止任何点的重做，并有一个一致的数据库快照，就像它在那个时候一样。 因此这种技术支持时恢复:有可能恢复状态，只要你基础备份做好了，在任何时间都能把数据库恢复到原始状态。

.如果我们不断地把一系列WAL文件到另一个加载了相同的基础数据文件的机器，我们有一个热备份 系统：在任何时候，我们可以让第二台机器达到和当前数据库副本几乎一样的状态。

注意：pg_dump和pg_dumpall不产生文件系统级备份，还不能当作持续归档解决方案中的一部分来使用。 这样转储在逻辑上不能包含足够信息用来做WAL重做。

由于与普通文件系统的备份技术，这种方法只能支持整个数据库集群，而不是一个子集的恢复。 此外，它需要大量的档案储存空间：基备份可体积可能很庞大，一个繁忙的系统会产生许多兆用来归档的WAL数据流。 然而，在许多需要高可靠性的情况下，这是首选的备份技术。

要使用连续归档（被许多数据库供应商称为 “在线备份” ）恢复成功，你需要一个向后延伸的连续的归档的WAL文件，至少到你开始备份的时侯。 因此要开始使用，在你把你做第一个基础备份之前，你应该设置和测试存档WAL文件的程序。 因此，我们首先讨论归档WAL文件的技巧。

24.3.1．设置WAL归档

在抽象意义上，正在运行的PostgreSQL系统产生无限长序列的WAL记录。该系统物理上划分这个序列到多个WAL段文件 ，通常每个段有16MB（但是在创建PostgreSQL时，段的大小可以改变）。该段文件给出序列数字名称来映射它们在抽象WAL序列上的位置。当不使用WAL归档，系统就通常只创建几个段文件，然后 “回收”它们，通过重命名不再需要的段文件到更高的段编号。这里假设这个段文件，其内容在最后检查点之前是没有使用价值和可以循环使用。

当归档WAL数据，在段文件被写满之前，我们需要获取每个段文件的内容，并在段文件被回收和重用之前保存到其某个地方。根据应用程序和可用的硬件，可能有许多不同的方式来 “保存数据到某个地方” ：我们可以复制段文件到NFS挂载的文件目录下，把它们写在磁带上（确保你有一个识别每个文件原名的方法），或者把它们批量的放在一起，然后全部刻录到光盘或其他什么东西上。为了给数据库管理员提供灵活性，PostgreSQL尝试对归档将如何做不作任何假设。相反，PostgreSQL允许管理员指定一个shell命令在执行后，复制一个完整的短文到任何它需要去的地方。该命令可以和cp命令一样简单，也可以调用一个复杂的shell脚本-------这一切都取决于你。

为了让WAL归档，开启archive（或 hot_standby ）的wal_level 配置参数，和archive_mode，并指定shell命令使用 archive_command 配置参数。在实践中这些设置将一直放置在postgresql.conf文件。在 archive_command ,％p被存档文件中的路径名称所替换，而 ％f 被替代的只有文件名。（路径名称是相对于当前工作目录，即簇的数据目录。）如果你需要在命令嵌入一个实际的％字符，那就使用％％。最简单有用的命令是这样的：

archive_command =’cp -i  %p /mnt/server/archivedir/%f  </dev/null’  #Unix
archive_command =’copy  “%p”  “c:\\server\\archivedir\\%f ” ’ #Windows

这样就会将WAL段文件复制到/ mnt /server/ archivedir目录。(这是一个例子，而不是建议，并且可能无法在所有平台上运行。）当 ％p和％f 参数已被取代，但实际执行的命令可能看上去像这样：

cp -i pg_xlog/00000001000000A900000065 /mnt/server/archivedir/00000001000000A900000065  </dev/null

类似的命令将会为每个要被存档新文件生成。

在PostgreSQL服务器正在运行的中的拥有相同所有权的用户的控制下，归档命令将被执行。由于系列被归档的WAL文件有效的包含一切东西在你的数据库中，你会想确保归档数据是被保护不被窥探的，例如，归档到一个没有用户组或领域科访问权限的文件目录。

重要的是归档命当且仅当它成功令时，返回零退出状态。当得到一个零结果，PostgreSQL将认为该文件已被成功地存档，并会删除或回收。然而，一个非零状态告诉PostgreSQL该文件没有被存档，它会定期再试，直到成功。

归档命令一般应设计为拒绝覆盖任何预先存在的存档文件。这是一个重要的安全功能，来使你的归档的完善不受到万一出现的管理员错误的影响（如把两个不同服务器的输出文件放到同一个文件目录) 。明智的做法是测试你预定的归档命令，以确保它确实不覆盖现有文件，并且它在此情况下返回非零状态。在许多Unix平台上，cp -i 会在覆盖文件之前提示是否覆盖，和 < /dev/null会让提示（和覆盖）失败。如果你的平台不支持这种特性，你应该添加一个命令来测试归档文件是否存。例如，像这样：

 archive_command = 'test ！-f /mnt/server/archivedir /%f && cp  %p  /mnt /server/archivedir/%f

能在大多数Unix变种上正常工作。

在设计你的存档的设置，考虑如果归档命令多次失败会发生什么，因为某些方面需要反复操作员干预或存档空间不足。例如，如果你没用自动转换器，就写入磁带，这就可能发生，当磁带填充时，没有空间可来继续归档，直到磁带切换。您应该确保任何错误状况或要求都被适当的报道的给一个人工操作员，这样这个情况都可以相当迅速的合理解决。这个pg_xlog /目录将继续用WAL段文件来填充，直至情况得到解决。 （如果文件系统包含pg_xlog / 填满，PostgreSQL会做一个PANIC关闭。没有提交的事务都将丢失，但数据库将保持脱机状态，直到你将释放一些空间。）

归档命令的速度不重要的，由于它可以保持与服务器生成WAL数据平均速率一致。即使存档过程有点落后了，正常运行任会继续。如果归档大幅落后，在灾难事件发生时，这会增加丢失的数据量。它也将意味着 pg_xlog / 目录将包含大量未尚未归档的段文件，这可能最终超过可用的磁盘空间。 建议您监控存档过程，以确保其按照你的计划正常工作。

在写你的档案命令时，你应该设想要归档文件名可达到64个字符长度，斌且可以包含所任何ASCII字母，数字，和点的组合体。保留原始的相对路径（％p）不是必要的，但是必需要保留文件名（％f）。

请注意，虽然WAL归档将允许您恢复在PostgreSQL数据库中对数据作出任何修改 ，它不会恢复对配置文件所做的更改（即 postgresql.conf，pg_hba.conf和pg_ident.conf），因为这些都是手动编辑而不是通过SQL操作。 你可能想保留配置文件在一个会被常规的系统备份程序备份的位置。参见第18.2节 如何重新部署配置文件。

归档命令只对已完成的WAL段进行调用。因此，如果你的服务器只产生很少的WAL流量（或有懒散的时期这样做了），有可能是在完成一个事务和它在归档存储中的安全记录之间产生了一个长期拖延。在怎样让旧的非归档数据可以做到上，加上一个限制，至少你可以经常设置archive_timeout来强制服务器切换到新的WAL段文件。请注意，归档文件过早的被归档是由于强制切换的仍然和完全充满的文件的同样一个长度。因此设置一个非常archive_timeout是一个非常不明智的----它会胀大你的归档存储。archive_timeout大约一分钟左右设置通常是合理的。

此外，如果你想确保刚刚完成的事务能尽快归档，你可以用pg_switch_xlog手动的强制切换一个段。其他 和WAL的管理相关的实用的功能在表9-56中列出来了。

当 wal_level 是minimal时， 一些SQL命令进行了优化，以避免WAL的记录，如第14.4.7节中的描述。 如果归档或流复制被开启了 在这些声明中的一个执行过程中，WAL文件将将不能包含足够的信息进行归档恢复。（崩溃恢复不受影响。）由于这个原因，wal_level只有在服务器启动时才能更改。然而， archive_command可以通过配置文件重新加载来改变。如果您想暂时停止归档，其中一种方法是设置 archive_command为空字符串(’’)。这将导致WAL文件在pg_xlog/中积累 直到一个正在运行的archive_command重新建立起来。

24.3.2. 制作基础备份

这个用来制作基础备份的过程相对比较简单：

1确保WAL归档已启用，而且正在工作。

2以超级用户的身份连接到数据库并且发出如下命令：

 select pg_start_backup（'label'）;

其中 label 是任何你想要用来唯一标识此备份操作的字符串。（一个很好的做法是使用你打算存放备份转储文件的地方的完整的路径。） pg_start_backup 创建一个名为backup_label的备份标签文件，放在数据簇群路径下，并且包含备份信息，包括开始时间和label字符。

你连上那个集群的数据库来发送命令都没关系。您可以忽略该函数返回的结果，但如果它报告一个错误，处理问题后再继续。

默认情况下， pg_start_backup可能需要较长时间才能完成。这是因为它执行一个检查点，并在检查点所需的I / O将消耗一个相当长的时间，默认情况下要花费相当于相邻检查点间隔的一半(参见配置参数 checkpoint_completion_target ）。这通常是你想要的，因为它最大限度地减少在查询处理速度影响。 如果你想启动备份尽快，使用：

 select pg_start_backup（'label'，true）;

这将强制检查点尽可能快速完成。

3执行备份，使用任何方便的文件系统备份工具，如tar 或cpio（不是 pg_dump或 pg_dumpall ）。在你执行这些命令时，不需要也没有必要停止一般的数据库操作运行。

4再次以超级用户连接到数据库，并发出命令：

 selec pg_stop_backup();

这将终止备份模式，并执行自动切换到下一个WAL段。 切换的原因是 安排最后写入的WAL段文件在 备份间隔之间来准备去归档。

5一旦在WAL段文件在被归档的备份中激活了，你就完成了。这个文件 靠 鉴定 pg_stop_backup的结果是最后一段 需要形成一个完整设置的备份文件。如果archive_mode启用，pg_stop_backup 不会返回，直到最后一段已归档。这些文件的归档会自动发生，因为你已经配置archive_command。在大多数情况下，这种情况发生的很快，但建议您监控您的归档系统，以确保没有延误。如果归档进程已经落后了，因其归档命令失败，它会不断重试，直到归档成功和备份完成了。如果你希望在pg_stop_backup上加一个时间限制，设置适当的statement_timeout值。

您还可以使用pg_basebackup工具来制作备份，而不是手工复制文件。此工具等效于pg_start_backup（）， 复制和 pg_stop_backup（）步骤自动的，并在使用复制协议的常规PostgreSQL连接中转移备份，而不需要文件系统级别的访问。pg_basebackup使用pg_start_backup()/pg_stop_backup()不会干扰文件系统级备份所。

一些文件系统备份工具发出警告或错误，如果他们试图在复制进行时复制已更改的文件。挡在制作一个运转的数据库的基础备份是，这种情况是正常的，而不是一个错误。然而，你需要确保你能把这类报错和真正的错误区分开。例如，一些版本rsync为 “消失的源文件”返回单独的退出代码 ，你可以编写一个驱动脚本接受退出代码作为非错误事件。另外，一些版本的GNU tar返回一个错误代码很难和致命的错误区分开来，如：一个文件被截断，而tar复制了它。 幸运的是，GNU tar1.16和之后的版本退出时，在备份的过程中如果一个文件被更改了会返回1，其他错误会返回2。

没有必要担心pg_start_backup和备份真正启动之间所消耗的大量时间，而不是在备份结束和pg_stop_backup之间 ;几分钟的延迟不会伤害任何东西。（但是，如果你正常的运行服务器 时，把full_page_writes 禁用了，您可能会注意到在pg_start_backup和pg_stop_backup之间性能的下降，因为full_page_writes 在备份模式是强制有效的。）您必须确保这些步骤连续的进行，没有任何的重叠，否则你的备份会作废。

可以肯定，你的备份转储包括所有文件都在数据库簇群目录下（如：/usr/local/pgsql/data）。如果您使用的表空间不是属于这个目录下的，小心的引用它们（并确保您的备份转储把链接符号作为链接来存档，否则恢复会破坏您的表空间）。

你可以，但是，从备份转储中忽略在簇群pg_xlog /子目录中的文件。 这轻微的调整是值得的，因为它减少了恢复时错误的风险。这是很容易安排，如果 pg_xlog / 是一个指向簇群目录以外的某个地方符号链接，这是一种常见设置，不管是什么性能原因。

为了备份使用，，您将需要保存所有在文件系统备份之后和之间生成WAL段文件。为了帮助你做到这点， pg_stop_backup 函数创建一个备份历史文件，能立刻存储进入WAL归档区域。这个文件在你需要为文件系统做的第一WAL段文件之后被命名。例如，如果起始WAL文件是 0000000100001234000055CD ，这个备份历史文件将被命名为一些像0000000100001234000055CD.007C9330.backup的文件。（文件名的第二部分，代表着在WAL文件内的确切位置，而且通常可以忽略不计。）一旦你安全地归档文件系统备份而且WAL段文件在备份期间使用（如在备份历史文件中指定），所有存档WAL段名字数字比较少的，不在需要来恢复该文件系统备份的都可以被删除。然而，你应该考虑多个备份设置是绝对能让你可以恢复你的数据。

备份历史文件只是一个小的文本文件。它包含你给pg_start_backup的标签字符串，以及起始和结束时间，备份的WAL段。如果您使用的标签确定相关的转储文件，则存档的历史文件足以告诉你哪个转储文件用来恢复。

因为你必须保持所有存档的WAL文件返回到您最后的基础备份，基础备份之间的间隔通常应选择取决于在归档WAL文件上要耗费的存储空间。你也应该考虑多久你会准备恢复，如果恢复是必要的 - 系统将不得不重播所有WAL段，如果它离上次基础备份有很长一段时间，这可能需要一段时间。

另外值得一提的是pg_start_backup功能使得文件名为backup_label在数据库簇群目录中，它是由 pg_stop_backup 删除的。这个文件将会作为您备份转储文件的一部分被归档。备份标签文件包括你给 pg_start_backup的标签字符串，除此之外还有pg_start_backup运行的同时，起始WAL的文件名。万一感到困惑，可以看看备份转储文件的里面，并确定转储文件是从哪些备份会话里来的。

当服务器已停止时，它也能制作一个备份转储。在这种情况下，你显然不能使用pg_start_backup 或 pg_stop_backup，因此会留给您自己的设备来跟踪那个是备份转储，以及如何追溯到相关的WAL文件去。 它通常是更好地遵循上述过程连续归档。