From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | David Steele <david(at)pgmasters(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: backup manifests |
Date: | 2019-09-20 07:15:28 |
Message-ID: | 20190920071528.GB18018@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 19, 2019 at 11:10:46PM -0400, David Steele wrote:
> On 9/19/19 11:00 AM, Robert Haas wrote:
>> On Thu, Sep 19, 2019 at 9:51 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> > I intend that we should be able to support incremental backups based
>> > either on a previous full backup or based on a previous incremental
>> > backup. I am not aware of a technical reason why we need to identify
>> > the specific backup that must be used. If incremental backup B is
>> > taken based on a pre-existing backup A, then I think that B can be
>> > restored using either A or *any other backup taken after A and before
>> > B*. In the normal case, there probably wouldn't be any such backup,
>> > but AFAICS the start-LSNs are a sufficient cross-check that the chosen
>> > base backup is legal.
>>
>> Scratch that: there can be overlapping backups, so you have to
>> cross-check both start and stop LSNs.
>
> Overall we have found it's much simpler to label each backup and cross-check
> that against the pg version and system id. Start LSN is pretty unique, but
> backup labels work really well and are more widely understood.
Warning. The start LSN could be the same for multiple backups when
taken from a standby.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Guo | 2019-09-20 07:33:13 | Re: Two pg_rewind patches (auto generate recovery conf and ensure clean shutdown) |
Previous Message | Kuntal Ghosh | 2019-09-20 07:10:51 | Re: Custom reloptions and lock modes |