On 2/19/18 10:32 AM, Don Seiler wrote:
> On Mon, Feb 19, 2018 at 9:21 AM, David Steele <da...@pgmasters.net
> <mailto:da...@pgmasters.net>> wrote:
>     Yes, they are typically very small.  The general exception to this rule
>     is if logs are stored in pg_log.  I recommend storing logs out of the
>     PGDATA dir as they can be quite large and don't really make sense to
>     restore to another server.
>     Files copied from the master will be marked as such in backup.manifest
>     (master:true) so you can check for yourself.
> Good to know. And fortunately for this DB we do have pg_log (and
> pg_xlog) symlinked to different volumes outside of $PGDATA.

If pg_log is symlinked to PGDATA it will be copied.  pg_xlog is not
copied in any backup.

>     > I did come up with a sort of Rube Goldberg-esque workaround for now
>     > involving using a clone of the prod standby VM from Veeam backup to use
>     > as the backup source (after stopping recovery and opening it as a
>     > standalone DB).
>     You don't get PITR that way, of course, but at least it's a backup.  As
>     long as your clone is consistent.
> Yes it's a crash-consistent snapshot-based backup. I've done quite a few
> restores from it and it works great. It can do PITR as well since I
> would have all the WAL files from prod needed to keep recovering. But
> for these cases I just recover it to the first consistent point and open
> it for testing (or backups in this case). 

I don't think it would be safe to do PITR on a backup taken in this way.
 The WAL diverges even if you suppress a timeline switch.


Reply via email to