DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:subject:cc:in-reply-to:mime-version
	:content-type:content-transfer-encoding:content-disposition
	:references;
	b=WImE5LrTZnuIW2JAIo0vjxeRqNZhyUKzdzQ2Dilz9WN923eO2MFfRvVPQ+qK2T9lV4
	+sG6DmJLRGGUPNHDwt09vuJ/7DOoGbjlBVZ8rtDvj9mu1iAxII18GXAC5LUcWHn474oA
	sSlTRtMAOvP210ccsafKHUvEGkDADc6aIQPGw=
Message-ID: <a2de01dd0810150722i6f9895b0u1731683b8bce8dc2@mail.gmail.com>
Date: Wed, 15 Oct 2008 15:22:39 +0100
From: "Peter Childs" <peterachilds@gmail.com>
Subject: Re: Backup strategies
Cc: pgsql-performance@postgresql.org
In-Reply-To: <gd4tad$qlg$1@ger.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <48F4D693.9000304@lerner.co.il> <gd4d7q$3ed$1@ger.gmane.org>
	<48F5BBFC.80404@krogh.cc> <gd4gp6$f4p$1@ger.gmane.org>
	<48F5D6AE.3000601@lelarge.info> <gd4qo2$gvl$1@ger.gmane.org>
	<alpine.DEB.1.10.0810151432280.15851@aragorn.flymine.org>
	<gd4tad$qlg$1@ger.gmane.org>

2008/10/15 Ivan Voras <ivoras@freebsd.org>:
> Matthew Wakeling wrote:
>> On Wed, 15 Oct 2008, Ivan Voras wrote:
>>>> Nope. Even files in data directory change. That's why the documentation
>>>> warns against tools that emit errors for files that change during the
>>>> copy.
>>>
>>> Ok, thanks. This is a bit off-topic, but if it's not how I imagine it,
>>> then how is it implemented?
>>
>> The files may change, but it doesn't matter, because there is enough
>> information in the xlog to correct it all.
>
> I'm thinking about these paragraphs in the documentation:
>
> """
> Be certain that your backup dump includes all of the files underneath
> the database cluster directory (e.g., /usr/local/pgsql/data). If you are
> using tablespaces that do not reside underneath this directory, be
> careful to include them as well (and be sure that your backup dump
> archives symbolic links as links, otherwise the restore will mess up
> your tablespaces).
>
> You can, however, omit from the backup dump the files within the
> pg_xlog/ subdirectory of the cluster directory. This slight complication
> is worthwhile because it reduces the risk of mistakes when restoring.
> This is easy to arrange if pg_xlog/ is a symbolic link pointing to
> someplace outside the cluster directory, which is a common setup anyway
> for performance reasons.
> """
>
> So, pg_start_backup() freezes the data at the time it's called but still
> data and xlog are changed, in a different way that's safe to backup? Why
> not run with pg_start_backup() always enabled?
>

Because nothing would get vacuumed and your data would just grow and grow.

Your data is held at the point in time when you typed pg_start_backup
so when you restore your data is back at that point. If you need to go
forward you need the xlog. (hence point in time backup....)

This is all part of the mvcc feature that PostgreSQL has.

PostgreSQL never delete anything until nothing can read it anymore, So
if you vacuum during a backup it will only delete stuff that was
finished with before the backup started.

If you don't do a pg_start_backup first you don't have this promise
that vacuum will not remove somthing you need. (Oh I think checkpoints
might come into this as well but I'm not sure how)

Or at least thats my understanding...

So if your base backup takes a while I would advise running vacuum
afterwards. But then if your running autovacuum there is probably very
little need to worry.

Peter Childs