PostgreSQL9.0文档中“持续归档和基于时间点的恢..

24.3 持续归档和基于时间点的恢复    PostgreSQL在数据目录的pg_xlog子目录中始终维护一个WAL日志文件。这个日志文件记录数据库数据文件的每个改变。这个日志文件存在的主要目的是为数据库异常崩溃后数据库能安全的恢复:如果系统崩崩溃后，PostgreSQL通过重放最后一次checkpoint后的日志文件把数据库恢复到一致状态。然而，这个日志文件的存在，提供了了第三种的数据库备份策略：我们可以把文件系统备份和WAL备份组合成来。当需要恢复的时候，我们先通过文件系统备份还原数据库，然后再重放我们备份的WAL日志，这样就把数据库带到了当前状态。对于管理者来说这个方法比前面的方法更复杂，但是它有以下更重要的好处：

• 我们在开始备份数据库的时不再需要一个完美的一致性备份。在备份中的任何数据的非一致性都会被WAL日志文件的重放纠正。所以我们在备份数据库时不再需要一个特别的文件系统的快照就可以完成备份工作，例如通过tar或类似的文件归档工作就可以完成备份工作。
• 当我们组合一个无限长的WAL日文件的回放，持续的备份就可以通过不断的备份WAL日志文件来完成。这点对大数据库有特别重要的价值。因为这样，大数据库就不需要频繁的做全库备份了。
• 并不一定要把WAL文件一直重放到结束。我们能够重放到数据库到任何一个数据一致性的快照时间点，从而这项技术支持了基本时间点的恢复：你可以把数据库恢复到基础备份后的任一时间点。
• 如果我们持续的提供一系列的WAL日志文件给另一台机器上的从基础备份中还原出来的数据库，我们可以得到一个热备份的standby数据库：在任何时间我们都可以在第二台机器打开这个数据库，它拥有当前数据库的最近的数据状态。

   注意：pg_dump 和pg_dumpall不能产生文件系统级别的备份，所以不能做为持续归档的方案。这些dump命令是逻辑的备份，没有包括足够的信息供WAL重放使用。    文件系统级别的备份的一个解释，这个方法仅支持整个数据库集的恢复，而不能做到部分的恢复。同时，这个方法需要大量的归档存储空间：基础备份可能是庞大的，一个繁忙的系统可能产生大量的WAL日志。然而，在很多需要高可靠的情况下这是首选的备份技术。    要想通过持续的归档来做到成功的恢复（其它数据库也叫热备份），你需要开始备份之后的所有WAL文件。 所以在你做基础备份前，你需要设置和检查的你WAL归档。
