junior.listas wrote:
> 1) mysql tables became huge ( each backup adds a million and six  
> hundred thousand lines ), so i split the configuration into 2 daemons 
> with 2 different bases, one for mon,tue,wed and other for thu,fri( and 
> one 3th for monthly bkps ) ; because between a backup starts, delete old 
> lines and start add newest lines take 45 mins; just to re-create the 
> catalog, before restore anything it takes 1 hour.

I have a similar problem with postgres; the catalog database is now so
large that restoring it from a pg_dump backup takes 3-4 hours.  This is
before you account for the length of time taken to read it from the tape.

In a DR scenario, that's 3-4 hours sitting there twiddling your thumbs
waiting for the catalog to come back so you can do some useful restores.

My solution so far has been to script a database sync and LVM snapshot
of the volume on which the database resides, and then backup the snapshot.

In theory at least, restoring the snapshot should give me the underlying
files back and it's undergone no worse than a system crash.  Provided
things like wal_sync are enabled, everything should be OK.

All my testing indicates that this should work but I'm a little nervous
as it's far from a properly supported solution.


James.

-- 
James Cort

IT Manager
U4EA Technologies Ltd.

-- 
U4EA Technologies
http://www.u4eatech.com


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users