@@ -857,12 +857,79 @@ test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_wal/0
857
857
</para>
858
858
</sect2>
859
859
860
+ <sect2 id="backup-incremental-backup">
861
+ <title>Making an Incremental Backup</title>
862
+
863
+ <para>
864
+ You can use <xref linkend="app-pgbasebackup"/> to take an incremental
865
+ backup by specifying the <literal>--incremental</literal> option. You must
866
+ supply, as an argument to <literal>--incremental</literal>, the backup
867
+ manifest to an earlier backup from the same server. In the resulting
868
+ backup, non-relation files will be included in their entirety, but some
869
+ relation files may be replaced by smaller incremental files which contain
870
+ only the blocks which have been changed since the earlier backup and enough
871
+ metadata to reconstruct the current version of the file.
872
+ </para>
873
+
874
+ <para>
875
+ To figure out which blocks need to be backed up, the server uses WAL
876
+ summaries, which are stored in the data directory, inside the directory
877
+ <literal>pg_wal/summaries</literal>. If the required summary files are not
878
+ present, an attempt to take an incremental backup will fail. The summaries
879
+ present in this directory must cover all LSNs from the start LSN of the
880
+ prior backup to the start LSN of the current backup. Since the server looks
881
+ for WAL summaries just after establishing the start LSN of the current
882
+ backup, the necessary summary files probably won't be instantly present
883
+ on disk, but the server will wait for any missing files to show up.
884
+ This also helps if the WAL summarization process has fallen behind.
885
+ However, if the necessary files have already been removed, or if the WAL
886
+ summarizer doesn't catch up quickly enough, the incremental backup will
887
+ fail.
888
+ </para>
889
+
890
+ <para>
891
+ When restoring an incremental backup, it will be necessary to have not
892
+ only the incremental backup itself but also all earlier backups that
893
+ are required to supply the blocks omitted from the incremental backup.
894
+ See <xref linkend="app-pgcombinebackup"/> for further information about
895
+ this requirement.
896
+ </para>
897
+
898
+ <para>
899
+ Note that all of the requirements for making use of a full backup also
900
+ apply to an incremental backup. For instance, you still need all of the
901
+ WAL segment files generated during and after the file system backup, and
902
+ any relevant WAL history files. And you still need to create a
903
+ <literal>recovery.signal</literal> (or <literal>standby.signal</literal>)
904
+ and perform recovery, as described in
905
+ <xref linkend="backup-pitr-recovery" />. The requirement to have earlier
906
+ backups available at restore time and to use
907
+ <literal>pg_combinebackup</literal> is an additional requirement on top of
908
+ everything else. Keep in mind that <application>PostgreSQL</application>
909
+ has no built-in mechanism to figure out which backups are still needed as
910
+ a basis for restoring later incremental backups. You must keep track of
911
+ the relationships between your full and incremental backups on your own,
912
+ and be certain not to remove earlier backups if they might be needed when
913
+ restoring later incremental backups.
914
+ </para>
915
+
916
+ <para>
917
+ Incremental backups typically only make sense for relatively large
918
+ databases where a significant portion of the data does not change, or only
919
+ changes slowly. For a small database, it's simpler to ignore the existence
920
+ of incremental backups and simply take full backups, which are simpler
921
+ to manage. For a large database all of which is heavily modified,
922
+ incremental backups won't be much smaller than full backups.
923
+ </para>
924
+ </sect2>
925
+
860
926
<sect2 id="backup-lowlevel-base-backup">
861
927
<title>Making a Base Backup Using the Low Level API</title>
862
928
<para>
863
- The procedure for making a base backup using the low level
864
- APIs contains a few more steps than
865
- the <xref linkend="app-pgbasebackup"/> method, but is relatively
929
+ Instead of taking a full or incremental base backup using
930
+ <xref linkend="app-pgbasebackup"/>, you can take a base backup using the
931
+ low-level API. This procedure contains a few more steps than
932
+ the <application>pg_basebackup</application> method, but is relatively
866
933
simple. It is very important that these steps are executed in
867
934
sequence, and that the success of a step is verified before
868
935
proceeding to the next step.
@@ -1118,14 +1185,28 @@ SELECT * FROM pg_backup_stop(wait_for_archive => true);
1118
1185
</listitem>
1119
1186
<listitem>
1120
1187
<para>
1121
- Restore the database files from your file system backup. Be sure that they
1188
+ If you're restoring a full backup, you can restore the database files
1189
+ directly into the target directories. Be sure that they
1122
1190
are restored with the right ownership (the database system user, not
1123
1191
<literal>root</literal>!) and with the right permissions. If you are using
1124
1192
tablespaces,
1125
1193
you should verify that the symbolic links in <filename>pg_tblspc/</filename>
1126
1194
were correctly restored.
1127
1195
</para>
1128
1196
</listitem>
1197
+ <listitem>
1198
+ <para>
1199
+ If you're restoring an incremental backup, you'll need to restore the
1200
+ incremental backup and all earlier backups upon which it directly or
1201
+ indirectly depends to the machine where you are performing the restore.
1202
+ These backups will need to be placed in separate directories, not the
1203
+ target directories where you want the running server to end up.
1204
+ Once this is done, use <xref linkend="app-pgcombinebackup"/> to pull
1205
+ data from the full backup and all of the subsequent incremental backups
1206
+ and write out a synthetic full backup to the target directories. As above,
1207
+ verify that permissions and tablespace links are correct.
1208
+ </para>
1209
+ </listitem>
1129
1210
<listitem>
1130
1211
<para>
1131
1212
Remove any files present in <filename>pg_wal/</filename>; these came from the
0 commit comments