Andres Freund wrote:
> On 2019-02-24 11:52:54 -0800, Christophe Pettus wrote:
> > > On Feb 22, 2019, at 15:18, Stephen Frost <sfrost@snowman.net> wrote:
> > > Getting a solid and resiliant backup to work from a shell script is, imv
> > > anyway (though I might have a bit of experience, having tried numerous
> > > times myself and then realizing that it just isn't practical...), a
> > > downright fool's errand.
Here is my run with the fool's cap on:
https://github.com/cybertec-postgresql/safe-backup
> > The reality, though, is that there are a lot of organizations who have
> > invested time and effort into getting a backup strategy working using
> > the existing APIs, and there will be quite a bit of pushback against
> > the version in which the existing exclusive API is removed.
> >
> > Some of those will be able to move to non-exclusive backups easily;
> > others won't. For the ones that can't move easily, the reaction will
> > not be, "PostgreSQL version x has a safer backup API"; it will be
> > "PostgreSQL version x broke our backups, so we're not upgrading to
> > it."
From the reactions I see in the field, I'd agree.
> I think it also depends on how we remove exclusive backups. If we do it
> by adding a 'pg_run_hot_backup --conection-options -- shell_command_to_copy'
> it ought to be pretty simple to fix scripts. Whereas right now, with the
> requirement to manually have a postgres connection alive, which is
> annoying to do from shell, is not the case.
>
> I think if we'd introduced a command like that, we'd have seen a higher
> adoption of non-exclusive backups.
I think that is a good idea and will do the trick for many people.
It will be harder for those whose backup solution is driven by
a central backup software that backs up the file system and just offers
"pre-backup" and "post-backup" hooks.
Yours,
Laurenz Albe