@@ -1746,10 +1746,19 @@ pg_probackup restore -B <replaceable>backup_dir</replaceable> --instance <replac
1746
1746
all data files in the data directory, validate header and checksum in
1747
1747
every page and replace only invalid pages and those with LSN greater
1748
1748
than shiftpoint.
1749
- This mode offer a greatest speed up, but rely on <replaceable >pg_control</replaceable >
1750
- been synched with state of data directory,
1751
- so it is not recommended to use in any situation, where this condition
1752
- is not met, for example, after <replaceable >pg_resetxlog</replaceable > execution,
1749
+ This mode offer a far greater speed up compared to CHECKSUM, but rely
1750
+ on two conditions to be met. First,
1751
+ <ulink url =" https://postgrespro.com/docs/postgresql/current/runtime-config-preset.html#GUC-DATA-CHECKSUMS" >
1752
+ data checksums</ulink > parameter must be enabled in data directory (to avoid corruption
1753
+ due to hint bits). This condition will be checked at the start of
1754
+ incremental restore and the operation will be aborted if checksums are disabled.
1755
+ Second, the <replaceable >pg_control</replaceable > file must be
1756
+ synched with state of data directory. This condition cannot checked
1757
+ 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
1759
+ recommended to use LSN mode in any situation, where pg_control has
1760
+ been tampered with:
1761
+ after <replaceable >pg_resetxlog</replaceable > execution,
1753
1762
after restore from backup without recovery been run, etc.
1754
1763
</para >
1755
1764
</listitem >
0 commit comments