Bacula-users

Re: [Bacula-users] SOT: Better strategy for backup PostgreSQL DB

2009-12-07 22:46:50
Subject: Re: [Bacula-users] SOT: Better strategy for backup PostgreSQL DB
From: Dan Langille <dan AT langille DOT org>
To: ReynierPM <rperezm AT uci DOT cu>
Date: Mon, 07 Dec 2009 22:43:03 -0500
ReynierPM wrote:
> Hi there:
> I'm trying to establishing
> 
> I'm trying to establish the rules and guidelines to be followed by a 
> Data Center (DC) on topics of backup and restore information. The 
> software that I have proposed to perform these tasks is Bacula[1] of 
> course. This is already configured and backing up some services (SaS) 
> available on DC. However, the issue of Databases with PostgreSQL has 
> caused me concern and have given me the task of finding possible ways to 
> store information (structure & contents) of the BD.

BD?  Is that database (DB)?  I will assume it is.

> So far I have investigated two ways of saving the contents:
> 1. WAL files with Point In Time Recovery (PITR) (the better but more 
> expensive)
> 2. Make DUMP of the tables from the DB
> 
> With the first I think is the best, resolve all or nearly all, as the 
> PostgreSQL Manual [2] and this website I found [3] said the advantages are:
> 
> - The backups not need to be consistent: you need a copy of the files of 
> the cluster (imagine that relates to the content of the directory where 
> the files are stored on the BD) and the WAL files
> - A DUMP (dump) full BD is not necessary
> - Incremental
> - Continuous
> - Point In Time Recovery: you can restore the DB to a point of time
> 
> But it also has disadvantages THE FOLLOWING:
> - Additional Complexity
> - The need for storage capacity
> - Improved write and access the hard disk IO which may impact on the 
> "performance" of the server
> - Works in the cluster of full BD
> 
> The second, which is not the best but it's not bad;), I resolved the 
> issue of saving the structure and contents of the BD but you need to 
> consume additional resources every time you perform a backup as it 
> should to dump BD all files then make copies of those files and also not 
> let me do PITR.
> 
> Taking into account the previously expressed what option yours would 
> recommend taking?
> 
> When using the first I have a little problem and I do not have enabled 
> the WAL files on my server so the BD file. Wal there, what would be the 
> best strategy to follow then? Generate "full dump of the DB so far from 
> that dump and start generating the file. Wal? "I find documentation 
> related to the issue of enabling the. Wal? What maximum amount of space 
> needed to be 10 for BD at the moment?

Your choice of PITR or pg_dump pretty much depends upon your time to 
rebuild the DB.  If that takes 20 minutes and you're happy with that, go 
with pg_dump.

> 
> Waiting for your comments
> 
> [1] www.bacula.org
> [2] http://www.postgresql.org/docs/8.2/static/continuous-archiving.html
> [3] http://www.wzdftpd.net/trac/wiki/Misc/PostgreSQL/BackupPITR
> 


------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users

<Prev in Thread] Current Thread [Next in Thread>