pg_standby支持"热备份"数据库服务器的创建。 它设计为一个生产就绪程序，还有一个可定制的模板，定制你需要的特定修改。
pg_standby设计为一个等待的restore_command， 需要将标准归档恢复返回到一个热备份操作。也需要其他配置， 所有这些都在主要服务器手册(参阅第 25.2 节)中描述。
使用pg_standby配置一个备用服务器， 将其放入recovery.conf配置文件中：
restore_command = 'pg_standby archiveDir %f %p %r'
这里的archiveDir是恢复WAL段文件的目录。
如果声明了restartwalfile，通常通过使用%r宏， 然后所有逻辑上在这个文件之前的WAL文件都将从archivelocation 中删除。这最小化了保存崩溃重启能力时需要保留的文件数量。 如果archivelocation对于这个备用服务器来说是瞬态暂存区域， 则使用这个参数是合适的，但在打算将archivelocation 当做长期WAL归档区域时，这是不合适的。
pg_standby假设archivelocation 是拥有服务器的用户可读取的目录。如果声明了 restartwalfile (或 -k)， 那么archivelocation目录也必须是可写的。
当主服务器故障时，有两种方法故障切换到"热备用"数据库服务器：
在智能故障切换下，在归档中应用所有WAL文件可用后启用备用服务器。 这样就会零数据丢失，即使备用服务器稍后失败，但是如果有大量未能应用的WAL， 那么在备用服务器准备好之前可能需要大量时间。要触发智能故障切换， 创建一个包含单词smart的触发器文件，或者只是创建它而不写内容。
在快速故障切换下，备用服务器立即启用。归档中任何未应用的WAL文件都将被忽略， 并且所有在这些文件中的事务都丢失。要触发快速故障切换，创建一个触发器文件， 并写入单词fast。如果没有新的WAL文件出现在定义的间隔中， 则pg_standby也可以配置为自动执行快速故障切换。
pg_standby接受下列的命令行参数：
使用cp或copy命令从归档中恢复WAL文件。 这是唯一支持的行为，所以这个选项没什么用处。
在stderr上打印大量调试日志输出。
从archivelocation中删除文件， 这样在归档中保存的当前文件之前不超过这么多WAL文件。 0（缺省）意味着不从archivelocation中删除任何文件。 如果声明了restartwalfile，则忽略这个参数， 因为该声明方法更精确的决定了正确的归档截止点。 这个参数的使用到了PostgreSQL 8.3就废弃了； 声明一个restartwalfile参数更安全也更有效。 太小的设置可能导致删除备用服务器重启仍然需要的文件， 而太大的设置会浪费归档空间。
设置拷贝命令失败时重试的最大次数（缺省是3）。在每次失败之后， 我们等待sleeptime * num_retries， 所以等待时间逐渐增加。因此，默认的，在将失败报告给备用服务器之前， 我们将等待5秒、10秒、然后15秒。这将被解释为结束恢复，并且结果是备用服务器完全启动。
设置测试之间睡眠的秒数（最高60，缺省15），以查看要恢复的WAL文件在归档中是否已经可用。 不一定推荐缺省设置；查阅第 25.2 节获取讨论。
声明一个触发器文件，它的存在会引起故障切换。建议使用结构化的文件名， 以避免多个服务器存在于同一个系统上时，混淆要触发的是哪个服务器； 例如/tmp/pgsql.trigger.5432。
打印pg_standby的版本并退出。
设置执行了快速故障切换之后，等待下一个WAL文件的最大秒数。 设置为0（缺省）意味着永远等待。不一定推荐缺省设置； 查阅第 25.2 节获取讨论。
显示关于pg_standby命令行参数的帮助，然后退出。
pg_standby是设计在PostgreSQL 8.2 及更新版本上使用的。
PostgreSQL 8.3提供了%r宏， 让pg_standby知道它需要保存的最后文件。 在PostgreSQL 8.2中，如果需要清理归档，则必须使用-k 选项。这个选项在8.3中保持可用，但是它的使用已经废弃了。
PostgreSQL 8.4提供了recovery_end_command选项。 没有这个选项，那么剩下的触发器文件可能是危险的。
pg_standby是使用C语言写的， 并且有一个容易修改的源代码，有专门指定的部分用来按你的需要修改。
在Linux或Unix系统上，你可能使用：
archive_command = 'cp %p .../archive/%f' restore_command = 'pg_standby -d -s 2 -t /tmp/pgsql.trigger.5442 .../archive %f %p %r 2>>standby.log' recovery_end_command = 'rm -f /tmp/pgsql.trigger.5442'
这里的归档目录在物理上位于备用服务器上，所以archive_command 通过NFS访问它，但是文件对于备用服务器来说是本地的（启用ln）。 这将：
在standby.log中产生调试输出
在检查下一个WAL文件可用性之前睡眠2秒
只在触发器文件调用/tmp/pgsql.trigger.5442出现时停止等待， 并根据它的内容执行故障切换
当恢复结束时删除触发器文件
从归档目录中删除不再需要的文件
在Windows上，你可能使用：
archive_command = 'copy %p ...\\archive\\%f' restore_command = 'pg_standby -d -s 5 -t C:\pgsql.trigger.5442 ...\archive %f %p %r 2>>standby.log' recovery_end_command = 'del C:\pgsql.trigger.5442'
请注意，反斜杠在archive_command中需要双写， 但是在restore_command或recovery_end_command 中不需要。这将：
使用copy命令从归档中恢复WAL文件
在standby.log中产生调试输出
在检查下一个WAL文件可用性之前睡眠5秒
只在触发器文件调用C:\pgsql.trigger.5442出现时停止等待， 并根据它的内容执行故障切换
当恢复结束时删除触发器文件
从归档目录中删除不再需要的文件
Windows上的copy命令在文件完全拷贝之前设置最后的文件大小， 这通常会混淆pg_standby。因此pg_standby 一到它认为合适的大小就等待sleeptime秒。 GNUWin32的cp只在文件拷贝完成之后设置文件的大小。
因为Windows示例在两端都使用copy， 所以一个或两个服务器可以通过网络访问归档目录。