Greetings, * Paul Förster (paul.foers...@gmail.com) wrote: > > On 22. Jun, 2020, at 17:46, Wolff, Ken L <ken.l.wo...@lmco.com> wrote: > > So apologies if this is a stupid question but there's obviously been a lot > > of discussion on this issue. Was a consensus ever reached on the following? > > > > If a Postgres database (both data and WAL) is located on one NetApp volume, > > meaning a snapshot should capture everything at exactly the same time with > > the required atomicity, do we still need to put the database into backup > > mode beforehand (and take it out afterwards)? If we don't put Postgres > > into backup mode first, will we still be able to use the WALs to roll > > transactions forward or would we be limited to only the point-in-time at > > which that snapshot was taken? > > you're absolutely fine with that as long as PGDATA and the pg_wal directory > are located on the same volume. But you can't perform a PITR.
... and all tablespaces are also on that volume. Basically, anything that PG might ever write to needs to all be included in that atomic write. > If you don't do pg_start_backup() then you won't be able to perform a PITR > but if that's an "I-will-*DEFINITELY*-never-need-a-PITR" situation, then > that's ok. Otherwise, from what I learned, you do a pg_start_backup(), then > do the volume snapshot, and finally the pg_stop_backup() saving the output of > the latter for PITR purposes. Note that the output from pg_stop_backup() is absolutely essential for the backup itself, not just if you want to do PITR. As for doing PITR with such a snapshot, it's not something I'd recommend as a general PITR-supporting backup strategy as it ends up being complicated and very much has a risk associated with it that you'll end up with a corrupted database if you don't manage it properly (and PG is pretty limited in its ability to help you with this process..). Thanks, Stephen
signature.asc
Description: PGP signature
