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 по дате отправления: