From 24a1ad31d0dfcd8c72a71c589902446a9da75e11 Mon Sep 17 00:00:00 2001 From: David Steele Date: Tue, 2 Feb 2016 11:57:46 -0500 Subject: [PATCH] Minor rewording in user guide. --- doc/xml/user-guide.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/xml/user-guide.xml b/doc/xml/user-guide.xml index c3963a327..66f7f82c8 100644 --- a/doc/xml/user-guide.xml +++ b/doc/xml/user-guide.xml @@ -737,7 +737,7 @@
Point-in-Time Recovery -

Restore a Backup in Quick Start performed default recovery, which is to play all the way to the end of the WAL stream. In the case of a hardware failure this is probably the most appropriate action but for data corruption scenarios (whether machine or human in origin) there is a better alternative called Point-in-Time Recovery (PITR).

+

Restore a Backup in Quick Start performed default recovery, which is to play all the way to the end of the WAL stream. In the case of a hardware failure this is usually the best choice but for data corruption scenarios (whether machine or human in origin) Point-in-Time Recovery (PITR) is often more appropriate.

Point-in-Time Recovery (PITR) allows the WAL to be played from the last backup to a specified time, transaction id, or recovery point. For common recovery scenarios time-based recovery is arguably the most useful. A typical recovery scenario is to restore a table that was accidentally dropped or data that was accidentally deleted. Recovering a dropped table is more dramatic so that's the example given here but deleted data would be recovered in exactly the same way.