24.3.1 Settup up WAL archiving 设置WAL归档    在一个抽象的场景中，一个运行的PostgreSQL数据库产生一个无限长的顺序的WAL记录。数据库物理的把这个WAL记录序列分割成WAL文件（每个WAL文件为一个WAL段）,通常每个段的大小为16M(在编译PostgreSQL时可以通过编译选项改变这个大小）。这个段文件的名字是一个数字，用来反映它们在抽象的WAL序列中的位置。当不使用WAL归档时，系统也会创建一些WAL段文件,然后通过把不再需要的WAL文件改名成下一个日志号的方式循环的使用它们。能够被循环重复使用的WAL文件就是那些内容是最后一次checkpoint点之前的产生的的WAL文件。    在归档WAL数据时，我们需要抓取每个WAL段文件被填充的内容，在被循环使用之前把数据存储到其它地方。依赖于应用和可用的硬件，有不同的方法去把WAL数据归档到其它地方：我们能拷贝WAL文件到一个从另一台机器导出的NFS目录，或把它们写到磁带上（确保你能从磁带备份中识别出每个WAL文件的原始的名字），或批量的把它们刻录到光盘中，或着完全使用其它什么别的办法。为了提供数据库管理的灵活性，PostgreSQL并不对如何做存档的方法做任何假设，相反的，PostgreSQL让管理员指定一个特别的shell命令支执行WAL文件的归档任务。这个shell命令可以非常简单，如一个cp命令，或一个非常复杂的shell命令，这一切都取决你。    为了允许归档，需要把wal_level参数设置为“archive“或“hot_standby“,archive_mode参数设置为"on",并为archive_command命令指定一个shell命令。在实践中，postgresql.conf文件中将始终设置这些参数。在归档的命令中，“%p“用来替换需要归档的WAL全路径文件名，“%f“表示不带路径的文件名。（路径名是相对的当前的数据工作目录，即数据库的数据目录），如果你要使用“%“，请使用“%%”替代。最简单的归档命令为： archive_command = 'cp -i %p /mnt/server/archivedir/%f </dev/null'    这条命令将会把WAL文件拷贝到目录/mnt/server/archivedir目录（这仅是一个示例，而不是必须这样，同时这条命令也不是在所有平台都能正常工作）.当“%p”和“%f”参数被替换后，实际的命令类似如下： cp -i pg_xlog/00000001000000A900000065 /mnt/server/archivedir/00000001000000A900000065 </dev/null 　　每个新WAL文件归档时类似这样的一条命令就会被数据库调用。    归档文件命令将以PostgreSQL服务器运行时的同一个用户去执行归档命令，被归档的一系列的WAL文件包含了数据库中任何有效的东西，你需要确保归档数据不会被非法访问，例如归档的目录不能有被其它用户读取的权限。    归档命令的返回值仅在成功的时候返加0，这是很重要的。当返回0时，PostgreSQL就会认为文件被成功的归档了，然后就会被删除或循环使用它们。反之，如果返回一个非零值，PostgreSQL会认为文件没有归档，然后会周期的重试，直到成功。    归档文件命令通常应旨在拒绝覆盖任何预先存在的文件。这是归档的一个重要的安全功能，当发生人为错误时能够保护你的归档（例如，将两个不同的服务器的WAL文件归档到了同一个目录中）。一个建议是测试您的存档命令，以确保它确实不覆盖现有的文件，同时最好在这种情况下返回非零状态。在许多的UNIX平台中，cp -i命令会提示是否覆盖一个文件，“</dev/null”会给出不覆盖的指示，然后命令以失败返回。如果你的平台不支持cp -i这个特性，你需要增加一个命令去测试文件是否存在。例如，命令可以类似如下： archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'    这条命令可以工作于大多数的UNIX平台。    在设计您的归档时,需要考虑当归档命令多次失败时将发生什么，如在某些方面需要操作员干预或归档文件运行空间不足的情况。例如：如果你写到不能自动换带的磁带的情况下，这就有可能发生。当磁盘满了，在更换磁盘前任何文件将不会被归档。您应确保任何错误或需要人工操作的要求能够被适当的报告出来，然后可以合理地快速解决。在这情况得到解决之前，pg_xlog目录一直会将处于满的状态。（如果px_xlog目录所在的文件系统满了，PostgreSQL将会做一个PANIC停机。未提交的事务将会丢失，一直到你释放空间之前数据库都会一直处于离线状态。 　　归档命令的速度是不重要的，只要它能跟上您的服务器生成WAL数据的平均速率。即使存档过程有点落后，但正常操作仍然能继续。如果归档大大落后，在一场灾难事件将会使丢失的数据量增加。它还意味着，在 pg_xlog/目录将包含大量的最终可能超过可用磁盘空间的未归档的WAL文件。建议您监视归档的过程，以确保它按您期望的那样工作。    编写您的归档命令时： 您应假定要归档文件的名称可以是最多64个字符，并且可以包含 ASCII 字母、 数字和“.”的任意组合。不需要保留原始的相对路径 (%p)，但要保存的文件名称 (%f)。    请注意虽然 WAL存档将允许您恢复PostgreSQL数据库中的数据所做的任何修改，但不会恢复由于那些手动编辑而不是通过SQL操作配置文件（也就是 postgresql.conf、 pg_hba.conf 和 pg_ident.conf） 所做的更改。您可能希望在文件系统的备份过程将配置文件保存在一个位置中。如何重新定位配置文件请参见18.2节。    归档文件命令归档已经写完的WAL文件。因此，如果你的服务器生成很小WAL流量，完成的事务最后存储到归档记录中可能会有长时间的延迟。为一个限制未归档的数据最多时间是多少，可以设置archive_timeout参数去强制数据库切换到一个新的WAL文件。注意，强制切换的归档文件仍然有整个WAL文件的长度。因此设置非常短的archive_timeout时间是不明智的，它将增加你的归档存储空间。通常合理的archive_timeout值为1分钟。    如果要确保刚刚完成的事务记录尽快到归档中，可以强制手工调用pg_switch_xlog。与WAL管理相关的其他实用程序列在Table 9-56。    当wal_level设置为minimal时，一些sql命令被优化掉而不会记录在WAL日志中，请见14.4.7节。如果在执行一个这样的SQL语句时归档或流复制被打开，WAL不会包含足够的信息用于存档恢复。（crash恢复是不受影响的）。因为这样 wal_level只能在服务器启动时更改在。但是archive_command可以使用配置文件重新加载进行更改。如果想暂时停止存档做的一种方法是将 archive_command 设置为空字符串 ('')。这将导致 WAL 文件积累在pg_xlog目录，直到archive_command被重新设置。     24.3.2 制作数据库的基础备份    下面是制作数据库基础备份的一个相对简单的过程：

1. 确保WAL归档被打开和正常工作。
2. 用超级用户连接到数据库并执行下面的命令：

select pg_start_backup('lable');   label是您要用来标识该备份操作到哪的唯一的任意字符串。（一个很好的做法是使用要备份转储文件的完整路径。） pg_start_backup在数据目录中创建一个叫“backup_label“的backup_label文件，文件中包括了您的备份的开始时间和标签字符串等信息。    使用此命令时连接到哪个数据库是不重要的。您可以忽略函数的返回的结果，但如果它报告出一个错误，继续之前请先处理完这个错误后再做后续的事情。　    默认情况下，pg_start_backup会执行一个较长的时间。这是因为它要执行一个checkpoint检查点， 在一段重要的时间周期内checkpoint检查点会发出IO请求，默认情况下会有一半的inter-checkpoint时间（见配置参数checkpoint comlpletion target).这通常是你需要的，因为这样做对查询操作影响最小。如果你想开始备份尽可能使用如下操作： select pg_start_backup('label',true);    这条命令让checkpoint尽可以快的完成。    3. 用一个尽可能方便的文件系统备份工具去执行备份，如cpio命令（而不是pg_dump或pg_dumpall）。当做这个操作时不需要停止正常的数据库操作。    4. 重新以超级用户连接到数据库，执行下面的命令    select pg_stop_backup();    这个操作将中止备份模式然后自动切换到下一个WAL文件.切换的理由是，在归档备份期间写入的最后WAL段文件。 　　5. 最后的WAL段文件是被记录在pg_stop_bakcup的命令结果中。如果archive_mode是enabled， 直到最后的WAL段文件被归档后pg_stop_backup命令才会返回。自从你配置了archive_command参数后，归档就一直会自动的执行。在大多数情况下这个操作是快速的，但建议你是监控你的归档系统以确保不会有大的延迟。如果因为归档命令失败导致归档过程落后了，它会一直重试直到归档成功和备份完成。如果你期望限制 pg_stop_backup命令执行的时间，请设置statement_timeout参数为合适的值。    在拷贝过程如果试图去拷贝的文件变化了，一些文件系统备份工具会忽略这些错误和警告。当做一个运行数据库的基础备份时，这种情况是正常的而不是错误。然后，你需要去确保能区别这种情况和真正的错误。例如：一些版本的rsync会返回一个单独的返回码表示“消失的源文件”,然后你写一个脚本把这个返回码做为一种非错误的情况处理。有时，如果一个文件被截断，一些版本的GNU tar工具正在拷贝这个文件时返回的一个错误码难以区别是其它严重错误还是这种情况。幸运的是，GNU tar 1.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)下的所有文件。如果你使用了所指向的目录不在这个目录之下的表空间，也需要小心的包括这些表空间的目录（也需要确保你的备份把表空间的链接文件也备份进去了，否则恢复时会损坏这个表空间）。    为了使用备份，你需要保留执行基础备份后产生的所有WAL日志文件。为了辅助你做这个，pg_stop_backup函数在WAL归档区中创建了一个备份历史记录文件。这个文件的名字是以你的文件系统备份需要的第一个WAL日志文件开始。例如：如果开始的WAL日志文件名为：0000000100001234000055CD，则备份历史文件名大致 为：0000000100001234000055CD.007C9330.backup（文件名中的第二部分是在WAL文件中的精确的位置，通常可以忽略）。一旦你安全的归档了文件系统备份和需要的WAL日志文件（被指定在备份历史记录文件中）,所有比这个数字小的WAL日志文件恢复时不再需要，可以删除掉。然而，你应该考虑保留几份备份以确保你绝对能恢复的你数据。     备份历史记录文件是一个小的文本文件。它包含了一个你传递给pg_start_backup函数的label串，也包含了备份起始时间、结束时间以及WAL日志文件名。如果你使用了这个label去标识这些相关的备份文件，这个备份历史记录文件足以告诉你哪些备份文件需要恢复。     从最后的基础备份后，你必须保留这之后的所有的WAL日志文件，两个基础备份之间的时间间隔的大小取决你有多少存储空间花费在这些归档的WAL日志文件上。你也必须考虑在恢复数据库时你准备花多长时间，当需要恢复时，系统会重新应用所有的这些WAL日志文件，如果基础备份做得比较久的话，这可能会花费一个较长的时间。     另一个值得注意的是pg_start_backup函数会建一个名叫“backuip_label”的文件在数据库的数据目录中，这个文件会被pg_stop_backup命令删除。这个文件当然会被归档到备份中。这个label文件包括了你传给pg_start_backup的“label”，也包含了pg_start_backup开始运行的时间和开始的WAL日志文件。可以查看一个备份中的这个文件来确认这个备份是属于哪个备份。     当然，我们也可以在数据库停止时备份。在这种情况下，你当然不需要使用pg_start_backup或 pg_stop_backup， 你剩下需要做的是记录每个备份所需要的WAL文件是哪些。 通常最好按照上述的连续归档过程。      24.3.3使用持续归档备份做恢复    最坏的情况发生了，你需要恢复你的数据库，下面是恢复步骤：    1.如果数据库服务正在运行，停止数据库服务。    2.如果你有足够的空间，拷贝数据库的数据目录和任何表空间对应的目录到一个临时的位置，我们后面会需要。注意这个预防措施需要你的空闲空间能有保留两份当前数据库所需要的空间。如果你没有足够的空间，你至少应该保存px_xlog目录下的所有内容,它可能包含了数据库shutdown之前的没有归档的WAL日志。    3. 删除数据库数据目录下所有的文件和子目录以及表空间所指向的目录。    4. 使用文件系统备份（即基础备份）恢复数据库。确保恢复出来的文件和子目录的属主及权限都正确。如果你使用了表空间，你需要验证在pg_tblspc/目录下的表空间链接也被正确的恢复了。    5. 移除pg_xlog子目录下的所有文件，因为它们是从文件系统备份中恢复出来的，可能已经过期了。如果你根本就没有备份pg_xlog目录，则使用正确的权限创建pg_xlog目录，如果pg_xlog是一个链接的，小心确保它是有效的。    6. 如果你有未归档的WAL文件（它们在第2步中被保存在一个临时的地方），把它们拷贝到pg_xlog子目录中。（最好是拷贝它们，而不要移动，因为如果后面有问题时，你还需要这些没有改变的文件）    7. 在这数据库的数据目录创建一个叫recovery.conf的恢复命令文件（请见Chapter 26)。你也可能需要临时的修改pg_hba.conf去阻止正常的用户连接到上来。    8. 启动数据库服务。数据库服务会进入恢复模式，不停读取需要的WAL日志文件。外部错误会导致恢复终止，这时只需重新启动服务器，它将继续恢复。完成恢复后，数据库服务会把recovery.conf文件改名成 recover.done（是为了防止后面意外再次进入恢复模式），然后开始提供正常的数据库服务。    9. 检查数据库的内容，确保你已经恢复到需要的状态。如果没有，回到步骤1。如果一切正常，然后恢复 pg_hba.conf允许用户正常连接到数据库。    所有这些的要点是设置恢复配置文件，恢复配置文件描述了你怎样恢复和恢复到哪个时间点。你可以使用 recovery.conf.sample（这个文件通常在安装包的share目录中）做为一个模板。其中的一个你必须做的事是在recovery.conf文件中指定restore_command命令，这个命令告诉PostgreSQL怎样去提取归档的WAL文件。就象archive_command一样，这个命令是一个shell命令脚本。它包含%f，用来指示这需要的WAL文件名，%p指示需要把WAL log文件拷贝到的目录。（这个目录相对于当前工作目录，也就是数据库的数据目录）。写%%代表真实的%字符。可使用的最简单的命令为： restore_command = 'cp /mnt/server/archivedir/%f %p'    这条命令将从归档的WAL日志文件文件目录/mnt/server/archivedir/拷贝WAL文件。当然你可以使用 更复杂的命令，甚至是一个shell脚本，去从相关的磁带上提取归档文件。    当命令执行失败后返回一个非零值，这个要求是很重要的。在当前目录中没有找到需要的WAL日志文件时， 这个命令将会被PostgreSQL调用。并不是所有被请求的文件都是WAL日志文件，你还应该期望是.backup 或 .history后缀的文件的请求。也需要注意%p全路径中的文件名可能与%f是不同的，不要期望它们是可以互换的。    不能在归档备份中找到的WAL文件将会在pg_xlog目录寻找，这就允许使用了最近的未归档的WAL日志文件。然而，归档备份中的WAL日志文件优先于pg_xlog目录中的文件。当系统从归档中提求WAL日志文件时不会覆盖pg_xlog目录中的内容。    正常情况下，恢复过程将处理所有可能的WAL日志文件，从而将数据库还原到当前时间点或尽可能接近。 所以，正常恢复将以给出“未找到文件“消息后结束，准确的错误信息取决于你的restore_command命令。 在恢复开始时，你可能也会看到一个错误信息：一个包含“00000001.history”的信息。这也是正常的，并不是说这有什么问题，请见24.3.4的讨论。    如果你想恢复到一个之前的时间点（可能是一个经验少的DBA删除了一个主要的业务表），需要在recovery.conf中指定恢复的停止点。你可以指定停止点，这被称为“recovery target”，停止点既可用时间或指定一个事务ID。正常情况下，仅使用时间是可能的，因为没有工具可以帮助你找到确定的事务ID。    注意：结束的时间点必须在基础备份之后，也就是pg_stop_backup命令的结束时间。你不能使用基础备份恢复到正在做基础备份中的时间点。（要恢复到这样的时间点，你必须使用之前的基础备份然后前滚到这个时间点。    如果恢复时发现损坏的WAL数据，恢复将停止这个点上，服务器也不会启动。在这种情况下，恢复过程必须重新来，并指定一个比损坏点更远的时间点，这样才能使用恢复正常结束。如果恢复因为外部的原因失败了，比方说系统crash掉了，或WAL归档文件不再能访问了，可以通过简单的重新启动来继续恢复。恢复的重启象一个正常操作中的checkpoint操作，服务器周期的把它们的状态存入磁盘中，然后更新pg_control文件去指示已经处理到哪些WAL数据，这些数据不需要再被处理了。     24.3.4 时间线    恢复数据库到先前的时间点可以产生很多复杂的情况，这就有点象科幻中的时间旅行和平行宇宙。例如，在数据库的原始历史中，假想你在周二下午5:15删除了一个关键表，但只到周三你才发现。不用紧张的是，你找出你的备份，把数据库恢复到周二的下午5:14，然后启动并运行。在数据库宇宙的这个历史中，你从来没有删除这个表。但假想，你最后又认识到这样也不是一个好办法，还是要返回到原始历史上的周三上午的情况。如果你的数据库正常运行，你不能做这个的，因为新生成的WAL日志文件将覆盖一些旧WAL日志文件。结果，为了避免这种情况，你需要区别出当你按时间点恢复后生成的WAL日志文件和恢复之前生成的WAL日志文件。    为了处理这个问题，PostgreSQL有一个概念叫时间线（timelines）。每当恢复完成后，一个有新的时间线的WAL文件被创建出来。这个时间线ID是WAL文件名中的一部分，所以新时间线的WAL文件不会覆盖先前时间线的WAL文件。这实际上归档多个不同时间线的WAL日志也是真实可行的。这可能看起来像一个没有用的功能，但这个功能经常是一个救命者。考虑这种情况：你完全不知道该恢复到哪个时间点，你不得不做很多次基于时间点的恢复，直到你从旧的历史中找到最合适的分支。没有时间线这一进程很快就会陷入无法管理的混乱。而有了时间线，您可以恢复到任何以前的状态包括您较早前放弃的时间线分支中的状态。    每一次新的时间线创建后，PostgreSQL会创建一个“时间线历史“文件，这个文件记录了每个时间线是从哪个时间线的分离出来的，以及什么时候分出来的。这些时间线历史文件是非常有用的，这能从包含多个时间线归档文件中找到正确的WAL日志文件，所以时间线历史文件也与WAL文件一样被归档在备份中。时间线历史文件是一个小文本文件，它们可以几乎无限期的保存而不会有什么代价（因为不象WAL文件那么大）。如果你喜欢，你可以添加注释到这个历史文件中，去记录你自己需要的信息，比方说如何创建的这个时间线及为什么要创建这个特别的时间线的信息。当你有很多不同的时间线时，这类注释是特别有价值的。    恢复的默认行为是一直恢复到与备份时的时间线相同时间线的结束处。如果你希望恢复到一些子时间线（这是，你想回到完成恢复后数据库又运行了一段时间的子时间线上），你需要在recovery.conf中指定target时间线ID你不能恢复到基础备份之前的时间线分支上。     24.3.5用法与示例    下面给出一些配置持续归档的配置用法     24.3.5.1 独立的hot backups    可以使用PostgreSQL的备份机制实现一个hot backups。这个备份不能被做为基于时间点的恢复使用，然后通常这种备份和恢复比pg_dump更快。（这种方式产生的备份也会比pg_dump更大，所以有些情况下，速度的优点会被抵消掉。）    为了准备一个独立的hot backups，要设置wal_level参数为archive或hot_standby，archive_mode设置为on，设置特别的archive_command，当切换触发文件存在时archive_command才会去执行归档。例如：    archive_command = 'test ! -f /var/lib/pgsql/backup_in_progress || cp -i %p /var/lib/pgsql/archive/%f < /dev/null'    这个命令当/var/lib/pgsql/backup_in_progress文件存在时会执行归档，当切换触发文件不存在时，会返回0（这允许PostgreSQL循环使用这个不需要的WAL文件）。    上面的做好了后，可用下面的脚本做备份： touch /var/lib/pgsql/backup_in_progress psql -c "select pg_start_backup('hot_backup');" tar -cf /var/lib/pgsql/backup.tar /var/lib/pgsql/data/ psql -c "select pg_stop_backup();" rm /var/lib/pgsql/backup_in_progress tar -rf /var/lib/pgsql/backup.tar /var/lib/pgsql/archive/    切换触发文件创建后，允许归档完成的WAL文件。当切换触发文件被移除后，归档的WAL日志文件和基本备份都被备份成一个tar文件。记住请在你的备份脚本中添加错误处理。    如果归档存储的大小是需要关心的，可能使用pg_compresslong, http://pglesslog.projects.postgresql.org,这个工具会移除不需要的full_page_writes和跟踪WAL文件中的有效数据空间。你可以使用gzip命令去进一步压缩pg_compresslog输入的内容： archive_command='pg_compresslog %p - |gzip > /var/lib/pgsql/archive/%f'    当恢复时，你需要使用gunzip和pg_decompresslog解压： restore_command = 'gunzip < /mnt/server/archivedir/%f | pg_decompresslog - %p     24.3.5.2 archive_command 脚本     很多人选择使用脚本去定义他们的archive_command，他们的postgresql.conf文件的配置类似如下： archive_command='local_backup_script.sh'     使用一个脚本文件是明智的，这样任何时候你都可以在归档过程中使用多于单条的命令。这允许在脚本中进行复杂的管理，这个脚本可以使用通常的脚本语言如bash或perl写。脚本输出到stderr的任何信息都将出现的数据库服务器的log中，复杂的配置能更容易的诊断错误。     在脚本中下面的需求可能被解决：

