Re: Proposal: Incremental Backup
От | Gabriele Bartolini |
---|---|
Тема | Re: Proposal: Incremental Backup |
Дата | |
Msg-id | CAHNtfO56qFbckMPjqko+-fu7ZhpYpK0mE0YRvcHjgWkb=ksG2g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal: Incremental Backup (Claudio Freire <klaussfreire@gmail.com>) |
Список | pgsql-hackers |
Hi Claudio, I think there has been a misunderstanding. I agree with you (and I think also Marco) that LSN is definitely a component to consider in this process. We will come up with an alternate proposal which considers LSNS either today or tomorrow. ;) Thanks, Gabriele --Gabriele Bartolini - 2ndQuadrant ItaliaPostgreSQL Training, Services and Supportgabriele.bartolini@2ndQuadrant.it | www.2ndQuadrant.it 2014-08-04 20:30 GMT+02:00 Claudio Freire <klaussfreire@gmail.com>: > On Mon, Aug 4, 2014 at 5:15 AM, Gabriele Bartolini > <gabriele.bartolini@2ndquadrant.it> wrote: >> I really like the proposal of working on a block level incremental >> backup feature and the idea of considering LSN. However, I'd suggest >> to see block level as a second step and a goal to keep in mind while >> working on the first step. I believe that file-level incremental >> backup will bring a lot of benefits to our community and users anyway. > > Thing is, I don't see how the LSN method is that much harder than an > on-disk bitmap. In-memory bitmap IMO is just a recipe for disaster. > > Keeping a last-updated-LSN for each segment (or group of blocks) is > just as easy as keeping a bitmap, and far more flexible and robust. > > The complexity and cost of safely keeping the map up-to-date is what's > in question here, but as was pointed before, there's no really safe > alternative. Nor modification times nor checksums (nor in-memory > bitmaps IMV) are really safe enough for backups, so you really want to > use something like the LSN. It's extra work, but opens up a world of > possibilities.
В списке pgsql-hackers по дате отправления: