PostgreSQL9.0文档中“持续归档和基于时间点的恢复”部分的翻译2

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日志中快照页的数目。

请合并成一个帖子，请问楼主是自己翻译的吗？
还是是你转载的。

是我自己翻译的，一个贴子放不下，字数超过限制了，只能放成两个贴子。