Re: Proposal: Incremental Backup

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: Incremental Backup
Date: 2014-07-31 13:09:34
Message-ID: 20140731130934.GE1040@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 31, 2014 at 11:30:52AM +0530, Amit Kapila wrote:
> On Wed, Jul 30, 2014 at 11:32 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >
> > IMV, the way to eventually make this efficient is to have a background
> > process that reads the WAL and figures out which data blocks have been
> > modified, and tracks that someplace.
>
> Nice idea, however I think to make this happen we need to ensure
> that WAL doesn't get deleted/overwritten before this process reads
> it (may be by using some existing param or mechanism) and 
> wal_level has to be archive or more.

Well, you probably are going to have all the WAL files available because
you have not taken an incremental backup yet, and therefore you would
have no PITR backup at all. Once the incremental backup is done, you
can delete the old WAL files if you don't need fine-grained restore
points.

Robert also suggested reading the block numbers from the WAL as they are
created and not needing them at incremental backup time.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-07-31 13:59:22 pgsql: Move log_newpage and log_newpage_buffer to xlog.c.
Previous Message Robert Haas 2014-07-31 12:57:41 Re: Fixed redundant i18n strings in json