On Tue, Nov 30, 2021 at 4:54 PM Michael Paquier <mich...@paquier.xyz> wrote:
> On Tue, Nov 30, 2021 at 05:58:15PM -0500, David Steele wrote: > > The main objections as I recall are that it is much harder for simple > backup > > scripts and commercial backup integrations to hold a connection to > postgres > > open and write the backup label separately into the backup. > > I don't quite understand why this argument would not hold even today, > even if I'd like to think that more people are using pg_basebackup. > > > I did figure out how to keep the safe part of exclusive backup (not > having > > to maintain a connection) while removing the dangerous part (writing > > backup_label into PGDATA), but it was a substantial amount of work and I > > felt that it had little chance of being committed. > > Which was, I guess, done by storing the backup_label contents within a > file different than backup_label, still maintained in the main data > folder to ensure that it gets included in the backup? > Non-exclusive backup has significant advantages over exclusive backups but would like to add a few comments on the simplicity of exclusive backups - 1/ It is not uncommon nowadays to take a snapshot based backup. Exclusive backup simplifies this story as the backup label file is part of the snapshot. Otherwise, one needs to store it somewhere outside as snapshot metadata and copy this file over during restore (after creating a disk from the snapshot) to the data directory. Typical steps included are 1/ start pg_base_backup 2/ Take disk snapshot 3/ pg_stop_backup() 4/ Mark snapshot as consistent and add some create time metadata. 2/ Control plane code responsible for taking backups is simpler with exclusive backups than non-exclusive as it doesn't maintain a connection to the server, particularly when that orchestration is outside the machine the Postgres server is running on. IMHO, we should either remove the support for it or improve it but not leave it hanging there.
