Re: Proposal: Incremental Backup

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Gabriele Bartolini <gabriele(dot)bartolini(at)2ndquadrant(dot)it>, desmodemone <desmodemone(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: Incremental Backup
Date: 2014-08-12 16:21:34
Message-ID: CAHGQGwFoqU3t7sQCjVFPCBkD1rNEvn8sX8Znfj=y71m7ja1adg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 13, 2014 at 12:58 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Aug 12, 2014 at 10:30 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>>> Still not safe. Checksum collisions do happen, especially in big data sets.
>>
>> If you use an appropriate algorithm for appropriate amounts of data
>> that's not a relevant concern. You can easily do different checksums for
>> every 1GB segment of data. If you do it right the likelihood of
>> conflicts doing that is so low it doesn't matter at all.
>
> True, but if you use LSNs the likelihood is 0. Comparing the LSN is
> also most likely a heck of a lot faster than checksumming the entire
> page.

If we use LSN, the strong safeguard seems to be required to prevent a user
from taking the incremental backup against "wrong" instance. For example,
it's the case where the first full backup is taken, PITR to a certain
past location,
then the incremental backup is taken between that first full backup and
the current database after PITR. PITR rewinds LSN, so such incremental
backup might be corrupted. If so, the safeguard for those problematic cases
should be needed. Otherwise, I'm afraid that a user can easily mistake the
incremental backup.

Regards,

--
Fujii Masao

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sean Chittenden 2014-08-12 16:42:30 [PATCH] PostgreSQL 9.4 mmap(2) performance regression on FreeBSD...
Previous Message Andres Freund 2014-08-12 16:03:35 Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations