Skip site navigation (1) Skip section navigation (2)

Re: WAL files backup

From: "Andy Shellam (Mailing Lists)" <andy(dot)shellam-lists(at)mailnetwork(dot)co(dot)uk>
To: Chad Wagner <chad(dot)wagner(at)gmail(dot)com>
Cc: "Eduardo J(dot) Ortega" <ejortegau(at)cable(dot)net(dot)co>, pgsql-admin(at)postgresql(dot)org
Subject: Re: WAL files backup
Date: 2007-02-16 15:07:21
Message-ID: 45D5C8A9.8090002@mailnetwork.co.uk (view raw or flat)
Thread:
Lists: pgsql-admin
Chad Wagner wrote:
> On 2/15/07, *Eduardo J. Ortega* <ejortegau(at)cable(dot)net(dot)co 
> <mailto:ejortegau(at)cable(dot)net(dot)co>> wrote:
>
>     After erasing the "less than  names" WAL files, we add to tar the
>     remaining
>     WAL records (0003B, 0003C  and so on on the example). The more WAL
>     files you
>     have after 0003B, the more up to date DB you get after restore
>     (since it has
>     more WAL files indicating more transactions that took place after
>     the backup.
>
>
> Why bother trying to delete WAL files older than the .backup file?  
> When PostgreSQL is in recovery mode it knows which WAL files are 
> necessary to perform the recovery.
>
> Also, the documentation recommends excluding the pg_xlog directory 
> when performing the base backup.  Likely when it comes time to 
> recovery the online WAL files have been archived already, so it is a 
> risk of confusion I am sure.

If the OP is doing the same as myself, the WAL files are being archived 
outside of pg_xlog (indeed outside of the PG data cluster) - it makes no 
sense keeping around WAL files older than the .backup file because 
they're not needed - in a day I generate ~5GB worth of WAL files which 
aren't needed after the full backup runs at 2am, so it's a waste of 
resources to keep them around or to worry about backing them up after 
this time.

Andy.

In response to

Responses

pgsql-admin by date

Next:From: Tom LaneDate: 2007-02-16 15:26:26
Subject: Re: pg_xlog and the WAL files
Previous:From: Chad WagnerDate: 2007-02-16 11:34:12
Subject: Re: WAL files backup

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group