On 2015-01-26 13:47:02 -0500, Stephen Frost wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
> > On Wed, Jan 21, 2015 at 11:27 AM, Adam Brightwell
> > <adam.brightwell@crunchydatasolutions.com> wrote:
> > > After re-reading through this thread is seems like EXCLUSIVEBACKUP (proposed
> > > by Magnus) seemed to be a potentially acceptable alternative.
> >
> > So this would let you do pg_start_backup() and pg_stop_backup(), but
> > it wouldn't let you run pg_basebackup against the server?
>
> Right. We already have a role attribute which allows pg_basebackup
> (replication). Also, with pg_basebackup / rolreplication, your role
> is able to read the entire data directory from the server, that's not
> the case with only rights to run pg_start/stop_backup.
>
> In conjunction with enterprise backup solutions and SANs, which offer
> similar controls where a generally unprivileged user can have a snapshot
> of the system taken through the SAN interface, you can give users the
> ability to run ad-hoc backups of the cluster without giving them
> superuser-level access or replication-level access.
I'm sorry if this has already been discussed, but the thread is awfully
long already. But what's actually the point of having a separate
EXCLUSIVEBACKUP permission? Using it still requires full file system
access to the data directory, so the additional permissions granted by
replication aren't really relevant.
I don't think the comparison with the SAN snapshot functionality is apt:
The SAN solution itself will still run with full data access. Just
pressing the button for the snapshot requires less. You're comparing
that button to pg_start/stop_backup() - but that doesn't make sense,
because it's only useful if somebody actually takes the backup during
that time.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services