Re: Proposal: Incremental Backup

Поиск
Список
Период
Сортировка
От Claudio Freire
Тема Re: Proposal: Incremental Backup
Дата
Msg-id CAGTBQpYD-7g+1562gRywGGR1DCaVTd5ni6wN7KeFrwTYphXnmg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal: Incremental Backup  (Gabriele Bartolini <gabriele.bartolini@2ndquadrant.it>)
Ответы Re: Proposal: Incremental Backup  (Gabriele Bartolini <gabriele.bartolini@2ndquadrant.it>)
Re: Proposal: Incremental Backup  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: SKIP LOCKED DATA (work in progress)
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: KNN-GiST with recheck