[go: up one dir, main page]

Re: The backup API and general purpose backup software

From: "Peter J(dot) Holzer" <hjp-pgsql(at)hjp(dot)at>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: The backup API and general purpose backup software
Date: 2020-06-22 11:13:34
Message-ID: 20200622111334.GB5340@hjp.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 2020-06-21 17:35:41 -0500, Ron wrote:
> On 6/21/20 10:45 AM, Peter J. Holzer wrote:
> > On 2020-06-21 10:32:16 -0500, Ron wrote:
> > > On 6/21/20 8:28 AM, Peter J. Holzer wrote:
> > > > To make a full backup with the "new" (non-exclusive) API, a software
> > > > must do the following
> > > >
> > > > 1. open a connection to the database
> > > >
> > > > 2. invoke pg_start_backup('label', false, false) in the connection from
> > > > step 1.
> > > >
> > > > 3. copy the contents of the data directory to the backup medium
> > > >
> > > > 4. invoke pg_stop_backup(false, true) in the connection from step 1.
> > > >
> > > > 5. copy the result from the previous step to the backup medium.
> > > I don't understand that last step "5. copy the result from the previous step
> > > to the backup medium."  It seems to be a duplication of "3. copy the
> > > contents of the data directory to the backup medium".
> > Step three copies all the files from the data directory. However, there
> > is an additional piece of information you you need to recover the
> > database, and that is only returned by the call to pg_stop_backup:
> >
> > postgres=# select * from pg_stop_backup(false, true);
> > ╔═[ RECORD 1 ]═════════════════════════════════════════════════════════════════╗
[...]
> > ╚════════════╧═════════════════════════════════════════════════════════════════╝
> >
> > Without this information the backup is useless, so it must be backed
> > up, too. Obviously you can do that only after you got it.
>
> Thanks.  A clearer instruction for step 4, I'd have said something like
> "invoke pg_stop_backup(false, true)in the connection from step 1, piping the
> output to a file on the backup medium."

I could have phrased it that way but I wanted to set the stage for the
second half of the posting, where I was contrasting that to the work
flow of a typical general purpose backup program.

There "piping the output to a file on the backup medium" isn't possible
because the backup is already finished. So it made sense for me to
present invoking pg_stop_backup and writing the result of pg_stop_backup
to the backup medium as two distinct steps. I think this also makes the
solution much more natural (some might even say obvious) than if those
had been presented as a single step.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp(at)hjp(dot)at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

In response to Browse pgsql-general by date
  From Date Subject
Next Message Paul Förster 2020-06-22 12:58:31 Re: Netapp SnapCenter
Previous Message Magnus Hagander 2020-06-22 11:08:23 Re: Netapp SnapCenter