From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Don Seiler <don(at)seiler(dot)us> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgBackRest backup from standby |
Date: | 2018-02-19 18:39:21 |
Message-ID: | 42d5f210-70e8-e7da-37ec-7903c69d008d@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2/19/18 11:29 AM, Simon Riggs wrote:
> On 19 February 2018 at 16:17, David Steele <david(at)pgmasters(dot)net> wrote:
>>> > 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.
>
> If you have all the WAL files, then it would be safe.
I read "open it for testing (or backups in this case)" as letting
recovery complete and promoting the cluster to a master before taking
the backup.
Don, is that the case? If it is, I think there's a problem with or
without a timeline switch. If you confirm the backup is being taken as
above then I'll detail my concerns.
--
-David
david(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Don Seiler | 2018-02-19 19:05:14 | Re: pgBackRest backup from standby |
Previous Message | Tom Lane | 2018-02-19 17:33:46 | Re: Empty ./share/timezone/UTC and failure to set UTC as timezone |