Re: Proposal: Incremental Backup

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: Proposal: Incremental Backup
Дата
Msg-id CAHGQGwFoqU3t7sQCjVFPCBkD1rNEvn8sX8Znfj=y71m7ja1adg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal: Incremental Backup  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Wed, Aug 13, 2014 at 12:58 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Aug 12, 2014 at 10:30 AM, Andres Freund <andres@2ndquadrant.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [RFC] Should smgrtruncate() avoid sending sinval message for temp relations
Следующее
От: Sean Chittenden
Дата:
Сообщение: [PATCH] PostgreSQL 9.4 mmap(2) performance regression on FreeBSD...