Re: cleanup patches for incremental backup - Mailing list pgsql-hackers

From Robert Haas
Subject Re: cleanup patches for incremental backup
Date
Msg-id CA+TgmoadPUdt8ZJ_Zem-T2_qZ5OTXVdxH6wGtnaV-TunN+LOHQ@mail.gmail.com
Whole thread Raw
In response to Re: cleanup patches for incremental backup  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Responses Re: cleanup patches for incremental backup
List pgsql-hackers
On Tue, Jan 16, 2024 at 3:22 PM Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:
> > One other thought is that the incremental backup only replaces
> > relation files with incremental files, and it never does anything
> > about FSM files. So the statement that it only contains data that was
> > potentially changed isn't quite correct. It might be better to phrase
> > it the other way around i.e. it is like a full backup, except that
> > some files can be replaced by incremental files which omit blocks to
> > which no WAL-logged changes have been made.
>
> How about the attached?

I like the direction.

+     A special <glossterm linkend="glossary-basebackup">base backup</glossterm>
+     that for some WAL-logged relations only contains the pages that were
+     modified since a previous backup, as opposed to the full relation data of
+     normal base backups. Like base backups, it is generated by the tool
+     <xref linkend="app-pgbasebackup"/>.

Could we say "that for some files may contain only those pages that
were modified since a previous backup, as opposed to the full contents
of every file"? My thoughts are (1) there's no hard guarantee that an
incremental backup will replace even one file with an incremental
file, although in practice it is probably almost always going to
happen and (2) pg_combinebackup would actually be totally fine with
any file at all being sent incrementally; it's only that the server
isn't smart enough to figure out how to do this with e.g. SLRU data
right now.

+     To restore incremental backups the tool <xref
linkend="app-pgcombinebackup"/>
+     is used, which combines the incremental backups with a base backup and
+     <glossterm linkend="glossary-wal">WAL</glossterm> to restore a
+     <glossterm linkend="glossary-db-cluster">database cluster</glossterm> to
+     a consistent state.

I wondered if this needed to be clearer that the chain of backups
could have length > 2. But on further reflection, I think it's fine,
unless you feel otherwise.

The rest LGTM.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Revise the Asserts added to bimapset manipulation functions
Next
From: Przemysław Sztoch
Date:
Subject: Re: UUID v7