@@ -1732,15 +1732,15 @@ pg_probackup restore -B <replaceable>backup_dir</replaceable> --instance <replac
17321732 header and checksum in every page and replace only invalid
17331733 pages and those with checksum and LSN not matching with
17341734 corresponding page in backup. This is the simplest,
1735- the most fool-proof incremental mode.
1735+ the most fool-proof incremental mode. Recommended to use by default.
17361736 </para >
17371737 </listitem >
17381738 <listitem >
17391739 <para >
17401740 LSN — read the <replaceable >pg_control</replaceable > in the
17411741 data directory to obtain redo LSN and redo TLI, which allows
17421742 to determine a point in history(shiftpoint), where data directory
1743- state shifted from backup chain history. If shiftpoint is not within
1743+ state shifted fromtarget backup chain history. If shiftpoint is not within
17441744 reach of backup chain history, then restore is aborted.
17451745 If shiftpoint is within reach of backup chain history, then read
17461746 all data files in the data directory, validate header and checksum in
@@ -1755,7 +1755,7 @@ pg_probackup restore -B <replaceable>backup_dir</replaceable> --instance <replac
17551755 Second, the <replaceable >pg_control</replaceable > file must be
17561756 synched with state of data directory. This condition cannot checked
17571757 at the start of restore, so it is a user responsibility to ensure
1758- that pg_control contain valid information.Because of that is not
1758+ that pg_control contain valid information.Therefore it is not
17591759 recommended to use LSN mode in any situation, where pg_control has
17601760 been tampered with:
17611761 after <replaceable >pg_resetxlog</replaceable > execution,
@@ -1769,7 +1769,13 @@ pg_probackup restore -B <replaceable>backup_dir</replaceable> --instance <replac
17691769 </listitem >
17701770 </itemizedlist >
17711771
1772- <para >
1772+ <para >
1773+ Regardless of chosen incremental mode, pg_probackup will check, that postmaster
1774+ in given destination directory is not running and <varname >system-identifier</varname > is
1775+ the same as in the backup.
1776+ </para >
1777+
1778+ <para >
17731779 Suppose you want to return an old master as replica after switchover
17741780 using incremental restore in LSN mode:
17751781 </para >
@@ -1794,12 +1800,12 @@ INFO: Redundant files are removed, time elapsed: 1s
17941800INFO: Start restoring backup files. PGDATA size: 15GB
17951801INFO: Backup files are restored. Transfered bytes: 1693MB, time elapsed: 43s
17961802INFO: Restore incremental ratio (less is better): 11% (1693MB/15GB)
1797- INFO: Restore of backupQBRHT8 completed.
1803+ INFO: Restore of backupQBRNBP completed.
17981804 </programlisting >
17991805 <note >
18001806 <para >
18011807 Incremental restore is possible only for backups with
1802- <literal >program_version</literal > equal or greater than 2.3 .0.
1808+ <literal >program_version</literal > equal or greater than 2.4 .0.
18031809 </para >
18041810 </note >
18051811 </refsect3 >