Re: backup manifests

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

In response to

Browse pgsql-hackers by date

  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