• 安全的拷贝数据到离线的存储中。
• 每三小时批量的传输WAL文件,而不是每次一个文件。
• 与其它的备份恢复脚本进行交互。
• 与其它的监控系统进行交互和报告错误。

    24.3.6 警告     在这篇文章中，对持续归档技术有一些限制。下面这些可能在将来的版本中被修复：

• 对hash索引的操作目前不会被记录到WAL日志中，所以应用WAL日志不会更新这些索引。这意味着任何新的插入将被索引忽略，更新的行也明显会消失，删除的行仍然保留着指针。换句话说，如果你修改了一个有hash索引的表，你将在standby上得到一个错误的查询结果。当恢复完成后，建议你手工的在这些hash索引上执行reindex.
• 当在进行基本备份的过程中，一个CREATE DATABASE命令被执行了，这时又修改了CREATE DATABASE命令使用的模板数据库，针对模板数据库的修改可能也被传播到standby的create database中。这当然不是我们希望的。为了避免这个风险，最好是在到基本备份时不要修改任何模板数据库。
• CREATE TABELSPACE命令中的路径被原样记录在WAL日志中，因而当恢复时创建出的表空间也使用这个绝对路径。如果我们在另一台机器上恢复时这可能不是我们希望的。在同一台机器上这也可能是危机，如果我们恢复数据库到一个新的数据目录： 恢复可能仍会覆盖原有的数据库。若要避免这种潜在问题，最好在创建或删除表空间后做一个新的基础备份。

   也需要注意的是，当包含多个磁盘页的快照时，这个默认的WAL文件格式是相当臃肿的。这些页的快照被设计用来支持crash恢复，原因是我们可能是需要修改部分被写的磁盘页。依赖你的系统硬件和软件，这个部份的风险可能非常小可以被忽略，在这种情况下，你可以通过设置full_page_writes参数关闭页快照去减少归档日志的空间。（在做这之前，请参见Chapter 29）。关闭页快照不会影响PITR的操作。今后的一个开发领域是当full_page_write设置为on时也可以通过移除不使用的页拷贝而压缩WAL数据。与此同时，管理员可能希望通过尽可能增加检查点间隔参数去减少在WAL日志中快照页的数目。