Thread: pg15 and VM snapshots with pg_backup_start

Hi, we run a lot of PG14 and lower. We do VM snapshots, which we backup. Before the snapshot we run a quiesce script which also runs pg_start_backup(). After a few seconds the snapshot if finished and we call pg_stop_backup.

This is working file for us, but pg15 removed this function and replaced it with pg_backup_start(), which however requires the session to be open, otherwise we get:

    WARNING:  aborting backup due to backend exiting before pg_backup_stop was called

For pg15 do I need to keep the session open, will the snapshot contain uncorruped data?

thank you.

--

OE

On Thu, 2023-03-30 at 11:50 +0200, oernii+pg@axonpro.sk wrote:
> Hi, we run a lot of PG14 and lower. We do VM snapshots, which we backup.
> Before the snapshot we run a quiesce script which also runs pg_start_backup().
> After a few seconds the snapshot if finished and we call pg_stop_backup.
> This is working file for us, but pg15 removed this function and replaced it
> with pg_backup_start(), which however requires the session to be open, otherwise we get:
>     WARNING:  aborting backup due to backend exiting before pg_backup_stop was called
>
> For pg15 do I need to keep the session open, will the snapshot contain uncorruped data?

If the snapshot is atomic, that is, represents a state that the file system had
at sume point in time, PostgreSQL can always use it for recovery.

Otherwise, you cannot use this backup, because you only get "backup_label" from
"pg_backup_stop()", and without "backup_label", you cannot recover the backup.

In the latter case, you may find this useful:
https://github.com/cybertec-postgresql/safe-backup

Yours,
Laurenz Albe

Greetings,

* Laurenz Albe (laurenz.albe@cybertec.at) wrote:
> On Thu, 2023-03-30 at 11:50 +0200, oernii+pg@axonpro.sk wrote:
> > Hi, we run a lot of PG14 and lower. We do VM snapshots, which we backup.
> > Before the snapshot we run a quiesce script which also runs pg_start_backup().
> > After a few seconds the snapshot if finished and we call pg_stop_backup.
> > This is working file for us, but pg15 removed this function and replaced it
> > with pg_backup_start(), which however requires the session to be open, otherwise we get:
> >     WARNING:  aborting backup due to backend exiting before pg_backup_stop was called

This was removed because between the start and stop backup calls if the
system crashed, you would be in an ugly state where a backup_label file
exists but it isn't actually a backup, and the database system wouldn't
start.  While you may not have ever had this happen, the risk was
certainly there and you were just lucky to not have hit it yet.

> > For pg15 do I need to keep the session open, will the snapshot contain uncorruped data?
>
> If the snapshot is atomic, that is, represents a state that the file system had
> at sume point in time, PostgreSQL can always use it for recovery.

Right- but the entire set of database files must be included in the
single atomic snapshot and you really shouldn't try to use those for
PITR because you absolutely must replay all of the WAL from the snapshot
to the end to be sure you reach consistency.

> Otherwise, you cannot use this backup, because you only get "backup_label" from
> "pg_backup_stop()", and without "backup_label", you cannot recover the backup.

You must absolutely also be doing WAL archiving properly and verify that
all of the WAL generated between the backup start and backup stop were
stored to be sure that you have a restorable backup.  Then you also need
to be sure to have the correct backup_label for the specific backup and
to restore that file when performing the restore.

All-in-all, this approach of using a snapshot and then copying it has
little advantage and many disadvantages over using a more traditional
approach to backing up the data, so I don't really recommend it.  I'd
strongly recommend using one of the built backup solutions which exist
and provide things like verifyable backups that have checksums for the
data backed up, ensure that all necessary WAL was copied, etc.

Thanks,

Stephen