diff --git a/doc/pgprobackup.xml b/doc/pgprobackup.xml
index 88ce237d5..a394cbcd4 100644
--- a/doc/pgprobackup.xml
+++ b/doc/pgprobackup.xml
@@ -1875,8 +1875,9 @@ pg_probackup restore -B <replaceable>backup_dir</replaceable> --instance <replac
         <command>DROP DATABASE</command> command.
       </para>
       <para>
-        If want to decouple a single cluster with multiple databases into separate clusters with minimal downtime, then
-        you can partially restore cluster as standby via <option>--restore-as-replica</option> options.
+        To decouple a single cluster containing multiple databases into separate clusters with minimal downtime,
+        you can do partial restore of the cluster as a standby using the <option>--restore-as-replica</option> option
+        for specific databases.
       </para>
       <note>
         <para>
@@ -1886,10 +1887,12 @@ pg_probackup restore -B <replaceable>backup_dir</replaceable> --instance <replac
       </note>
       <note>
         <para>
-          Due to how recovery works in PostgreSQL versions lower than 12 it is advisable to
-          disable <option>hot_standby</option> option, when running partial
-          restore of PostgreSQL cluster of version less than <option>12</option>.
-          Otherwise recovery may fail.
+          Due to recovery specifics of PostgreSQL versions earlier than 12,
+          it is advisable that you set the
+          <ulink url="https://postgrespro.com/docs/postgresql/current/runtime-config-replication.html#GUC-HOT-STANDBY">hot_standby</ulink>
+          parameter to <literal>off</literal> when running partial
+          restore of a PostgreSQL cluster of version earlier than 12.
+          Otherwise the recovery may fail.
         </para>
       </note>
     </refsect3>
@@ -3976,10 +3979,11 @@ pg_probackup restore -B <replaceable>backup_dir</replaceable> --instance <replac
         this flag if you need to restore the
         <productname>PostgreSQL</productname> cluster from a corrupt or an invalid backup.
         Use with caution.
-        When used with <link linkend="pbk-incremental-restore">incremental restore</link> this flag
-        allows to replace already existing PGDATA with different system ID. In case of tablespaces,
-        remapped via <literal>--tablespace-mapping</literal> option into non-empty directories,
-        the content of such directories will be deleted.
+        If <envar>PGDATA</envar> contains a non-empty directory with system ID different from that
+        of the backup being restored, <link linkend="pbk-incremental-restore">incremental restore</link>
+        with this flag overwrites the directory contents (while an error occurs without the flag). If tablespaces
+        are remapped through the <literal>--tablespace-mapping</literal> option into non-empty directories,
+        the contents of such directories will be deleted.
       </para>
       </listitem>
       </varlistentry>
@@ -4425,7 +4429,7 @@ pg_probackup archive-get -B <replaceable>backup_dir</replaceable> --instance <re
       <listitem>
       <para>
         Specifies the timestamp up to which recovery will proceed.
-        If timezone offset is not specified, local timezone is used.
+        If the time zone offset is not specified, the local time zone is used.
       </para>
       <para>
        Example: <literal>--recovery-target-time='2020-01-01 00:00:00+03'</literal>
@@ -4615,7 +4619,7 @@ pg_probackup archive-get -B <replaceable>backup_dir</replaceable> --instance <re
       <para>
           Specifies the timestamp up to which the backup will stay
           pinned. Must be an ISO-8601 complaint timestamp.
-          If timezone offset is not specified, local timezone is used.
+          If the time zone offset is not specified, the local time zone is used.
       </para>
       <para>
        Example: <literal>--expire-time='2020-01-01 00:00:00+03'</literal>