From: | Don Seiler <don(at)seiler(dot)us> |
---|---|
To: | David Steele <david(at)pgmasters(dot)net> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgBackRest backup from standby |
Date: | 2018-02-19 15:32:18 |
Message-ID: | CAHJZqBB+pKxVYm_Np9HF5Ga+aDFK9M2+u9BPOj86ibP3d7nPdA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Feb 19, 2018 at 9:21 AM, David Steele <david(at)pgmasters(dot)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.
> 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).
Thanks for all your help!
Don.
--
Don Seiler
www.seiler.us
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2018-02-19 16:17:33 | Re: pgBackRest backup from standby |
Previous Message | David Steele | 2018-02-19 15:21:12 | Re: pgBackRest backup from standby |