One suggestion might be to implement a backup object versioning scheme. In most cases, the most active data in the system is the current version of a backup object. What if we retained the current table structure for the most recent version of each object, and moved any previous version to the per client tables Kern has suggested.
This would allow most of the common scripts to continue to work as is (most of them are really concerned with the most current versions of the data), and a view could be defined to provide a similar structure for scripts working on older versions of files w/o impacting the current performance for real-time backup processing. This would clearly hit the expiration processing and restore processing (in that both would have to become aware of versioning) , and expiration would have to be aware of the difference between whether this was the last copy of an object or not, but I think that would be overall valuable as well as solving this particular problem. ------------------------------------------------------------------------- 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-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
