Subject: Re: Backup/Restore of single table in multi TB database
From: Simon Riggs <simon@2ndquadrant.com>
To: John Smith <sodgodofall@gmail.com>
Cc: pgsql-general@postgresql.org
In-Reply-To: <b88f0d670805071524g1e4965cbif9b48a822dba961f@mail.gmail.com>
References: <b88f0d670805071302h469141e0ke29413edddb444e0@mail.gmail.com>
	<19037.1210196461@sss.pgh.pa.us>
	<b88f0d670805071524g1e4965cbif9b48a822dba961f@mail.gmail.com>
Content-Type: text/plain
Date: Thu, 08 May 2008 07:25:16 +0100
Message-Id: <1210227916.4268.254.camel@ebony.site>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Wed, 2008-05-07 at 15:24 -0700, John Smith wrote:

> Actually, I forgot to mention one more detail in my original post.
> For the table that we're looking to backup, we also want to be able to
> do incremental backups.  pg_dump will cause the entire table to be
> dumped out each time it is invoked.
> 
> With the pg_{start,stop}_backup approach, incremental backups could be
> implemented by just rsync'ing the data files for example and applying
> the incremental WALs.   So if table foo didn't change very much since
> the first backup, we would only need to rsync a small amount of data
> plus the WALs to get an incremental backup for table foo.
> 
> Besides picking up data on unwanted tables from the WAL (e.g., bar
> would appear in our recovered database even though we only wanted
> foo), do you see any other problems with this pg_{start,stop}_backup
> approach?  Admittedly, it does seem a bit hacky.

You wouldn't be the first to ask to restore only a single table.

I can produce a custom version that does that if you like, though I'm
not sure that feature would be accepted into the main code.

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com