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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
