From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | David Steele <david(at)pgmasters(dot)net> |
Cc: | Don Seiler <don(at)seiler(dot)us>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgBackRest backup from standby |
Date: | 2018-02-19 16:29:49 |
Message-ID: | CANP8+jK4XkjQ75CYRoMzNbHbWAXUfkbyrD0Liwxd=nVhsMTq2Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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.
> The WAL diverges even if you suppress a timeline switch.
Which is exactly why we have timelines.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Aditya Nugraha | 2018-02-19 16:57:20 | Error when compiling postgresql 9.6.7 with Visual Studio 15.5.6 |
Previous Message | David Steele | 2018-02-19 16:17:33 | Re: pgBackRest backup from standby |