Re: Proposal: Incremental Backup
От | Claudio Freire |
---|---|
Тема | Re: Proposal: Incremental Backup |
Дата | |
Msg-id | CAGTBQpZrCbXSuQ5Y1rTJH8ZYNVFB0ud5Gh=L+smDiOSHSemNww@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal: Incremental Backup (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-hackers |
On Tue, Aug 5, 2014 at 9:17 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Wed, Aug 6, 2014 at 9:04 AM, Simon Riggs <simon@2ndquadrant.com> wrote: >> >> On 5 August 2014 22:38, Claudio Freire <klaussfreire@gmail.com> wrote: >> Thinking some more, there seems like this whole store-multiple-LSNs >> thing is too much. We can still do block-level incrementals just by >> using a single LSN as the reference point. We'd still need a complex >> file format and a complex file reconstruction program, so I think that >> is still "next release". We can call that INCREMENTAL BLOCK LEVEL. > > Yes, that's the approach taken by pg_rman for its block-level > incremental backup. Btw, I don't think that the CPU cost to scan all > the relation files added to the one to rebuild the backups is worth > doing it on large instances. File-level backup would cover most of the > use cases that people face, and simplify footprint on core code. With > a single LSN as reference position of course to determine if a file > needs to be backup up of course, if it has at least one block that has > been modified with a LSN newer than the reference point. It's the finding of that block that begs optimizing IMO.
В списке pgsql-hackers по дате отправления: